Press enter or click to view image in full size
This is classic. However, tons of software engineers do it in the wrong order.
Often people obsess about code/design cleanness even before getting it to work. And I wish I had a quarter for each time when people started to do premature performance optimization, I would be a billionaire by now.
Pretty much, you always have to get it working first, even if it’s imperfect and requires some polish. (BTW. I am not advocating cowboy coding and throwing some garbage at your main branch. However, I am saying that the first cut could be a little bit more simplistic, a little bit less polished, and so on).
After you got it working and it got some miles on it, you actually will understand better what you are working on. You may find some better abstractions or a better design, some other way to structure the code to make it simpler, cleaner, and so on.
And finally, when you got enough miles and load on it, you can start measuring and optimizing bottlenecks.
P.S. Obviously, there are some (rare) exceptions. That being said, everybody thinks that their project is an exception. Please, pause for a second and answer these two questions:
- Will people _literally_ die if you do things wrong (not clean or not optimal)
- Will your company guarantee to immediately lose dozens of millions of dollars if you do things wrong?
If your answer is No to both of them, climb down from your high horse. Your project almost for sure is not an exception. So, make it work, make it clean and make it fast.
P.P.S. Alex Mylnikov sent me a great comment. First should come “Define it.” On one hand, often you don’t know fully what you are building until you get feedback from customers. Even in the absence of feedback, you do need to define what you are building before building it.