I have been at my current employer for six months now, and it’s clear that it’s not a software development job at all. It’s a software maintenance job. I have noticed a lot of differences. There seems to be a lot less opportunities for creativity, or innovative ideas, as everything has already been decided. It reminds me a lot of the assignments we would set for the first year computer science students at uni. We provided the skeleton of the program, a bit more than method stubs, and allowed the students to fill in the gaps. In fact, in my job, even the gaps are filled in, and I just make a few changes here and there. Another difference is in the flow of delivering value. I am used to hammering out the tests, hammering out the code to make them pass, running all tests and checking everything in, and it all feels like delivering value. I hardly ever used the debugger, only in situations where something really weird was going on. Now, I basically start off in the debugger, spend a few days stepping through code, writing down notes, keeping a note of what methods and classes really do (as opposed to what they are called, which is more related to what they might have done some years ago), and trying to link things back to domain concepts if possible (although that’s not often so useful, another difference between development and maintenance seems to be that technical aspects of programming e.g. classes, xml, bytes, etc become the actual domain concepts rather than orders, customers, products etc). A lot of time is spent waiting for some expert, usually one of the other maintainers that developed the software, to explain something, and at the end of the week the change is perhaps less than 20 lines. I felt like something was wrong, as if such a small part of my time was spent truly delivering value. I was comparing apples to oranges again. Something that would have taken half a day in a development context, seems to take roughly 10 times as long in a maintenance context. But this is nothing new. Everyone knows that maintenance is more expensive than development, that is why software is often developed as projects, with fixed time-spans for development and maintenance before it is retired. But sometimes the business reality is that is in fact cheaper to continually develop something than start again from scratch. I have also heard it said that replacing a legacy system can also be expensive. So there is clearly a business case for extended maintenance of mature software products.
I wasn’t too interested at first, I wanted to be a craftsman, a creator of new software, a developer. I wanted to play a part in the high level architecture, and be involved in the decision making from a project’s very beginnings. However, software maintenance does have something to offer. It seems that there is huge money in it for a start. Customers see it as a lower risk, quicker turnaround alternative to developing a new solution. The fact that it is so expensive suggests to me that there are still some unsolved problems. Considering myself as a developer, yet engaging day-to-day in maintenance felt frustrating, so I am accepting reality, and am now considering myself a software maintainer.
However I am still a NNPP after six months, and that is unsatisfying. I take up more of the original developer’s time getting him to explain something than if he were to simply perform the maintenance himself. It is a classic case of Brook’s “Mythical Man Month”. An article in the BCS mentions “Whatever the maintenance required, it must be fully understood by the maintainer, including the impact of the maintenance in terms of cost and effort to implement.” Everything I read says it makes more sense to have the original developers perform the maintenance, and adding more developers simply makes it slower, and that if a company really feels that they have so much to do that they need new developers, then that new functionality, should be implemented by the new developers in a new project. However, the people who make decisions obviously have access to information that confirms that in this case, it does in fact make more financial sense to add new developers as maintainers, rather than start them on a new development effort.
So we can therefore assume that the company has done its risk management, weighed the pros and cons of both approaches, and decided on one. As a developer that aspires to craftsmanship principles it raises a few questions relating to optimizing my personal satisfaction with the job and ideally, mitigating some of the company’s risks in using new developers as maintainers.
- As a software craftsman in a software maintainer role, what can I offer the company, that the original developers cannot?
- How can I be just as valuable and productive to the company as the original developers?
- According to one interpretation of the Pareto principle, 20% of employees are responsible for 80% of the value. How can I ensure that I am in that 20%?
You see, it is not, and should not, be sufficient for me to be a slightly less competent, less effective and less valuable version of the people who wrote the original software. For me the answer would seem to be, find a way to complement, rather than compete with the original developers. It does not make sense to perform the same actions in the same way as the original developers. We have different strengths and weaknesses. Strengths of the original developers, which can be seen as weaknesses of the new maintainers include:
- Extensive domain understanding.
- Extensive understanding of the code base.
- Moral authority.
- Embedded in company culture.
Strengths of new maintainers, which could be seen as weaknesses of the original developers include:
- More recent exposure to other domains.
- More recent exposure to other coding styles and languages.
- More recent exposure to different cultures and ideas in general.
- Fresh start, no company history categorizing or constraining them.
- Not so solidly embedded in the company culture, already liberated from their “comfort zone”.
I was looking for analogies, from historical craftsmanship, to see what general patterns I could notice, but nothing seemed to fit quite right. Usually the thing being designed or maintained exhibit much less complexity and variation than a million line software product, such as shoes, or fountain pen nibs. Often where the product really is complex, such as a car, we start to move away from craftsmanship, and we start looking at software mechanics. Even in this case, a car is still less varied than software, and the mechanic doesn’t have to play around with it for days to discover how it works, he just reads the manual, and looks up tables of symptoms and applies the solution suggested by the manufacturer. That is an idea that could be explored further in the context of software, but I think its usefulness is limited. I could definitely say that a little more documentation would make maintenance easier, but in this case it would cost more that it would bring to produce such documentation, and would suffer the classic disadvantage of always being more out of date than the software itself. It does lend itself to underscore the importance of design techniques such as Domain Driven Design, particularly the use of Ubiquitous Language, to enable source code to be a tool that aids in domain understanding, rather than requiring huge efforts to be understood for its own sake.
One useful analogy I did think of was the boiling frog analogy. The original developers are like frogs placed in cool water that is slowly brought to boil, and the new maintainers are like frogs placed directly in boiling water. The former experiences change slowly over time, and finds it difficult to notice such change occurring, and accepts the current situation as normal, because it is what they are accustomed to. The latter frog notices things straight away, anything that seems not quite right, is immediately apparent.
So I am lead to the following ideas about how and where new developers might get their chance to shine on a maintenance team, alongside the original developers:
- Customer facing tasks and analysis. “I am still new to the travel industry, but in the automotive and health care industries we solve such problems by … have you ever thought of doing it that way?”
- Change and risk management.
- Retrospectives.
- Architecture and software design. “Of course that is going to be difficult to solve in that iterative loop. In my last job we used a lot of LISP and recursion so I believe that if we used recursion here…”
- Things independent of the domain, such as Quality Assurance (not QC/Testing but real QA), Technical Debt management, code reviews, optimization, porting, integration, deployment.
- Representing the company at conferences, and in writing on blogs and in magazines and journals etc, on technical rather than domain related issues.
However, this is not a list that I would hand to the employer and demand that changes are made to suit me. If the employer felt that changes were necessary, he would make them himself. A software craftsman’s career is his own responsibility. He has to carve out his own role, and define the way he will deliver value, within the constraints he his given.
In my case, working within an agile/iterative development process, where we get stories, divide them up into tasks, and tackle them one after the other, it should prove to be somewhat challenging to carve out a role that allows me to answer my three questions above, but a rewarding challenge, one that I, as part of my recent acceptance of my role as maintainer, am quite excited and willing to take on, not so much as an obstacle, but as an opportunity to embrace change on a personal level, and most importantly, to increase the value that I can deliver for my employer.
