Standing in for Quality
If you read these letters for a few issues, you might have already noticed that I like quality in software engineering. I try to optimize for quality and enhancing the quality of a project leads to more successful projects and more satisfied clients. If you care for the quality it can lead to situations where you have to stand your ground to achieve the goal of increasing the quality (or your processes or your products). Because doing high-quality work also increases the costs of a project. And it’s rare that managers don’t care for the cost of a project.
A good thing to have in those discussions are case studies about successful IT projects—and what made them successful. An external partner that explains the business case why quality matters would be helpful, as well.
Anyway, it’s important to take care of quality right from the start of the project. Don’t fall for the idea of redoing it later. Refactorings are common, useful and will happen, but don’t plan for them from the beginning. If your design and architecture plans for the project were faulty or of low quality from the start, there is not much you can do later on. Be realistic about the time it will take to create a well thought-through design for your application. Factor in that you might have to create a small poc (proof of concept) to test and compare different approaches if you lack the experience.
Don’t let someone else rush you to do these things. Explain to them that you save time in the long run. What’s the saying?
Weeks of programming can save hours of planning