Quick win oriented development

In my first job as a developer, I worked for a medium sized company where the CEO was a developer, turned manager, turned CEO. You could still find old lines of codes in the codebase from his time as a developer. This was the first, and so far, last time I have ever encountered this phenomenon. But I digress.

He had his own philosophies about software development. And one concept which he pushed hard was, Quick-Win oriented development (TM), or QWOD for short.

QWOD

Quick-win oriented development was centered around the concept of making software in the quickest and cheapest way possible. Doing what gave the most value for customers first, in the fastest possible way. Technical debt? Who cares. A working solution is better than a good solution is better than a perfect solution. Take the win, worry about whatever later.

Now this methodology, if we can call it that, is something to be used with caution. All products and projects that are considered fire and forget by a company qualifies for QWOD until they suddenly don't. And in a professional setting, you will not be there forever to fix things, so better stay on the side of maintainability and good practices. It takes longer time, but it gives valued predictability and you get to practice your craftsmanship. In the end everyone ends up slightly better. You even get paid.

For our personal projects the story is different. Not everything we make have to be enterprisey. In our micro product projects, where we are the sole developers and often sole users, we will be able to actually deliver value if we permit ourselves to take the quick-win and ignore so called best practices.

However as we shall see in future postings, quick wins does not necessarily mean bad, only incomplete.

Permission granted

In micro products the following things are permitted (work in progress)

• Hardcoded values
• Not implemented logging, monitoring and tracing
• Undocumented api
• Badly designed api 😊
• Breaking changes
• Deploy with downtime
• No thoughts about scaling
• Manual configuration of infrastructure
• Not worrying about if this third party library or DB tech is approved by IT or not

Keep doing

• Automated tests - These are awesome for running your code without running everything, saves time, gives short feedback loop, keeps excitement level high.
• Automated builds and deploy - It's just a joy to commit really. However DO NOT overdo this. This is typically a point where you (I) spend ALL excitement capital
• Automated SSL certificate handling

Back to top