5 ms·

More people should focus on the following, in my humble opinion: - be consistent and reliable - learn about your company's business goals - focus on deliveri

• iliaznk 8y ago
  Just wondering, in terms of value for the business, doesn't clean code always deliver a higher value as opposed to, say, messy code? Being easier to maintain and debug, and also likely to contain less bugs thus being more reliable, do those qualities provide value by themselves? I realise that, from a business' point of view, how fast something is done may be more valuable than how clean, but at the end of the day a "faster" code can eventually take longer to reach a production-grade reliability... Isn't that true?
  • btschaegg 8y ago
    Edit: Obviously, I'm not GP, but here's my take on this. > doesn't clean code always deliver a higher value as opposed to, say, messy code? I'll agree with you there, but I'm under the impression that the phrase "clean code" is somewhat too ambiguous. Coding style per se is very subjective anyway, so obsessing over it propably is not a good thing in most cases, yes. But if the "quick and dirty" approach also influences the architecture of what you're developing (i.e. it also affects other code) I'd very well argue that taking a stand against it is a good thing to do. On a similar note: I find the notion of "technical debt" to be quite useful in a lot of ways: By taking the short path, you'll be forced to make up for it at a later date, be it through slower development, a lack of reliability or the necessity to clean up the "hacks". Where the metaphor breaks down (and seems to be contraproductive) is that it leads many business people to assume the debt (i.e. the negative impact) will be easy to quantify and can be treated like some other expense (and thus it often is ignored for far too long). So, the first thing I ask whenever the "business side" asks for a quick and dirty fix for something (often mainly because of some production issue) is "When and how are we going to fix this properly? How will we deal with the downsides in the mean time?". This usually achieves my goal of making them think about the implications more -- I don't believe that's a very viable strategy in bigger companies, though.
  • wjossey 8y ago
    As the other response stated, it depends on what you mean by clean code. When used in a positive sense, “clean code” just means well written code that’s easy to reason and maintain. When referenced in the pejorative sense, it means “overly engineered”, or potentially that the author of the code spent an excessive amount of time writing something that could have been done much faster. As for whether or not clean code always delivers higher business value, the answer is no. Businesses rarely deal in absolutes and clean code is not always better. Business and engineering is just a huge game of trade offs, and code quality is just one knob you can turn up or down when discussing priorities for you and your team. Is it one you should frequently sacrifice to accomplish company goals? No. But, sometimes it makes sense.
  • oldboyFX 8y ago
    > Just wondering, in terms of value for the business, doesn't clean code always deliver a higher value as opposed to, say, messy code? Of course it does, and writing clean code should be one of your goals. But it should never be the primary goal. You always want to be aware of why you're being paid: it's to deliver value and increase profits. Maintainable code is important, but our thought leaders have been putting the idea of clean code on a pedestal lately. Because of this I feel like many developers sweat over minute technical details but completely ignore business goals.
  • goto11 8y ago
    "Clean code" is not some objective quality though. Does say the open/closed principle lead to clean code or to overly complex code? It depends on the use cases for the code which in turn depends on the business goals.
  • throwaway98121 8y ago
    Clean code is an ambiguous and subjective concept. Assuming you’re referring to the practices taught in the book, I disagree that it always delivers a higher value than messy code. I worked with a code base recently that on the surface checks all the boxes, but honestly, the code was way over engineered for the problem it actually solves. The team itself was great at writing clean code, but they over indexed on it to the extent that they were paralyzed and couldn’t actually get anything out the door. Honestly, they don’t know how to deliver. I would prefer a team or even one decent engineer who knows how to make trade offs. Instead of only optimizing your logic, also invest time to figure out how you’re rue going to deliver. Make sure there’s instrumentation and metrics. Load test your system and understand your dependencies and their limits. Do they need to scale too? What hardware do you need? If your traffic calculations are off and you have problems, how quickly will you be able to get back into your SLA... speaking of, what is the SLA? Have you built your run books? If dependency A fails or if this part of your architecture fails, what happens? Did we failure test? How many calls will this system get per second? Will it be sustained or bursts? Thinking of software only as a code style optimization problem doesn’t work, unless you’re in an organization where developers are explicitly code monkeys.
• dsies 8y ago
  I couldn’t agree more with all points. One thing that strikes a nerve with me is attachment to code - you will have a whole lot less stress if you stop that. Your code is not your loved one - it is means to an end. If it has served its purpose - throw it away and don’t dwell on it.
• MichaelMoser123 8y ago
  # don't get emotionally attached to your own code or a piece of technology I don't know, i think if you don't care about your stuff then you are probably not too good at it.