What makes surprisingly expensive code changes?
For the past two years I have been working as a full stack web developer and recently as a team lead at a small software company. I work with clients on a day to day basis and have demo’s and sync up meetings once every week or two with said clients. When working with the clients we often discuss how development is going, what the most pressing issues are, and whether or not the clients expectations are being met. We run an agile process so we can adjust our direction and our work every two weeks based on the clients feedback.
One of the more common scenarios in these meetings is the clients have recently gotten their hands on a new feature and they want it to be improved or extended. From there, we discuss with them why they want it to be improved, what they want changed, and whether making a change to the code or a change to their business process is the best next step.
It is not uncommon for a business process change to be a more cost effective solution than a code change and as a software developer working closely with clients, it is important to keep this in mind.
When we are discussing possible code changes that could be made to improve existing features the question ‘How much time is it going to cost to make that change?’, or something like that, almost always comes up. The answer to this question can range drastically and depends on a number of variables. We have some amazing clients at my job so usually they don’t react much to these estimates but sometimes the clients and even the project managers are quite surprised. So what does make a code change surprisingly expensive to implement?
The one word answer is because of assumptions. I’m talking about assumptions that are made with a decision in mind. ‘I assume we are meeting outside the movie theater, so I will wait here.’ — 5 minutes later — ‘Oh, they are inside.’ That’s a 30 second fix because all you have to do is walk inside. However, you could have made the assumption that you were meeting at a different movie theater. Hopefully you figure that out before going to the movies though. If your assumptions are incorrect then there are consequences. This same scenario applies to software development.
A significant assumption and an assumption we assume every day is that the requirements for features that are currently being developed have a low chance of changing. If you think there is a high chance of the requirements changing then perhaps no development should be done at all until a more concrete decision has been made. However, with any decision there is a chance that the requirements will change in the future.
Assumptions and requirements could be thought of as two parts of a sum. Let’s say that the chance of requirements changing plus the chance of requirements not changing always equals 100%. If the requirements are 90% certain then the other 10% is assumptions that are made when developing the features for said requirement. The 10% represents how risky all the assumptions are for that requirement. These assumptions could be based on a hunch of what might come to be or perhaps they are based on a common standard in the UI/UX world. Ex. Feature X often benefits from feature Y so let’s build X but allow Y to be easily implemented in the future or the client asked for feature X and based on what we know they are likely going to ask for Y in a few months.
When projects are being developed, assumptions are made every single day. Sometimes these assumptions are informed and sometimes they are not. It’s not uncommon for an assumption to appear completely informed but for more information to be discovered later. The assumptions are often made based on input from one or more of project managers, business analysts, developers, and the client. Sometimes they are made on information that has been miscommunicated (This often results in a requirements change). Sometimes they are made after thorough planning and sometimes they are made on the fly, which isn’t necessarily a bad thing. A relatively certain assumption could be made on the fly to save the time that a meeting would take up and because it’s relatively certain there will likely be no consequences in the future.
Now it’s up to the developer
So what does it all come down to? These decisions that are made, based on requirements and with some assumptions, are then passed down to the developers. The developers then have to implement the features and based on the assumptions the developer can and should design the code so that it is easier to follow through with said assumptions. If feature X is built and there is an assumption that feature Y will be needed then feature X should be built with feature Y in mind. Doing this usually takes more time in the present but saves time in the long run.
However, even assumptions have uncertainty. If it’s only 30% (an arbitrary number) likely that feature Y is going to be wanted and it takes 10 more hours to plan for Y when building X then maybe it’s worth not planning for Y and saving that extra 10 hours until more information is gathered even if it would have saved 20 hours in the long run. Another thing that might influence a developer is the current work load. If there is only a 30% chance that feature Y will be requested and it will take 5 extra hours to plan for Y and the developer has plenty of other high priority work to do then maybe the developer should not plan for Y and should instead work on the other work they have assigned to them. In that scenario, project management also has an effect on how easy it is to make future code changes. The project managers have an interest in finishing projects quickly but must allow some time for developers to effectively plan and maintain the codebase. It’s a fine balance that requires strong communication.
In summary, an easier code change is one that aligns with the assumptions that were made when developing past features with the additional assumption that the developer had the time and resources to plan for said assumption. More difficult code changes occur when incorrect assumptions were made or if time and resources were not available in the past to plan for new requests. Requirement changes can be grouped in with the more difficult changes as the assumption was that the requirements were not likely to change. How difficult a code change is is difficult to determine but hopefully that helps shed some light on the topic.
I use a lot of percentages in this post but what it really comes down to is the judgement calls made by all members of the team when planning and developing a feature. There is no way to say that it’s 30% likely that feature Y will be wanted in the future but you could assume that there’s a low to medium chance. Whatever a ‘low to medium chance’ means is up for interpretation :).
I hope you enjoyed this blog post. If you did, sign up for updates on my website: https://joeczepil.com/ or follow me on twitter: https://twitter.com/ProgrammingJoe.
