Many projects I have worked on seemed simple at first glance. Nonetheless, there is always something to be done, and there is no end in sight. Usually, it’s not a problem—as long as there is money to finance the development. Let’s take a look at why IT projects are never done.
Complexity
Things are always more complicated than they seem at first. Often we have unexpected complexity in two places—the problem we want to solve and the solution itself. As we try to solve the problem, we learn about new aspects that make it more complicated than it looked at first. And the solution that we create often becomes more complicated than necessary. This leads to way slower progress, to the point when the requirements change at the similar rate as the code itself.
Technical surroundings
No project is an island. Any functional piece of code depends on countless things over which we have no control. If you look with perspective long enough—5, 10, or 20 years—anything can change: operating systems, programming languages, or ways the IT economy is running. From a business perspective, plenty of efforts take many years to become profitable.
I started my career in 2008, and over the 15 years since I’ve seen:
- iOS (2007) and Android (2008) becoming important operating systems,
- the appearance of Node.js (2009) and its rise to popularity,
- Web platforms overtaking desktop applications,
- the growing popularity of JavaScript, and
- the disappearance of Flash and Java applets.
With changes of this scope, there is no way to create a future-proof project—at some point, you (or your successors) could be forced to rewrite everything on a new stack.
Third-party APIs
On a less dramatic scale, your application is likely to use some external providers: for managing payments, sending emails, or any other services. Given enough time, some of those providers will go out of business or rebuild their API and deprecate the version that you are using. Usually, there is some transition period, but it will likely be a few months rather than a few years. In a project with many competing priorities, this can feel like short notice.
Legal requirements
Similarly, the legal requirements can change from one year to another. In the EU, we had a big change with VAT and online sales in 2021. For many online companies, that meant plenty of changes in the code. They were forced to start dealing with VAT in every EU country that they were selling to.
The company where I work deals with brick and mortar businesses—we were not affected by online trade regulations. Nonetheless, we had an assumption in the code that there are only 3 levels of VAT—for example 0%, 7%, and 21%. This worked fine for us for a long time. It turned out to be a problem, however, when one of our customers expanded to a new country. Over there, not only were the percentages different, but there were also simply more levels. When you have to change a fundamental assumption like this, you are likely to get an avalanche of changes in your codebase.
Code dependencies
A mature JavaScript project has many essential dependencies:
- the framework it uses
- unit test library
- end-to-end solution
Creators of those tools try to smoothen the upgrade path as much as possible, but they have a trade-off between the ease of upgrade for you and how much they can change. And when the tool is discontinued, moving to a replacement is guaranteed to be a lot of work.
When I started working with AngularJS, Protractor was an impressive end-to-end tool—the best tool available for doing integration testing of angular applications, and probably for any frontend application. Now, 8–9 years later, it’s been a few years since it got an update, and in August 2023, it reached its end-of-life. There are better tools available now, but moving four hundred tests I have on Protractor would be a huge project.
Product discovery
Product discovery is a nice term that covers the fact that it takes time to find the right combination, where:
- your customers have a problem,
- you can address this problem at scale with an application,
- they are willing to pay for using your solution, and
- what they pay covers your costs.
You can expect this process to take time and many iterations. Some of the iterations will require implementing a feature and then seeing if it's useful to customers, and whether it makes money for the company. As long as the product is used, there will be some ideas worth checking.
How to manage it
So we know that the IT projects are unlikely to be done—that there will always be some changes that require updates to the code. What can we do about it?
Plan long term
There are always dead-lines to be met, but make sure that quarterly goals will not ruin the long-term future. Think about it as a marathon, not a sprint. One thing worth investing time in is code quality. Some compromise and flexibility will be needed, but think about overall architecture, consistency, and best practices of the stack you use. Rushing too much can lead to making a code so difficult to maintain that it will become impossible to make the simplest changes.
Document what you are writing. For a start, maintain a README file with instructions on how to start the project. Write documentation for classes and methods, preferably in a way that makes it easy to extract the documentation—for example, JSDoc.
Write automated tests. Unit tests slow down development when you are learning to test at the same time as you write code. Once you are proficient with testing, developing tests along with your code can be faster than the code alone. When you write code and tests together, you have a quick way to recheck all the edge cases you want to cover.
Keep the team around
Even with the best effort at documentation, there is a lot of knowledge that is stored only in the minds of your team members. What decisions were made 4 years ago and why; how similar bugs were fixed the last time; what code is responsible for what. Every time a team loses someone, part of this knowledge is irreversibly lost. It’s a shame the industry got to the point where changing jobs often is the best advice for developers. If you can influence that, it would make sense to make sure the devs are happy with the job and the conditions and stay as long as possible.
Top comments (2)
"Why IT projects are never done" is a statement that resonates deeply within the tech industry. Despite meticulous planning, robust frameworks, and seemingly endless resources, IT projects often find themselves in a perpetual state of incompleteness. Several factors contribute to this phenomenon.
Firstly, the landscape of technology is constantly evolving. What may have been cutting-edge at the project's inception could become obsolete midway through development. This necessitates continuous updates and adaptations, prolonging the project's timeline.
Secondly, scope creep is a prevalent issue in IT projects. As stakeholders become more involved or requirements evolve, the project's scope expands beyond its initial boundaries. This results in additional features, functionalities, or integrations being introduced, further delaying the project's completion.
Moreover, technical challenges and unforeseen complexities frequently arise during implementation. Integrating disparate systems, ensuring compatibility across platforms, and addressing security concerns can all present significant hurdles. Resolving these issues demands time, resources, and expertise, prolonging the project lifecycle.
Furthermore, organizational factors such as resource constraints, budget limitations, and shifting priorities can impede progress. Competing projects may vie for the same pool of resources, leading to delays or compromises in the execution of IT initiatives.
Additionally, human factors play a crucial role in the perpetual incompleteness of IT projects. Miscommunication, lack of alignment between stakeholders, and ineffective project management can all contribute to delays and setbacks. Furthermore, employee turnover or skill gaps within the team can disrupt continuity and impede progress.
Furthermore, the pursuit of perfection can be a double-edged sword in IT projects. While striving for excellence is commendable, it can also result in an endless cycle of refinement and iteration. The quest for the perfect solution or flawless execution can lead to project stagnation or paralysis.
Moreover, external factors such as regulatory changes, market dynamics, or geopolitical events can exert influence on IT projects. Adapting to these external forces may necessitate pivots or adjustments to the project roadmap, further prolonging its completion.
In conclusion, IT projects are never truly done due to the dynamic nature of technology, scope creep, technical challenges, organizational constraints, human factors, the pursuit of perfection, and external influences. Recognizing these factors and adopting agile methodologies, robust project management practices, and effective communication strategies can help mitigate delays and enhance the likelihood of successful project delivery. However, in an ever-evolving digital landscape, the concept of a "finished" IT project may remain an elusive ideal.
Hey. Their commitment to preparedness, resilience, and collaboration is truly commendable. Delaware Readiness Teams delawarereadinessteam.com/ are a force of positive change for our community. I've witnessed the impact of their work firsthand, as they bring together diverse stakeholders to ensure our state is ready for any challenge. A proactive approach and emphasis on community engagement make them an invaluable asset in promoting safety and well-being. Kudos to this dedicated team for their tireless efforts to make Delaware a safer and more resilient place to call home. They exemplify the spirit of unity and preparedness that every community should aspire to achieve.