The Difference Between Getting Things Done and Making Things Last In Software Engineering

Word on the streets is that software developers are hired based on what and how much they can get done — i.e. productivity —, generally. Most companies expect them to provide tangible value consistently in a capitalistic frenzy where “Time is money”, and productivity is trending higher every day. 

I can agree that this makes sense, wherein companies (except nonprofits) are driven by money and growth while tightly competing amidst a myriad, but only to a certain extent.

Getting things done is, besides buzzword, a poor excuse to cut short and avoid expenses. There is this illusion that this is how software is built successfully with the lowest budget possible. There is a perspective that software done quickly and restricted only to the specifications of a product owner or client is what drives businesses forward and generates profits.

Make no mistake, this approach is not suitable for most projects, and you will pay the bill sooner or later. It usually costs dearly and, sometimes, with interest.

It is a Software Engineer’s duty, in respect to his career and his clients, to consult and approach such cases with no less than the best quality standards in mind. Sometimes you need software with the bare minimum quality, but it shall never be the rule.

There are situations where you’re building an MVP, prototype or Proof of Concept, which implicitly means you’re already expecting a low-quality disposable piece of software. It would be wise to keep it low-budget and restrictive in quality aspects. In the end, you’ll either be doing a significant refactoring before hitting the market or throw it away.

However, when you’re either building a production version or adding new features to existing software, cutting short like this is AT BEST a terrible decision. It’s well known that a software codebase rots by itself mainly by being worked. If it keeps going forward carelessly in this manner, it will reach a point of no return, therefore becoming disposable. It will become either challenging and complex, thus costly, to maintain. Or generate so many issues that it lacks trust and becomes unusable naturally. At this point, it’s disposable, whether you like it or not.

Take heed, disposable software that hasn’t yet fulfilled its purpose is already a failure and a complete waste of money. You don’t want that!

By doing software that lasts, teams concentrate their efforts into building robust solutions that will hold firm against rotting. They will be prone to changes in a way that it can accommodate technological, architectural and client requirements without breaking nor exceeding reasonable budgets. They will perform well with a small bug rate and few bottlenecks.

Software built with quality in mind respects the main -ilities that guarantee it’s a success. Maintainability, Extensibility, Testability, Reusability, Scalability, Reliability, and Usability are the main ones. You can find them all on Wikipedia.

In other words, it can easily change, evolve, adapt, perform well and be tested in ways it’s supposed to. It can handle the physical stress imposed by its use and the psychological burden of the expectations about it, which without it cannot survive.

Of course, building software isn’t for free. High-quality ones are usually expensive due to the extra effort it requires. They take longer to complete, and sometimes the process isn’t as transparent as stakeholders would want it to be. It takes wisdom to see when and how this will pay-off, and I’d wager it’s a big reason that managers decide otherwise.

But, (un)fortunately, it’s unavoidable. At some point, it will demand quality, one way or another. It might take time and may even not disrupt operations in an impactful manner, but pushing it in that direction might not be a smart move.

At the end of the day, you will pay the fair price of the software. Be it by doing it right the first time or spending extra later reworking and refactoring. Even worse, sometimes the bill comes with interest, and you end up losing key clients, opportunities, employees, reputation, etc. for delivering weak solutions. Be mindful of that and adapt decisions accordingly.

Next time you build software, be vigilant about how it respectfully requires to be made. Consider carefully all variables of your project to decide how you will approach it, and give higher consideration to quality. It will pay off in the long run when you reduce bug and rework rates, improve customer satisfaction, and have it ready for the next feature or change without making a fuss.