How can you build software more quickly, without just cutting corners, taking risks and turning out crap? The prevailing view in the industry is that building software is a tough job, and it just plain takes a long time. Different factions heavily promote methods that are supposedly better, but in the end, the fancy new methods are either minor variations on standard practice or make things worse.
We don't need to speculate to decide that great software can be built much more quickly than nearly everyone thinks -- there are people who are doing it today. I've written about this extensively. But in most environments, including government contracting and large corporations, the speed methods are forbidden. Yes, forbidden, as unthinkable as trying to walk in the office barefoot. The people who get it done don't just add some secret sauce to the standard recipes -- they have whole new ways of framing the problem.
Getting from the start to the finish
Most programming jobs are like getting from Point A (where your software is today) to Point B (where you'd like it to be).
All the widely accepted methods for getting from Point A to Point B take what they sincerely believe to be the shortest path.
Standard ways to travel
There are standard, authorized, certified and audited ways to make the trip. Some people feel passionately that their way is better than the others, but they all take a long time, and there are frequent wrecks on the road. The journey is always an arduous one, and has many phases, each requiring specialists with lots of experience and training to get the job done while avoiding disaster. Which nonetheless happens often enough. Even when you make it safely to the destination, all too often you either arrive late or without all the stuff you expected to arrive with.
Everyone agrees that there are lots of steps in getting software done, steps that require education, experience and skill of different kinds, and each step builds on successful completion of earlier steps.
In the early stages of the trip, you do lots of planning, because you know how tough trips like this tend to be. You go back and forth over nearly the same ground, never making lots of progress. It’s climbing a mountain, and the switchbacks are just a necessary part of what you have to do to get to the peak. Once you’re there, you can finally see your goal at the bottom of the mountain. There’s a clear path to get there. The path continues to have lots of risks, but at least you have a definite plan, you’re know exactly where you’re going (you can see it!) and how you’re going to get there. It feels more like you’re going down the mountain.
When you’ve got point B in sight, it’s important to move deliberately and carefully. If you skip steps, you can easily wreck everything and fall off a cliff. But still, it’s easier going because everything is spelled out and written down. You’ve brought new members onto the team, specialists who have gone down mountains like this many times.
Even though you're going in a straight line, it turns out it's not a straight line on level ground! It's a straight line that goes over a very high mountain, one with vertical walls, gaps and all sort of progress-killing obstacles. There are all sorts of people promoting ways of getting to point B that are supposedly faster or less error-prone. But in the end, you still have to climb the mountain and then go down to the destination. All the same work ends up getting done, but just in different combinations and arrangements and orders.
Speed-optimizing methods
There are a couple wacko’s out there who talk about nothing but “speed.” Right. Going faster is definitely the fastest way to end up in the ditch.
Yes, that's what nearly everyone thinks, and especially people with experience, people who have been part of or been subjected to the wide variety of disasters caused by train-wreck software development efforts (oops, sorry, I'm being redundant here).
When you look at what the people who get things done quickly actually do, you find that they reject the whole paradigm of project-management-oriented software development. They think about the whole process in different terms. There's still a Point B, but instead of accepting the common delusion that you can figure out how comfortable a bed is before you lie on it, they realize that you have to get close to where Point B probably is, and then look around and refine it, maybe by quite a bit! Maybe Point B sounded wonderful based on the speculate reports received while standing on Point A, but maybe once you're in the general region of Point B, nearby Point B1 is clearly superior. So you shift to it. Look around. Figure something else out, and shift to Point B2. Wow, how great is Point B2 -- let's build some comfy chairs and a roof so we can stay here a while -- but be sure to build the roof this way, and with a skylight over there, which is pretty obvious while sitting on a camp chair in the right place, but simply couldn't have been known way over there at Point A.
Conclusion
The speedy programmers who want to get to a destination find ways to avoid making arduous, risky climbs over mountains; instead they zoom to the general place quickly, learn stuff and refine. The detailed methods that speed-oriented developers use can seem mysterious, until you see that they're looking at things from an entirely different point of view.
Comments