Nice article David. This is a great, under represented topic that has bigger consequences than most developers realize as it can lead to failed projects.
Some developers never take time to refactor and simplify their code usually because they don't see a cost benefit, want to implement the next feature with minimal effort, or do not want to deal with the time, communication, and risk of a breaking change. Sometimes a developer has a photographic memory and can remember all the details but the dev behind them doesn't have the benefit of knowing how it was built. The result of this over time is code that they as you indirectly referenced above and the next developers behind them have great difficulty working with. It also hurts their reputation inside the company as someone who generates code that is difficult to work with.
The rule I follow and what I encourage developers working with me is to first get it to work, then clean it up ensuring all parameters are in the configuration file, and all objects, methods, and vars are named to exactly match what they do. Cleaning up later is difficult as the code is no longer fresh in the developers mind and if not done soon afterwards will never get done. Then developers behind them, like yourself, rightfully complain about the code. This is a common issue that has been happening for decades.
A more compelling reason to create easy to understand code is for you as a developer to keep your job, improve your reputation, and ultimately to enjoy the benefits of a long career.
John, I'm sorry. I do not agree that the process should be write nasty code then clean it up. The problem is that the second step probably won't occur - leaving nasty code.
It is far better to insist that clean, understandable code be written in the first place. I bemoan the fact that today we employ entry level programmers to design and implement new code. In the past, we employed new programmer as maintenance programmers who leaned the hard way that poorly written code was to be avoided.
I'm a software developer based in Newcastle Upon Tyne, England. I've got a wide range of experience in companies of varying sizes and cultures, and in roles of varying degrees of responsibility.
Thanks John, I very much agree. And yes, the "it can lead to failed projects" point is incredibly important; especially if you're working for an organisation for whom software delivery isn't their primary function; because, as experienced on the project I describe above, product owners who are not familiar with software development will often not appreciate how big of a task it can be to get up to speed with someone else's project when these considerations haven't been made during its development.
Of course there are often pressures on development teams to get things done as quickly as possible; but we need to appreciate that a small time investment in this area actually allows everyone to get things done more quickly overall. I'm not suggesting this is by any means a new idea, nor a new problem, but sometimes it's worth a reminder. :D
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice article David. This is a great, under represented topic that has bigger consequences than most developers realize as it can lead to failed projects.
Some developers never take time to refactor and simplify their code usually because they don't see a cost benefit, want to implement the next feature with minimal effort, or do not want to deal with the time, communication, and risk of a breaking change. Sometimes a developer has a photographic memory and can remember all the details but the dev behind them doesn't have the benefit of knowing how it was built. The result of this over time is code that they as you indirectly referenced above and the next developers behind them have great difficulty working with. It also hurts their reputation inside the company as someone who generates code that is difficult to work with.
The rule I follow and what I encourage developers working with me is to first get it to work, then clean it up ensuring all parameters are in the configuration file, and all objects, methods, and vars are named to exactly match what they do. Cleaning up later is difficult as the code is no longer fresh in the developers mind and if not done soon afterwards will never get done. Then developers behind them, like yourself, rightfully complain about the code. This is a common issue that has been happening for decades.
A more compelling reason to create easy to understand code is for you as a developer to keep your job, improve your reputation, and ultimately to enjoy the benefits of a long career.
John
John, I'm sorry. I do not agree that the process should be write nasty code then clean it up. The problem is that the second step probably won't occur - leaving nasty code.
It is far better to insist that clean, understandable code be written in the first place. I bemoan the fact that today we employ entry level programmers to design and implement new code. In the past, we employed new programmer as maintenance programmers who leaned the hard way that poorly written code was to be avoided.
Thanks John, I very much agree. And yes, the "it can lead to failed projects" point is incredibly important; especially if you're working for an organisation for whom software delivery isn't their primary function; because, as experienced on the project I describe above, product owners who are not familiar with software development will often not appreciate how big of a task it can be to get up to speed with someone else's project when these considerations haven't been made during its development.
Of course there are often pressures on development teams to get things done as quickly as possible; but we need to appreciate that a small time investment in this area actually allows everyone to get things done more quickly overall. I'm not suggesting this is by any means a new idea, nor a new problem, but sometimes it's worth a reminder. :D