Are We Trying To Build Software “Too Fast”?

A recent blog post by my friend Jim Bird, along with other thoughts and ideas I’ve heard around software development using agile methods, got me wondering if we are trying to move “too fast”. Part of agile development is continuous integration, and as outlined in Jim’s article now can include continuous deployment. The goal of agile is as the name implies: agility and speed, being nimble and reacting quickly to changing needs. Followed purely, there is really minimal emphasis on long-term planning and looking ahead to the future. Instead, the focus is largely on the “here and now”, and solving immediate problems and addressing immediate requirements.

Going with an agile methodology has many advantages. It allows for rapid adaptation to customer and market demands. Following it can uncover many types of problems and errors early, and prior to release to production (unless you follow the more aggressive continuous deployment, then you can introduce new business and technical risk). It provides a certain amount of “instant gratification” because you aren’t necessarily waiting weeks or months to see forward progress.

However, like our 10-second-soundbite/video game/music video world that agile sometimes appears to mimic, it also implies short attention spans, only worrying about “right now”, and not raising your head above the weeds. In some ways, I liken it to navigating by looking no more than a few feet in front of your toes: you will react quickly to immediate obstacles in your path, but you may end up in a place you didn’t expect or possibly didn’t want to be. To take the analogy further, it isn’t just navigating looking a very short distance ahead, its also about doing this while jogging or even sprinting. So you could end up somewhere “bad” very rapidly. You didn’t trip, you didn’t step in the mud, but your product or service isn’t what you expected or potentially even should have been. To be frank, I suspect few shops follow an absolutist/purist agile approach, and do stop from time to time to see where they are really going. But the potential is there to get yourself in trouble if you don’t slow down and look around often enough.

We are living in a fast-moving world. News, entertainment and information is available “right now” with the Internet, on-demand services from cable and satellite, and instant download-and-install from online gaming stores like the Playstation Network. Some older forms of content delivery like print and CD’s are dying as people migrate to more immediate forms of content consumption. This is a fact of life, and with smartphones and similar devices gaining marketshare, the ability to participate in this continuous and constant stream of information and communications only increases. For the most part, I think this is a good thing, when consumed intelligently and with some critical thought.

However, there seems to be an attempt to apply this to anything and everything. Companies try to build cars and houses faster, assemble other goods more rapidly, and build and release software quicker. This rush, though, has resulted in things like Toyota having to recall millions of vehicles from nearly all of its models it makes. New houses seem to have a longer litany of problems and issues, most not significant in and of themselves, but when added together makes you wonder about the integrity of the entire building. More computers and small electronics seem to have issues with displays, batteries, etc. Trying to deliver product quickly, and rapidly react to consumer demand is laudable. Doing so at the expense of quality makes the approach questionable, and at the expense of safety makes it unacceptable.

Turning around a fix for a problem should happen quickly. Customers expect that. You do need to take the time to make sure the fix actually repairs the problem, and do what you can to ensure it doesn’t cause other problems. But properly repairing a product or service as rapidly as possible is essential. I definitely believe that this is a situation where using agile methods are essential and helpful.

Is it truly, truly essential that new product or features be delivered almost instantly? If your business is depending on that frequently, then I think you might have a bigger problem. I believe it would be wiser to slow things down a little bit, particularly when you have an established service or business, when looking at adding new features or making a major change to a system. Obviously, too slow is bad as well. Market pressure will sometimes dictate a degree of urgency. But unless the urgency is real, I would counsel an organization to not rush into something too quickly and release prematurely. Just because you can bang something together and get it out there quickly doesn’t mean that you necessarily should. Using agile methods here is still essential, and the ability to get something to select customers to gain feedback and information will usually help to make a better product. But I think you also need to take some time to put critical thought into the bigger picture. You have to dial the speed back a notch or two so you can see the pitfalls and insurmountable obstacles that are outside the visual range of a short-term sprint.

That being said, I am not advocating the expenditure of inordinate amounts of time in long-term planning. There needs to be a balance, and what that balance is depends on your product or service, your team, your customers and the technical/legal/economic environment that all of them exist in. The point of agile was, in some ways, to make organizations more responsive to their customers. That cannot be lost. What I am saying is that you should go as fast as you need to, which may not necessarily be as fast as you can.