Often as a SWE, we have to meet deadlines and to deliver on time the code quality can decrease. Or worse, it is much harder to refactor bad code later.
How do you balance between doing things right and doing things fast?
For further actions, you may consider blocking this person and/or reporting abuse
Oldest comments (7)
I tend to make things right first so it's easier to make things faster afterwards. A good software foundation is a must for incremental development.
Do things right first, and by right I also mean only the things you need to do.
YAGNI.
DRY.
By cutting out what you don't really need the things that you do right will be faster.
So true. The first time I came across YAGNI, I wasn't convinced. The second time -- with more failures behind me -- the concept clicked. Then it changed my whole outlook on work.
Seems a false dichotomy. If you don't do things the right way, you will inevitably have to go back and fix them. Which is another way of saying, "you'll have to do the work twice" ...which is generally slower than doing it once.
Saying its a false dichotomy is quite easy when there is no deadline. But its quite a different story when deadline hits hard.
So, handling this topic is the most hardest thing when you're in a leading role of a project. For me, it is more a prior subject to hold a deadline. You can always refactor code later on. But you can't refactor time. So when it comes to this point, my advice would be: hold the line, refactor later.
A customer is more impressed, when your team can do its job even if the pressure is hard. But no customer will value the code you or your team will deploy. As long as it works as intended.
I usually present information to management and product owners that "if we do X it will be fast but have Y thing happen later" and "if we do Z then that it won't happen BUT will take longer". There is a really nice freedom in being senior enough to advise but not to decide.
Do both. Have a framework or design pattern in place to remove the "doing things right" aspect. Then if you have that framework or design pattern already, "doing things fast" is a natural outcome.
Now if you have all this, of course you charge double!
When I am clearly in this time-crunch situation, like getting prepped for a conference where we are showing new products, I typically skip the documentation side with a promise to come back to it later. So I do skip non-code dev stages when needed.
If the time crunch is super silly, I plan out the feature-set and split it into phases. Then I communicate with the client on what their priorities are and prioritize.