Skip to main content
Software Engineering

Return to Answer

Post Timeline

added 97 characters in body
Source Link
phtrivier
phtrivier
  • 229
  • 1
  • 2
  • 6

  • Make it clear that expectations are not realistic, and that you're going to produce a sub-par product because you're asked to. Everyone needs to share part of the blame here. (You assume that the conversation has already been had, but in so many cases only half the side really understand what it means)

    Make it clear that expectations are not realistic

You're going to produce a sub-par product because you're asked to.

Everyone needs to share part of the blame here. (You assume that the conversation has already been had, but in so many cases only half the side really understand what it means)

  • Find ways to ship less. Reduce scope to the bare minimum. Use the acronym "MVP" as much as possible (it subconsciously reminds people of "IPO" in the start-up world, which put some in a better mood ;) )

    Find ways to ship less

Reduce scope to the bare minimum. Use the acronym "MVP" as much as possible (it subconsciously reminds people of "IPO" in the start-up world, which put some in a better mood ;) )

  • Find ways to ship incrementally. A large part of your "soon-to-be-dirty" code is actually not needed because the business requirements are not clear. If you can implement 10% of the feature in a "quick and dirty way", and make it obvious enough that the feature was misunderstood / not needed, you've spared you and your codebase.

    Find ways to ship incrementally

A large part of your "soon-to-be-dirty" code is actually not needed because the business requirements are not clear. If you can implement 10% of the feature in a "quick and dirty way", and make it obvious enough that the feature was misunderstood / not needed, you've spared you and your codebase.

  • Identify the time when you won't be "rushing" any more. If this is never going to happen, than don't delude yourself too much - you're only ever going to write bad code, and you'll be slow because of that.

    Identify the time when you won't be "rushing" any more.

If this is never going to happen, than don't delude yourself too much - you're only ever going to write bad code, and you'll be slow because of that.

  • writingwrite "knowingly dirty" code with comments, especially documenting any potential "surprise". It's interesting to follow the // TODO(xxx) convention where xxx is your name, acronym, etc... so that coworkers know to ping you when they hit this code later.

(Suggested by other answers). Especially document any potential "surprise". It's interesting to follow the // TODO(xxx) convention where xxx is your name, acronym, etc... so that coworkers know to ping you when they hit this code later.

  • delaying the cleanup ; but it's then critical to set a date fordelay the cleanup, and maybe add it in the code to automate listing your technical date

(Suggested by other answers). However, I would add that it's critical to set a date for the cleanup, and maybe add it in the code to automate listing your technical date

  • tolerate some duplication ; I have yet to find a situation where not factoring a function as soon as you notice duplication was really saving substantial amount of time. However, when you notice duplication, again, it might make sense to document it next to the code (if only, to schedule fixing it)

I have yet to find a situation where not factoring a function as soon as you notice duplication was really saving substantial amount of time.

However, when you notice duplication in other code, again, it might make sense to document it next to the code (if only, to schedule fixing it)

  • aliases and synonyms ; sometimes a code is just hard to understand because naming is poor. This will be controversial, but if your language / IDE does not support renaming function and classes, it can never prevent you from creating aliases purely for naming reason

Sometimes a code is just hard to understand because naming is poor. This will be controversial, but if your language / IDE does not support renaming function and classes, it can never prevent you from creating aliases purely for naming reason

  • Make it clear that expectations are not realistic, and that you're going to produce a sub-par product because you're asked to. Everyone needs to share part of the blame here. (You assume that the conversation has already been had, but in so many cases only half the side really understand what it means)

  • Find ways to ship less. Reduce scope to the bare minimum. Use the acronym "MVP" as much as possible (it subconsciously reminds people of "IPO" in the start-up world, which put some in a better mood ;) )

  • Find ways to ship incrementally. A large part of your "soon-to-be-dirty" code is actually not needed because the business requirements are not clear. If you can implement 10% of the feature in a "quick and dirty way", and make it obvious enough that the feature was misunderstood / not needed, you've spared you and your codebase.

  • Identify the time when you won't be "rushing" any more. If this is never going to happen, than don't delude yourself too much - you're only ever going to write bad code, and you'll be slow because of that.

  • writing "knowingly dirty" code with comments, especially documenting any potential "surprise". It's interesting to follow the // TODO(xxx) convention where xxx is your name, acronym, etc... so that coworkers know to ping you when they hit this code later.
  • delaying the cleanup ; but it's then critical to set a date for the cleanup, and maybe add it in the code to automate listing your technical date
  • tolerate some duplication ; I have yet to find a situation where not factoring a function as soon as you notice duplication was really saving substantial amount of time. However, when you notice duplication, again, it might make sense to document it next to the code (if only, to schedule fixing it)
  • aliases and synonyms ; sometimes a code is just hard to understand because naming is poor. This will be controversial, but if your language / IDE does not support renaming function and classes, it can never prevent you from creating aliases purely for naming reason
  • Make it clear that expectations are not realistic

