Your comment made me think Mort represents efficiency, Einstein represents quality, and Elvis represents risk. The ideal combination is difficult, and it changes over time. If anyone knew what the ideal combination was, companies would never fail. Risk can get something started, and lack of it can eventually kill software. In fact, I would argue the vast majority of software we’ve seen so far dies an eventual death due in part to its inability to take risk and change and adapt - it might be not enough Elvis in the long term. Too much risk can kill something before it takes off and can undermine the ability to ship and to ship quality. Generally speaking my gut instinct was to (perhaps like you) align with and defend Morts; the business objective is the only thing that matters and pays the bills, and there is certainly a class of Morts that doesn’t write spaghetti code, and cares about quality and tries new things, but prioritizes work toward the customer and not code wonkery. Anyway… this is too probably abstract to be very useful and I made it worse and more abstract, but it’s fun to hypothesize!

▲

kyralis 9 days ago | parent [-]

Mort might mean short-term efficiency, but those solutions are where technical debt and unmaintainable organically-grown complexity come from. That has its time and place, but it must be balanced to not doom anything but short-lived projects.

	▲	dahart 9 days ago \| parent [-]
		The only place I’ve seen technical debt and organic complexity come from in real life is from over-engineering (Einsteins over-engineer the code, and Elvises bring in too many dependencies) and, more importantly, from changing requirements (customers & PMs & management). The changing requirements is the bigger culprit most of the time, and that doesn’t reflect directly on programmers or programmer personalities. I’ve never seen efficiency arguments make the code unwieldy. If anything, the problem is that real life Morts sometimes under-engineer, and it takes some of the other types to build up a bit. I’ve seen over-engineering far more often than under-engineering. Anyway, Mort only means short-term efficiency if you make assumptions. It didn’t in the top comment, and it doesn’t have to, you can just as easily assume efficiency is long term and includes efficiency of maintainable code and efficiency of business processes. If you care about the business outcome, why would you jump to the conclusion that it’s short term thinking?