Something can be easy or difficult, simple or complex. But even the most arduous tasks can be made in a simple, comprehensive way.
Construction is complex. Construction of a high rise building, a neighbourhood, a master plan even more so. Involving not only engineering, design, structural resiliency, but also coordination, timing, proper budgeting and hundreds of other things. Anything can go south at any point. Contingency plans are needed, too. Yet, construction happens everyday.
Software is no much different. Software can be simple or complex, but it’s the execution that can make a simple project a living hell.
Projects must have a plan. A design. A reason to be. A cohesive high level and clear understanding of the goals and domains which can make development enjoyable and rewarding. Having the time to focus on the how instead of what allows to write simpler, cleaner code that works as expected. Code that you can understand now but in a year or two. Code that needs little to none explanation to the team.
More haste, less speed
But then, there is deadlines. And with deadlines, the rush to deliver on time. Rushing in can easily kill simplicity. When planning gives in to a deadline, when there is little time to internalise objectives and domain, make them your own. Is when simple becomes a lesser priority.
We’ll get this done now and refactor later.
Being most often said than done, is a common mindset and self-indulged lie teams rely on to relax or omit the responsibility of their craft. Sometimes coined as tech debt when should most likely be malpractice1.
Conveying simplicity’s importance
Sometimes business and engineering goals are not on the same page. And although in most cases there would be no engineering without business, the opposite is also true.
And it is sometime inevitable to hurriedly get something done, but not without understanding the cost that it can translate into in the future.
As software engineers is our job to ensure the business understand the cost of hasty development. To clearly expose that time spent planning is not wasted time but quite the opposite. That executing complex features in the simplest possible form is not trivial, but also is mastered with time.
Footnotes
-
The Changelog | Kris Brandow - You call it tech debt I call it malpractice ↩