What would you do if you were given a house with a collapsed ceiling and some tools? Would you start hammering away at every broken ceiling tiles or find the problems to why the ceiling collapsed? Maybe another pillar was needed to support the structure or perhaps the ceiling were simply old? Either way, strap on your tool belt, put on a helmet and say: “I am going in!”
Do it right the first time!
Software development is much like building a house, you start with the design and foundations and then you build upwards and “Do it right the first time!” is actually the easy part. The amount of design patterns, cookie-cutter architectures, and boiler-plate code that are available online makes it relatively easy to setup, especially with Maven Archetypes (Boom! Project setup done). The system may have a few custom components here and there but the process is relatively simple, there won’t be many obstacles implementing a new system. All you need is a good architecture and the rest will fit in like Lego pieces.
A good initial design helps speed development process and maintenance but in this non-perfect world with growing functionalities, deadline, business pressure to deliver, copy and pasting, lack of code maintenance, refactoring and review. Year after year, the system accumulates technical debt and hopefully your company can pay its interest on time. How does the existing framework fare now, after one year, five years or ten years?
So back to the initial example of fixing a house, you have a broken ceiling what would you do? I believe most people would say: “Let’s find the problem, fix it so it doesn’t happen again”. Unfortunately, because of technical debt, sometimes the problem is buried so deep within the system that the root cause cannot be identified because it is caused by a combination of existing problems. So the developer just patches (*cough* hack *cough*) it and pray to Linus Torvalds that it does not break while they are on production support duty.
Now, let’s talk business.
How much do you think this kind of problem is going to cost you? Technical problems such as: hard coding, lazy copy and paste, hard to understand code, duplicating work etc., these issues cause new projects to take longer to implement and it is more prone to bugs. Not to mention the amount of resources you will need to maintain and debug the system. How much time are your developers spending on fixing (patching) the system instead of development? Are you hiring developers for the right reasons?
I had a project where every time we wanted to implement a new functionality, it would require us to modify 28 files and multiple database tables just to make the functionality appear in the correct place excluding the actual implementation of the function because of all the hard coding and bad architecture design. This process usually takes between 1 ~ 2 weeks to completed, then another few weeks just to code the logic for the new functionality. Now, imagine doing this every single release cycle. Eventually I asked my manager for some time (approx. 3 months) to refactor the system and another month for regression testing. Now it only takes three SQL statements (approx. 5 minutes) to complete the same task. Spending some effort to refactor saves money and time in the long run and certainly makes the developer’s job easier.
In conclusion, good initial design is really important, however, it is not enough. Doing it right is not just about the initial setup but also continuous refactoring and streamlining the system via code review and system (redundancy) analysis. It’s like cleaning a house, if you clean your house everyday then you will have less to do and everyone will benefit.