One of the characteristics of the IT industry is that time works differently for us. This is challenging and fun, but can also be frustrating. Compared to established industries, such as construction, time goes faster in the IT industry. People who are not close to the development cycle (and even some people directly involved in it) don’t always appreciate the impact this has on IT projects.
First things first: what do I mean when I say that time seems to go faster?
I don’t mean that a minute isn’t a minute, or that an hour or even a month takes longer or shorter in the IT industry. I mean that the consequence of time is different. If you are building a house and you for some reason stop building for a year, most likely you can pick up exactly where you left off and continue building. The parts you need will in all likelihood still be available on the market, you won’t have to redo the wiring or the plumbing, and fixtures will match what you put in the walls. You might get unlucky and see that the tiles you had thought out for your bathroom have gone out of production, but the «back end» of the house won’t have such problems.
On the other hand, if you put away the system you’re currently developing for a year, the passage of time can have large consequences. You might not be forced to redo parts or the whole app, but something made a year ago can easily be bordering obsolete in terms of technology. This doesn’t hold for the whole of the IT industry, but the closer you are to the bleeding edge, the worse the problem becomes. These days, the bleeding edge tends to be found close to the operations side, with Docker and micro services, but also in the front end with the continuing development and expansion of front end libraries.
So to what extent is this a problem? You can sometimes choose to ignore new developments and keep going. If it’s only been a year you can still get all the libraries you need (unless you’re extremely unlucky) and most of them will still be supported. Your front end will probably work just fine. But there is no guarantee that your system will be secure as security issues will have cropped up that require you to patch or update your libraries. In the worst case, you are forced through major updates that can have a significant impact on your system. Your front end will probably still work just fine, but in a year many new libraries have surfaced that could have made your life easier or allowed you to do things you couldn’t consider before.
In any project running for longer than a few months you need to make time to update your libraries and apply updates. The less agile your approach, the worse this becomes. The more agile you are, the easier it becomes to fix issues as they come along. Oh, and by «running», I don’t mean just the development phase. Running also includes the lifetime of your app. It’s hardly possible to make an app and expect that to be the end of it. Even if you disallow changes to behaviour, you still need to ensure that you have a secure and running system. Updates come at all levels from front end to server patches and updates to the operating system.
The longer a system has been running, the more expensive any change becomes. An application written five years ago may not even compile because libraries are no longer available. The small request for new functionality may cost several times more than originally thought after the developers discover that the application can’t even be built any more.
Another issue arises in terms of deciding what you actually build. Constructing a house is a perfect example of the very popular misinterpretation of the waterfall method: plan everything ahead and then build the actual house. Things change, and the more time has passed between the specification phase and the implementation phase, the more the outside world changes. Requirements that were really important when planning a system might become completely irrelevant due to outside factors. Most likely the requirements are unclear and incomplete (as requirements are really hard to make). Some requirements even render other requirements obsolete or are in direct contradiction with each other. If you can’t change your requirements and your plan as times goes by, you won’t be building a very good system.
The IT industry is fairly new compared to the construction industry. We’ve been building stuff for thousands of years, and we’ve worked out many of the kinks in that time. Yes, there are new building materials, new rules and safety regulations, but the broad outlines are established and stabile. The IT industry on the other hand, is at most a few hundred years old, and for the most part we can say it is well under 100 years old. Given the global nature of communication today we can experiment and produce vast amounts of variants and new stuff simply because we have so many hands on deck and they can all communicate easily. In many ways we even have less stability now than we did 10 years ago, as there are so many choices in terms of architecture and libraries, and the global nature of our industry drives the development at a breakneck pace. If you were developing applications 10 or 15 years ago, the consequence of the passage of time would be smaller than it is today.
No matter your role in the IT project: don’t underestimate the cost of these considerations! You need to allow for time (and funds) to update libraries and code to newer standards, and the world changes more quickly than you think. Developers should be critical of which changes are important, but some will definitely be and they shouldn’t be ignored. It’s hardly ever possible to build a system and then expect that to be the end of it. A system is done when it’s no longer in use and all the machines running it have been turned off .