4 ms·

As a consultant (not the OP) one of the best parts of writing code is having it solve real business problems (and getting paid well for it). It's a point of pe

As a consultant (not the OP) one of the best parts of writing code is having it solve real business problems (and getting paid well for it). It's a point of personal pride to write reasonably good code, but the structure doesn't matter to the person paying the bills - the outcome does. It's like living in a house: as long as it doesn't fall down and doesn't cost unreasonable amounts to maintain, I don't really care about how well-formed the mortar is, or that the drywall is hung perfectly according to company standards. I just want to live in the house and not worry about it.

SahAssar 7y ago
Well, what I'd say to that is: * Somebody maintains that code. If it is only you you have a bus-factor of one if none of it is actually reviewed. If it is not you you are imposing a single persons idea of what the business problem is and how it should be solved on the maintainer, which they might not agree with * Personal development depends on realizing when you are wrong or have used the wrong tool. If nobody challenges your decisions you will probably not realize that as often (or at all) and therefore not improve as much. * Solving business problems means solving problems for a business. Usually businesses evolve over time, so the business problems might change. Who will understand the code in that case? How do you know the code is understandable to other people if nobody else reviewed it? And as for the house example: before buying that house I would definitely hire somebody else to check it, and that is legally required in some countries. I don't trust anyone to rate their own work. In this case the person who hired your consultancy bought the house, and they should definitely have an expert that did not build it check it. --- Just a FYI: I'm also a consultant, but work on a project where we have discussions about how to structure the code and do code reviews and so on.
- kareemm 7y ago
  Yes yes, I agree with all that. I much prefer to discuss approach with someone senior before tackling hairy problems and have others look at my approach after the fact to improve. But since I often work with clients where I am the dev team, I rely on my professional network to discuss approach. Agree that getting a technical review from a third party isn't a bad idea. FWIW this doesn't change my main point: the business owner cares about outcomes, and not code structure (a good outcome is dependent on the code being good enough to maintain e.g. the house not falling down). There's a simple test for this BTW: write lited, beautiful code that doesn't solve the business problem you were hired to solve and see how popular you are with your client.
dwild 7y ago
The structure does have an impact on its maintainability though. You said you don't care about well-formed the mortar is or how the drywall is hung, but would you care if it was made in a way that would make it much harder later on to run new wires inside the wall? I would care personnaly. > writing code is having it solve real business problems Sure, but writing good code is about solving future problem the business is going to have too. A problem has more than a single dimension. If your code will never evolve, if it's a definitive solution to their problems, the structure doesn't matter that's true, but sadly, that's almost never the case.
alfalfasprout 7y ago
It's like building someone a house where the design is flawed and someday it'll fall down and kill everyone. By the time it happens, you'll be long gone. Doesn't mean it's the right thing to do.
dragonwriter 7y ago
> the structure doesn't matter to the person paying the bills - the outcome does. The structure matters to the outcome; but the outcome problems of bad structure tend to manifest after paid-by-engagement contractors have left.

SahAssar 7y ago

Well, what I'd say to that is: * Somebody maintains that code. If it is only you you have a bus-factor of one if none of it is actually reviewed. If it is not you you are imposing a single persons idea of what the business problem is and how it should be solved on the maintainer, which they might not agree with * Personal development depends on realizing when you are wrong or have used the wrong tool. If nobody challenges your decisions you will probably not realize that as often (or at all) and therefore not improve as much. * Solving business problems means solving problems for a business. Usually businesses evolve over time, so the business problems might change. Who will understand the code in that case? How do you know the code is understandable to other people if nobody else reviewed it? And as for the house example: before buying that house I would definitely hire somebody else to check it, and that is legally required in some countries. I don't trust anyone to rate their own work. In this case the person who hired your consultancy bought the house, and they should definitely have an expert that did not build it check it. --- Just a FYI: I'm also a consultant, but work on a project where we have discussions about how to structure the code and do code reviews and so on.

kareemm 7y ago
Yes yes, I agree with all that. I much prefer to discuss approach with someone senior before tackling hairy problems and have others look at my approach after the fact to improve. But since I often work with clients where I am the dev team, I rely on my professional network to discuss approach. Agree that getting a technical review from a third party isn't a bad idea. FWIW this doesn't change my main point: the business owner cares about outcomes, and not code structure (a good outcome is dependent on the code being good enough to maintain e.g. the house not falling down). There's a simple test for this BTW: write lited, beautiful code that doesn't solve the business problem you were hired to solve and see how popular you are with your client.

dwild 7y ago

The structure does have an impact on its maintainability though. You said you don't care about well-formed the mortar is or how the drywall is hung, but would you care if it was made in a way that would make it much harder later on to run new wires inside the wall? I would care personnaly. > writing code is having it solve real business problems Sure, but writing good code is about solving future problem the business is going to have too. A problem has more than a single dimension. If your code will never evolve, if it's a definitive solution to their problems, the structure doesn't matter that's true, but sadly, that's almost never the case.

alfalfasprout 7y ago

It's like building someone a house where the design is flawed and someday it'll fall down and kill everyone. By the time it happens, you'll be long gone. Doesn't mean it's the right thing to do.

dragonwriter 7y ago

> the structure doesn't matter to the person paying the bills - the outcome does. The structure matters to the outcome; but the outcome problems of bad structure tend to manifest after paid-by-engagement contractors have left.