Michael Feathers

How Long Does It Make Sense to Develop Software?

This is a serious question.

Imagine the startup scenario: a new company with bright plans. If the company needs to have a web presence (and what company doesn’t?), chances are they will hire team of top notch programmers to craft a set of applications to start the business on. The team works furiously for a year, dealing with all of the ins and outs of the business space and at some point requirements start to slow down. The company starts making money and the users get used to the web interface and they react violently to major changes. The company establishes itself and establishes a market. They are going to make money no matter what they do with their website. Development goes into maintenance mode. The original set of programmers start looking around and saying “I don’t want to work on this!” They dust of their resumes and join the next startup. Not everyone leaves, of course. Some people are happy about the reduced pace. They get comfortable and they deal with bug reports and the odd feature request.

That scenario plays itself over and over again across the business world. Startups need to deliver software quickly. They need to carve out a niche. But, if you’re in a business where you can get some guaranteed returns once you line up a good set of customers, the value of software development goes down. It just doesn’t matter much any more. 

A decade ago, Microsoft was a textbook example. In the beginning, software mattered at Microsoft, a lot. They competed on every field that they could, but once they nailed Windows and Office, it seemed that they really didn’t have to write code any more to make money. In many industries, that state of affairs can last a long time. But, invariably the competitors come. What happens then? At the moment when it is most critical to write new code, a company finds that it can’t. Why? Its development skills have atrophied. The developers that built the edifice are gone or off in management and the ones that are left just aren’t used to designing new software.

So, how long does it make sense to develop software? I have a friend who says that over time the best companies will discover that it is critical to maintain that capability and they will do whatever they can to keep it going. It’s the Toyota model: be your own competition and pursue excellence. It seems that Google uses this model. Their developers run wild with new ideas continually. There’s no resting on laurels. But, I wonder how many other companies will take that course? From an economic point of view it’s easy to trim development, treat it as a cost. It’s easy to reduce the challenges and leave it moribund.

My prediction is that we’ll continue to see this cycle in software development and the rewards will go to the companies who can kick-start their development when they need to.  It's hard work.  Often it seems harder than maintaining a development culture. 

Regenerative Builds

I think that when people look back at the way we program today, one of the things that they'll be amazed at is the fact that we have so much computing power but we don't do much with it.

Seriously, how many computers do you have?  If you're like me you have a least a couple of stray ones sitting around the office, and they aren't doing anything.  What a waste.  And, it's only going to get worse as multicore processors become more prevalent.

When I first heard of continuous integration, way back in the day, I misunderstood it.  I thought that some computer someplace was going to build my project continuously.  That is, regardless of whether I or anyone else had checked in.  Silly?  Perhaps. But, wasteful?  I don't think so, the computer is running anyway.  It might as well work.

A while back, I visited a C++ team that had found a wonderful use for a spare computer.   They set it up to build continuously.  Then they  did something  fascinating. They created a script that went into their code and commented out  a single #include.  Then it built their project.  If the build and the tests passed, the script deleted the include.  If it didn't, the script uncommented the include and went on to the next one.  Yes, it took quite a while to march through the code, but with that build running continuously in the background, they were able to eliminate a large number of superfluous dependencies.  Their build got better.

That script that they wrote is an example of something I call a regenerative build tool.  There are others.  Jester is a regenerative build tool which uses mutation testing to find problems.  It changes your code in subtle ways and runs your tests to see whether they still pass.  If they do, you either don't have the tests you need to have, or you could have code which is really doesn't contribute to your results at all -- zombie code.  Guantanamo is another regenerative build tool, a rather severe one.  It deletes all code that isn't covered by a set of tests.

I'm sure there are plenty of regenerative build tools that we haven't thought of yet.  And, that's a shame.  Our spare computing resources can offer us a great deal.  We just have to find creative ways to use them.