Code is a means, not a goal because software engineers solve business problems
Let's be honest. Few care about the intricacies of programming outside the developer community. What people crave, though, are solutions, regardless of the implementation details.
There are many reasons to write software: for fun, for learning, as a hobby, often as a job. But first and foremost, engineers should satisfy business needs.
When it comes to decisions about technology or processes, the fundamental question then should be: how will this move the project towards the ultimate goal - delivering a solution?
This type of thinking can prevent technology choices that are motivated only by curiosity (also known as “CV Driven Development”) or the imitation of others.
What people crave are solutions, regardless of the implementation details.
Create a minimal end to end journey as soon as possible. Treat it like a skeleton and add the “meat” later. A working draft brings clarity by serving as a roadmap towards essential goals. Knowing where to go helps avoid getting bogged down in details (over-engineering), leaving no time for crucial features (under-engineering).
Code is a means, not a goal. Writing more doesn’t necessarily help. Adding code is not always the answer - keep the priorities in mind.
Clients expect software systems to work for an extended period and also to evolve as requirements change. So we can’t be too myopic. But today has priority over the uncertain future - more on this soon.
Interested in delivering solid applications quicker? Continue reading my Best Practices here.