40 ms·

Possibly a way to say YAGNI which is easier to relate to. Don't build stuff unless you are suffering, and hence understand the problem domain. Do the "easiest

Possibly a way to say YAGNI which is easier to relate to. Don't build stuff unless you are suffering, and hence understand the problem domain. Do the "easiest thing that could possibly work" and then don't change it unless you see a problem with it. Even if there are better ways to do it, if you aren't experiencing a problem, then there is no point in changing it. Don't fix problems you don't have :-) On the other hand, this requires a considerable amount of discipline. It is easy to procrastinate. You think, "Oh we are suffering here, but it's only one small thing, so it's not too bad. Plus we're super busy adding these other 100 features". Then there are 2 small problems. Then there are 10. Then 100. Pretty soon, the amount of time necessary to fix the problems you need fixed exceeds the amount of time that you can spend without losing business. So you prioritise the worst issues and work around the others... The workarounds cause more issues and because it's a network effect, the software starts to degrade in a non-linear way. After a while, you are spending entire days reading code just to make sure that a few line change won't break something. It's not a panacea. You still need a lot of experience... and for want of a better term, good taste.

colechristensen 8y ago
>Don't build stuff unless you are suffering That strikes a good chord, thanks for the concise response to excessive abstraction evangelists.
kradroy 8y ago
The experience part is key. I have junior engineers who implement solutions without understanding the whole they're adding to. They end up believing they're peeling an onion and start crying. There is no onion. It's a potato; peel it and throw it in the pot! It's difficult to tell them that they're not suffering though. I've sat many down to explain that we don't need containerized components and rearchitecting into an SOA with a blue-green deploy model. They protest nonetheless. But what do I know after 15 years of engineering? I surely know that our customers' suffering caused by their relief of suffering will make us all suffer more.

colechristensen 8y ago

>Don't build stuff unless you are suffering That strikes a good chord, thanks for the concise response to excessive abstraction evangelists.

kradroy 8y ago

The experience part is key. I have junior engineers who implement solutions without understanding the whole they're adding to. They end up believing they're peeling an onion and start crying. There is no onion. It's a potato; peel it and throw it in the pot! It's difficult to tell them that they're not suffering though. I've sat many down to explain that we don't need containerized components and rearchitecting into an SOA with a blue-green deploy model. They protest nonetheless. But what do I know after 15 years of engineering? I surely know that our customers' suffering caused by their relief of suffering will make us all suffer more.