You're going to produce a sub-par product because you're asked to.

Everyone needs to share part of the blame here. (You assume that the conversation has already been had, but in so many cases only half the side really understand what it means)

  • Find ways to ship less

Reduce scope to the bare minimum. Use the acronym "MVP" as much as possible (it subconsciously reminds people of "IPO" in the start-up world, which put some in a better mood ;) )

  • Find ways to ship incrementally

A large part of your "soon-to-be-dirty" code is actually not needed because the business requirements are not clear. If you can implement 10% of the feature in a "quick and dirty way", and make it obvious enough that the feature was misunderstood / not needed, you've spared you and your codebase.

  • Identify the time when you won't be "rushing" any more.

If this is never going to happen, than don't delude yourself too much - you're only ever going to write bad code, and you'll be slow because of that.

  • write "knowingly dirty" code with comments

(Suggested by other answers). Especially document any potential "surprise". It's interesting to follow the // TODO(xxx) convention where xxx is your name, acronym, etc... so that coworkers know to ping you when they hit this code later.

  • delay the cleanup

(Suggested by other answers). However, I would add that it's critical to set a date for the cleanup, and maybe add it in the code to automate listing your technical date

  • tolerate some duplication

I have yet to find a situation where not factoring a function as soon as you notice duplication was really saving substantial amount of time.

However, when you notice duplication in other code, again, it might make sense to document it next to the code (if only, to schedule fixing it)

  • aliases and synonyms

Sometimes a code is just hard to understand because naming is poor. This will be controversial, but if your language / IDE does not support renaming function and classes, it can never prevent you from creating aliases purely for naming reason

Source Link
phtrivier
phtrivier
  • 229
  • 1
  • 2
  • 6

"Clean code" motto, repeated to the point of ridicule, is that:

the only way to go fast, is to go well

Philosophically, "writing clean code" and "rushing to ship something" are polar opposite.

Some options to compromise on each axis, while keeping options open:

rushing to ship something

  • Make it clear that expectations are not realistic, and that you're going to produce a sub-par product because you're asked to. Everyone needs to share part of the blame here. (You assume that the conversation has already been had, but in so many cases only half the side really understand what it means)

  • Find ways to ship less. Reduce scope to the bare minimum. Use the acronym "MVP" as much as possible (it subconsciously reminds people of "IPO" in the start-up world, which put some in a better mood ;) )

  • Find ways to ship incrementally. A large part of your "soon-to-be-dirty" code is actually not needed because the business requirements are not clear. If you can implement 10% of the feature in a "quick and dirty way", and make it obvious enough that the feature was misunderstood / not needed, you've spared you and your codebase.

  • Identify the time when you won't be "rushing" any more. If this is never going to happen, than don't delude yourself too much - you're only ever going to write bad code, and you'll be slow because of that.

"We're rushing because we have a tradeshow last week"

...can be redeemed in two weeks ;

"We're rushing because our normal process is to cram a large roadmap on a small team with short milestones"

...is called a "death march" for a reason.

writing "less clean" code

Some strategies:

  • writing "knowingly dirty" code with comments, especially documenting any potential "surprise". It's interesting to follow the // TODO(xxx) convention where xxx is your name, acronym, etc... so that coworkers know to ping you when they hit this code later.
// FIXME(bob) This assumes that function X has been called before. This might
// fail if the user has done Y, but this should not happen in production.
  • delaying the cleanup ; but it's then critical to set a date for the cleanup, and maybe add it in the code to automate listing your technical date
// TODO(bob, before: 2020-06) There are no tests at all for the edges cases here
  • tolerate some duplication ; I have yet to find a situation where not factoring a function as soon as you notice duplication was really saving substantial amount of time. However, when you notice duplication, again, it might make sense to document it next to the code (if only, to schedule fixing it)
// DUPE(bob) This is almost the same code as in `SomeOtherModule`
  • aliases and synonyms ; sometimes a code is just hard to understand because naming is poor. This will be controversial, but if your language / IDE does not support renaming function and classes, it can never prevent you from creating aliases purely for naming reason
// Original code
function xty(z) {
 ... 100 lines of undecipherable code
}

// Your code
function mapStandardUnitToImperialUnits(meters: number) : number {
  return xtz(meters)
}
  • if you can devote just a bit more time to cleaning up, "Working effectively with legacy code" has some other techniques. (Isolating dirty modules, strangling code, etc...) but I'm afraid you're not in the situation do this at the moment.

outro

In the long run, you know that you're going to be better off writing the "clean enough" code at a sustainable pace. Try your best at doing that.

Hoping this is just a rough patch.

Good luck !