Craft fast, Polish later

Craft fast, Polish later

When software development team starts working on a project they know what the software will need to do. Dev team can focus on technical side of the solution. They can design an architecture, approach for testing, infrastructure etc.

Important part of cutting corners in my projects is that I am responsible for both business and technical side. How – you will find out in this article.

Responsible for business and development

From business perspective if I would be to design business solution only – I would like to testy it as soon as possible to know what is the best way to answer user needs. In initial step I would look for extreme simplification to.

When responsible for defining business solution and development together I can look for easiest paths to connect delivering value to client and extreme simplifying implementation.

This lack of separation between business requirements and development allows me to skip a lot of architectural decision – which in classic projects are usually done up front. And its not a good idea to decide on architecture when whole business requirements can change.

So I focus on delivering feature as fast as possible to use it, maybe show someone and test it. And the code is ugly. 

Should it stay or should it go?

Simply because the app is changing – often a lot in initial phase. Every component by design will go to trash – or will be refactored. But this allows me to do small step and verify and again. 

Once I know the way I will go with the whole app or feature – I can adjust the code to be correct. But only once I found the way it should be presented to the user. Why invest in something before you know if should it stay or should it go?

I avoid investing a lot of time in solutions that may be useless. I did it in past and it was expensive and often gave less value.

For me this selection of what and how should be done is the most important.

Classic Process

In classic process, when business is separated, each iteration of defining requirements means waiting for it to be implemented, deployed and maybe tested. Probably developers will try to adjust architecture to save time in the future. Ale making few of such iterations 1) takes time and 2) costs money.

When implementing by yourself it takes minutes or hours instead of days. This possibility is not available for separated responsibilities. You can implement and review the effect multiple times, which if done properly, brings you to better usability. 

Or at least you’re saving time by lack of communication and explanation.

Fun and feedback

Except that it allows to reduce workload significantly and craft better products – it also has an important motivation impact.

Spending a lot of time on something that is thrown to trash is upsetting and drains motivation. Releasing is motivating. Dopamine hits when I create something new.

Once I know what is the thing that I really need – than I can polish my code and let myself be pedantic. Which many developers love.