What defines a successful engineering team: one that prioritizes working products or one that focuses on perfecting code quality from the start? Share your thoughts and experiences on balancing priorities in engineering projects.
Follow the DEVteam for more discussions and online camaraderie!
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (7)
Perfection is enemy of the good. And in my opinion, perfection is enemy of things done, things in time, time to market. Uffffff.... perfection is enemy of too many things :D
how about one that proactively balances shipping working products with good code quality and engineering practices?
There is a fine line somewhere there. If something is hanging by a string and barely works and the first best breeze of wind will break it, it's no good.
But on the other side, if you try to make everything perfect you'll never get to a point where it's finished/working. There is always something to improve.
May I refer to point 7 in my post about the Cult of Done:
Accomplish more with the "Cult of Done"
Mr. Linxed ・ Feb 18
Indeed a good thing to think about, but part of the answer is hidden inside the description (balance). Engineering is in its essence searching for the balance. Roughly, on early stages of the project the concentration would be more on making it work.
And when the team's mindset has been built (i.e. there's a solid understanding of the targets and subject area) it's time to move a bit to perfection. All in all, both (Making It Work and Making It Perfect) are frequently 2 opposite extremes and should be avoided.
I make it work, and then refine as time allows.
This gives the users and management something to use, and see, and brings in income.
It all depends on how you write the framework - make it flexible and you CAN refine and iterate.
Make it work
that's a good topic.