My hypothesis is that the biggest challenge of the 21st century would be to solve for code maintenance.
A lot of development in the software world has been happening in the past decade. The pace is set to increase as more people join the bandwagon. With technology being the only viable option to reduce costs and bring the next generation of people out of poverty and to create a sustainable eco-system, it becomes imperative that the focus remains also on how the systems would be maintained.
Many companies are figuring out they need to re-write their entire systems. Many others are grappling with figuring out the one off bugs on systems that were written a long back. Others trying to find people who still use the technology that was used to build the system.
This article will work on providing a view on how to solve for maintenance from the development time itself. This is not to say that re-write or bugs will not happen, yet this is to say that re-write can be delayed allowing more ROI and avoid grappling late night issues.
Engineers
Like “Mechanical Engineers” or “Chemical Engineers” or “Civil Engineers” we have “Software Engineers”.
What is it that Software Engineers build? The answer Software. But this is something which is not tangible, which we cannot view so how do we decide on how to build something which you cannot see?
Here in the question lies the most important aspect of the engineer. Similar to how you cannot create a blueprint for a building without dreaming, you cannot write code if you have not dreamt of how it should look.
If we look at any popular painting, the outline has been prepared before putting the brush to the board. Why do we rush in software engineering then?
How should the development happen then?
The below article tries to draw synonyms from how to build a township. How can we learn from it while building softwares.
The first part of development starts with understanding the problem to be solved. Can you build a house without knowing how many rooms it should have? How can you then code without knowing what needs to be solved?
Having understood the problem correctly, create a mental map of how to solve the problem. The technology or the language used for solving has little impact here. This is where the “software engineer” needs to dream. This is where everything that you learnt will be used. Know the flaws of the design. Know its strength. Dream it in and out. Dream it on paper, share it with fellow workers, debate with peers. This is where you can prove that your salary is worth. This is where the growth, deep work and the actual work is.
Now this dream could be at 2 levels. The first situation is where you need to make some interior design changes in the house. In such a case you dream of how the changes fit into the house. Similarly, for changes that only touch one small area of our virtual house, the thought can remain around how to make the change fit in the existing code/system.
For the second situation where you need to construct a new house, or an entire township, the thought starts with blueprint. Here you do not worry about the kind of wood used for gates, the kind of interior design that you will do on rooms. You are bothered about how the township will structure, how many houses, where will be the roads, the school, the hospital. In the virtual world, you need to dream of how your systems would be built. A single system or multiple systems. How will they interact. You are not bothered about how the individual system gets built but more on their interaction, their interfaces to each other, their responsibilities in the eco system. Once this is done the first part of the HLD or “high level design” is complete.
The next part is to understand each system (each house in the township) and now think about how its going to be structured (think rooms, the layout, the height). Think about how it would be best suited to fulfil its responsibilities. Here you start defining the technology and the language that best suits these responsibilities. You also think about the NFR’s or the “Non functional requirements” here. No one every tells these things, and yet this is again where the “engineering” comes in. Do you expect to have a house without a ceiling? Well no one tells you and yet this is implied. Similarly no one tells how much the response time for an API execution should be, and yet it is expected. This is the time to think on how you can provide a base to solve for all of these. Once this is done the “HLD” is complete.
The next part comes to map the house interiors. To know the windows, the quality of glass required. Similarly, the next part is to know how the code would interact within itself. It needs to know how the functions talk to each other. Which interfaces are needed. Which objects are created. Which database table holds what values. Which table indexes are needed. Knowing exactly what is expected in the code, completes the “LLD” or the low level design.
After having complete clarity on what is to be written, this should be the shortest or the least time consuming work, “writing code”. When you sit down to write an essay, if you know the points in your mind, the essay flows out smoothly. Same is the case here. If you are getting stuck while writing code, it means somewhere you missed in understanding the layout of the house. This is the construction part. This would be the least brain consuming activity (assuming you understand the technology and the language being used).
Having completed the development, you do a testing for the functionality. This could be automated through test cases. If the above parts are done correctly your code (house) should pass the quality check. And you should be ready to shift in the house? No wait, this was you giving a certificate that the house is ready for shifting.
Next comes the role of the people who check your claims (for houses its Government, for software its the quality assurance people). They check your claim to know if the house is stable as you have stated. Once they have given the go ahead, you can then put your code in production and let the people have a house party.
I skipped the code review part, which generally should happen after the development testing, which is synonymous to internally checking for quality before submitting the request to the Government.
There is a cost to building a house, similarly there is a cost for software. Every person involved in the process should have a vision for his her virtual house. In reality if houses are expected to stay for 20-40 years, why cant we envision our virtual houses to stay for 20-40 years? If we want them for so long, it is imperative that we build it with a solid foundation and easy to do maintenance. No one would be happy to maintain a code / house which does not have easy to reach windows/doors/interfaces.
Learning a new language or a technology is hard. To master it is harder. Yet, the most difficult part in this century will be to dream.
Journey of a Techie 