Nothing makes a better developer than knowing WHAT is to be built. Before deciding on HOW to build your system, component, or a simple function, you definitely need to know WHAT you are building. While this seems to be obvious, absolutely most developers are focusing on HOW first, leaving WHAT as more of an afterthought. Well… there could be a simple explanation, for devs, HOW is cool, WHAT is not so much (is it to blame our approach to learning to code?).
Keeping WHAT as an afterthought ignores the simple fact that good architecture and design are not possible without a proper understanding of WHAT. WHAT has all the logical challenges solved already, so knowing WHAT will shrink your development time, scope, resources, and simplify your code. WHAT is not changing significantly on a whim, unless business requirements are badly “harvested”; so, knowing WHAT will also serve as a vaccine that immunizes your system against the difficulties of implementing future changes, protecting it from “growth problems”, when the time comes to add a new awesome feature. If you understand the above, then getting an excuse “our architecture doesn’t support this new requirement” from your architect means there is a chance you should fire him/her, or less likely Product Manager, or even less likely both.
Not understanding WHAT clearly makes your application hard to understand. Your code is nothing more than just expressing your domain via a programming language. So, imagine you are writing a new book… in TypeScript, C#, or Rust. If you write it without a clear understanding of what you are writing about, your readers will struggle through it just because they have to. However, if you understand what you are trying to say and express it in an elegant and concise way, it would be easy and fun to read for a new developer who joins your team a year later.
Agile… I can see some toothy grins and those oh-so-common words: don’t be waterfall (!!!), do not request requirements from us, and everything will be fine — we’ll adjust. What is missing in this logical chain is that the sole purpose of agile is to respond to changes quickly. Creating additional issues by poorly defining requirements and introducing “cowboy” architecture and design right from the start is not part of the agile process. While I am definitely not advocating for going to the waterfall, overall broad system vision and detailed requirements for each sprint or even just a story before they start are “must-haves” for an agile process, unless you are doing a quick POC.
Let’s look at some of HOW people’s most common arguments (based on true stories) in the next story.
But now, know WHAT you do, have fun coding, and what is way more important and rare… have fun supporting your app!
Cheers!
