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 (8)
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
As an individual, I find that making something work is often a necessary step towards making it perfect. Sometimes I find myself really going in circles in my head about how to write some code/module/feature/etc as best as possible, and I'm not really getting anywhere. When I find myself doing that, I tell myself "make it work, then make it good". And that suddenly opens the path forward, because making something work is easier than making it good.
Then after I get it working, sometimes I look at it and say "you know, this actually isn't that bad", and leave it there. Other times I do some refactoring, and I find it's often easier to improve something you just built, than to build it good from scratch.
I do think that approach breaks down a bit on an engineering team however, especially if you have non-technical product owners (which I do), because they may not appreciate the value of taking time to "fix something that ain't broke," as we say. Also, among a team, if you can be locked onto a certain approach from the beginning, it can save a lot of hassle as the project progresses.
Then there's the business angle. As engineers, I think we tend to feel that we're doing a good job when we get our code as close to perfect as possible. But if we can get the first-mover advantage by making something work sooner, that may make the business more successful than perfect code would. Of course we have to consider future maintenance costs, extra cost of supporting customers, the cost that the tech debt adds to new feature, etc, and deciding if that's actually worth it is black magic.
Ultimately I don't think there's any one-size-fits-all approach. I think an engineering team will generally be happier and function more smoothly if they prioritize quality, but that may not always be what the business needs.
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.