I have been told “there is no such thing as green field development”. While that statement is false for the hobbyist developer, in the business world it is nearly true. Those who code for a hobby or for pure enjoyment often start from scratch, as evidenced by the explosion of unmaintained projects on Github. See my article about software ghettos for more on that. When it comes to software used in the real world, open source or not, maintenance is an everyday task.
Consider what goes on between the 1.0 and 1.1 release. Was that 100% new work or did it include some maintenance to allow the 1.1 features to fit with the 1.0 architecture? Now fast forward to the 1.8 release, was the ratio of maintenance higher? Almost certainly.
An article by Robert Glass in IEEE Software May/June 2001 called Frequently Forgotten Fundamental Facts about Software Engineering states maintenance is 40-80% of software cost, and enhancements contribute to 60% of new maintenance costs!
Why care about quality?
Consider that businesses are not interested in (and probably can’t afford) a monument to computer science. What the average business demands is functional code. I have been involved with dozens of businesses, small, large, tech centric, and technophobic – none have asked for fancy or perfect code. Anything beyond functional is seen as a waste, and I agree. This is not a license to take shortcuts and hack things together. If shown the distinction a business doesn’t want a ghetto code base with anti-patterns everywhere that will soon become unmaintainable and cause developers to run and hide. In spite of this, it turns out a lot of systems are managed in a manner that contributes to major system outages, security holes, developer attrition, and occasionally huge monetary losses. Google ‘stock market glitch‘ for examples.
How can software maintenance work be done efficiently?
A great developer won’t make much of a dent if they are blocked from doing so. The product owner should have a long term plan for the system which includes keeping the system healthy and maintainable. That plan should favor fixing existing bugs (see #5 on Joel’s list) and allocate time for paying down technical debt in each release. Technologies such as source control, a suite of unit tests, code linting and build automation are extremely helpful. Policies on code style, documentation, learning, and knowledge sharing make a big difference too.
A team composed of a mix of veterans, mid level staff, and junior developers makes for a healthy balance. The developers should be allowed to think they own it (a variation on a famous quote from Bill Gates). A culture of knowledge sharing should be encouraged and rewarded. Assumption checking should be considered normal and non-threatening. Have you ever read a spec that was 100% free of half baked assumptions? Individual performance should take a back seat to team performance. Otherwise silos form, the incentives become twisted, and so does the code.
On the individual level a developer has three hills to climb to become maximally efficient:
1) The languages, libraries, and technologies used in the system.
2) The domain (the nature of the business).
3) The way the system was setup.
Languages and libraries should be a relatively low hurdle if the technologies used are ubiquitous and the right skills are hired for. Domain knowledge is harder to come by. In some areas such as insurance, finance, education, or ERP a person with the right experience is attainable. The third hurdle is by far the least visible to the business and the most challenging. It ultimately comes down to what is stuck inside the developer’s head that makes them efficient at maintaining the system. If the developer wrote the system from scratch, they get past that for free. That assumes they haven’t already moved on… perhaps washing their hands of a mess?
“Debugging is like farting – it’s not so bad when it’s your own code” – Unknown
The time it takes to attain mastery over a code base is proportional to its size and complexity. The best approach is to start with an easy task, then something slightly more complex in a different part of the system, then something in a third area, and finally circling back to the first area for a real challenge. This way confidence is built up steadily and the risk of breaking something critical is reduced.
The first few days to several months of working on an unknown system are the most stressful and error prone for a developer. Without knowing every aspect of the system it is easy to accidentally write new bugs. Without a senior developer or product manager to explain things it can be very confusing and frustrating to make headway. This is where developers with solid people skills and high self esteem will shine because they are not afraid to ask for help and are effective at getting good answers.
Development efficiency increases over time then plateaus:
The orientation phase and steepness of the growth phase increase relative to the size of the system. They can be shortened with documentation, clean code, but most importantly friendly and knowledgeable team members. Hiring for a person with knowledge of the languages, libraries, and domain also helps.
Let’s say things go well, and the developer climbs the efficiency curve after X days or weeks. Now they are really ‘making money’ for the business. This is the most efficient place for the developer to be business wise. The length of time a developer spends on top of the curve depends entirely on the company’s ability to retain that developer. The going advice is to pay at least a fair wage, be flexible, be organized, then stand back and let them go. Make sure to let them do interesting things from time to time. Offices with windows, sit stand desks, and flexible hours are nice perks that don’t cost much when averaged out. The alternative is to loose the developer and go back to square one in the orientation phase with someone new.