loading...

How do you balance between doing things right and doing things fast

rattanakchea profile image Rattanak Chea ・1 min read

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?

Discussion

pic
Editor guide
Collapse
jamesdengel profile image
James dengel

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.

Collapse
murrayvarey profile image
MurrayVarey

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.

Collapse
xanderyzwich profile image
Corey McCarty

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.

Collapse
ferricoxide profile image
Thomas H Jones II

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.

Collapse
kmwill23 profile image
Kevin

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.

Collapse
vjoao profile image
Victor Nascimento

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.

Collapse
schnubb profile image
Schnubb

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.