One of the most amazing feats in an IT company is a visionary motivating the employees. A visionary is basically a person who has radical ideas for the company and its products. Here is a vision one might have:
The G3R1 system is a prototype to solve the problem of waste management in our city. It has the potential to revolutionize the greening industry and make a print on our society to make them realize how beautiful the future is. And we are not just stopping with our city; we have plans to extend this to our nation, and then to the whole world (applause, applause; and a successful team meeting).
This is how a typical IT project starts. Now, let’s take a look at how the entire project proceeds. If you look closely, the above speech has a lot of loose ends which is perceived in a different way by every individual. During requirement’s gathering phase, every document (use case, user stories, functional specifications, etc.) will address future requirements, e.g.: the vision for this system is to extend it to all the nations on this planet. This in-turn is interpreted by the designers as features to be incorporated now so that they can be easily utilized in the future, e.g.: we’ll need an internationalization feature to cater to all the languages spoken in the world. This is pushed to the development team to write the code in such a way that they don’t need to do much later; in short, write everything right now since you might use it in the future, e.g.: let’s utilize i18n and create a resource model or use a content management system to make sure we can handle these requirements in the future.
Just how many things went wrong here? The first underlying rule of software development is to play it like a game of chess; strategize every move to reach the final destination – checkmate. But it is the uncertainty of software development that falsify this rule most of the time. This game of chess might kill a pawn and still be the winning move.
Let’s utilize the same theory here: the vision is to provide this software to the world, but we are building the prototype for now; for all we know, this is a proof of concept and might even fail after implementation. It is being developed as per the requirements of our city right now, which might need a lot of customization for the other cities as per the rules and regulations of other nations in the world. It’s important to prove that our theory and implementation works before we can develop a full-fledged system.
Even though we are aware of this underlying rule, ask a developer why a piece of code was written and the answer is “we might need it in the future”. “Might” is good enough for me to push this implementation for later; then why do we end up doing it right now?
Because the second underlying rule of software development is that the cost of changing a program rises exponentially over time. But this underlying rule does not exist anymore (strange all our software rules no more exist). The software development community has spent enormous resources in recent decades trying to reduce the cost of change – better languages better database technologies, better programming practices, better environments and tools, new notations. The cost of change no more rises exponentially over time, but rises much more slowly, eventually reaching an asymptote .
Considering our initial example, there is a good possibility that we might never implement this system outside our own city (or country). So we can let go off the feature to support multiple languages (considering we are not in a country like India where political pressure might result in a system being developed for all the regional languages). Even if we need this feature in the future, keep the architecture simple enough (difficult to achieve since we like to show off) so it can be extended later. We’ll take almost the same amount of time to implement it later on an architecture that is much stable than the current one, with technology better than the one available to us currently. And considering economics, just in time delivery usually earns you more revenue than stale delivery.
Software engineering is very different from other forms of engineering. It’s evolving faster than the others, requires smaller investment, used by all engineering disciplines, and probably the coolest. But if I may compare it with Civil Engineering, building a structure that supports today’s infrastructure and demolishing it when not required is a principle that can help software as well. Build for today with a belief (and courage) that your skills will handle the future. In the words of Grand Master Oogway – You are too concerned with what was and what will be. There's a saying. Yesterday is history, tomorrow is a mystery, but today is a gift. That is why it is called a "present" .