[gorpomon]

Overall I like posts like these, as they are a reminder that you're not really paid for agonizing over eloquent or great code, but just code that "gets the job done". But then if you over-index on this viewpoint, you'll end up needing posts which remind you that this is a craft and that code needs some agonizing over.

What I've been pondering lately is another way to sum this up that is more future focused: Let's say a genie walks into your project and says that you can have 1.5 times the features you have right now, for 3x the code. The genie promises that the code will be "alright, maybe just kind of a bit bad". I think around 2/3 of developers would say no, but I suspect 2/3 of people in product management, sales, marketing, etc would say yes. Everyone would be sympathetic to the problems this would create, but the allure of getting 1.5X ahead on your roadmap is probably too hard to ignore for those other disciplines. It's basically accelerating all your other work streams by 1.5, at the expense of potentially bogging down dev. Obviously, countless caveats exist, but it does in general feel right, and feels like it hints at the fundamental causes of tension between business and development.

[tristor]

Speaking as a PM and a former Eng, if you could get 1.5x your features at this trade-off, the topline revenue that those features drive could very likely result in significant additional resources to provide to dev. I realize you can chase your tail with tech debt, but you're calling this "alright" code, not horrible code. I'd take that trade-off in either role I had.

[zer8k]

That's your PMness speaking.

PMs never consider who will manage the code down the line. They never consider the implied difficulty multiplier because if you can't party poker it, you can't build it! That's what the agile ninjas say! Code that is "kinda bad but ok" will end up being the cause of a SEV0 eventually. This kind of tradeoff is made by management because the entire field of software engineering is a joke to them.

There's a trade off to be made. But it isn't the one posited. Creating code that is manageable implies it's better than "kinda bad but ok" but not all the way to a magnum opus in software engineering.

Leave decisions like these to the engineers. If management isn't willing to give "significant additional resources" to engineers they get what they pay for. Enjoy your extremely high turnover. Of course, it'll never be your fault. The engineers will also suffer the consequences. It would be nice to see even one PM eat shit for their terrible project management decisions done in the name of "agile".

[tristor]

This rant doesn't seem to address my comment, and seems to be an expression of your existing anti-PM bias.

[deepspace]

> Leave decisions like these to the engineers.

Maybe for a 1.1x increase in features, but for 1.5x (provided the new features solve actual customer problems), I will choose the genie every time. /PM

[Apes]

1.5x the features, 3x the code would roughly result in 1/3 development velocity, 3x bugs, and 3x incidents going forward.

Even assuming all your developers are magically given a solid understanding of the new code, all remaining velocity will be entirely consumed by bugs and incidents. No more feature development will occur.

You could try to grow to outrun the code debt you've just acquired - but that's what literally every start up tries to do, and less than 10% succeed.

The most likely outcome is that the company would enjoy a one-time massive feature feast before slowly dying over the course of 5-10 years or so.

Great if you're a founder looking for a quick exit or some other position that is super focused on short term growth, I suppose.

[etblg]

> significant additional resources to provide to dev.

Ah sweet, even more problems to deal with then. More people to onboard to support you in writing the 3x more code, more managers needed, or more strain on the managers, etc. We'll just fix it by hiring even more people.

[tristor]

> Ah sweet, even more problems to deal with then.

Whether or not adding more people is a problem greatly depends on the existing workload and where in the development cycle those folks are added. It also depends on the quality of the people. My comment was certainly not advocating for putting more meat into the grinder in favor of chasing the mythical man month.

My point was more that if you can magic your way into 1.5x the features for 3x the code, and it's "alright", you can probably add 1.5x to the top-line revenue over the same time frame. A 1.5x increase in top line revenue, especially at a larger organization, is absolutely massive and opens up many possibilities, including hiring significant additional headcount. The headcount comes in /after/ this magical moment, not prior to or in the midst of. And yes, if you have 3x more code, you'd probably want more people to help manage resolving technical debt, fixing bugs, and generally dealing with the ongoing keep-the-lights-on work that is inherent in that.

[HWR_14]

I'm amazed that as a PM you think features linearly drive revenue. This has not been my experience.

[tristor]

It greatly depends on what the "features" are. We're being intentionally very hand-wavy here. If you are adding features that are incremental for existing customer markets, then of course it's not going to drive linear revenue (it may not even drive /any/ additional revenue), but if those features open up new markets and use cases it can grow revenue beyond linear for effort. It all depends, and we're not being specific enough to say one way or the other since this is a contrived hypothetical with vague inputs.

[jashmatthews]

Engineering output doesn't even scale close to linearly, though. You _might_ grow revenue 1.5x but now you have 3x as much code/system and need 6-9x as the engineering headcount.

We probably just took a nice small/medium profitable business and completely fucked it.

[commandlinefan]

> more problems to deal with

But that's not _his_ problem, and he already got his bonus for "hitting the date".

[szundi]

Of course you can always run out of time and go bankrupt and these people could go to other companies to work on a probably even worse codebase. Also everyone lost years of their lives chasing the CEO into perfectness

[thayne]

Even if the code is the same quality as existing code, having 3x of it will slow down development considerably. And will probably make developers less happy with their jobs, and increase churn. And hiring more devs will initially slow down development even more.

[woleium]

Alright code is a step up for some projects I've seen, lol.

[vsareto]

Our field’s (lack of) training sucks at teaching good code though.

Plus some styles have changed over the years. If we keep changing quickly, good code is just a fad.

[szundi]

Exactly

[gymbeaux]

If I had a dollar for every time a SWE was promised “resources” to address tech debt I could probably retire. If you’re “not that PM”, good on you, but any seasoned SWE hears “we’ll address the tech debt {in the future}” and either laughs or cries on the inside.

[thfuran]

For most anything but a very new project, 1.5x the features isn't just advancing the roadmap, it's hitting the end and not stopping. At work, that'd probably be something like five years of work poofed into existence. Getting that for free is absolutely worth a fairly large amount of mediocre code.

[pdimitar]

That's generously assuming that the executives will accept stopping of adding new features. Even more generous assumption is that they will give engineering time and space to grasp the new code and make it more maintainable.

They always move the goalposts.

[wbl]

How much does it bog down? If for the next two years you're adding features at half the rate but you got a five year boost you're still head and some of that work can simplify the situation.

[gorpomon]

Yeah that's the thing, it's hard to say how much you are bogged down. As time goes on the value of the 1.5x multiplier increases in value, but then you also run the risk of massive spaghetti code (more or less, depends on what the genie considers good).

I don't know if there's great value in trying to figure out if you would quantitatively get ahead though. I think the value is in just realizing that some groups are inclined to perhaps take that risk, and some groups are not.

[josephg]

If your code has increased by 3x, that means 2/3 of the entire project is unknown to your developers. It’ll take a lot of work to just get everyone across that much extra code. To say nothing of how much work it would be to tame it.

I agree with the GP. Business people would probably salivate over this, but if it were up to me I’d want to say no.

[teaearlgraycold]

The code needs to work, but given that the actual writing of code is not most of the work to be done I think it's worth the extra time in polishing the code. Like how Apple designs the internals of their products to look as good as the externals. Once you've spent billions on R&D for custom chips, PCB layouts, optimizing heat transfer, etc. you really owe it to your product to spend a couple million on the finer things.

Likewise, there can be an attitude of "Who cares about the code? I met the needs of the feature" that some devs will have. I've spent many an hour reading others' code, re-reading my own code over and over to learn the subtle differences in readability, cleanliness and maintainability between approaches. I want others to have some craftsmanship when writing code if we're working together. That also means getting the little details right in the user-facing parts.

Most importantly you need humility when it comes time to throw away the code you felt so good about. All code is trouble. The best code is no code. Don't let your well crafted code get in the way of deleting what needs to get deleted.

[yowlingcat]

I have found it's more practical to invert this train of thought and work backwards. In most codebases I've worked in, there are fairly clear divisions of labor between vanilla line of business code and critical path code that merits extra infrastructural investment.

Working backwards from the critical path code to reinforce it with the infrastructure it needs to support robustness and ease of maintainability is valuable because it makes the path to ROI for the business very clear, and candidly, there is often lots of code that just wouldn't be high ROI to reinforce too much.

[notShabu]

as a counterpoint, this is sorta similar to how Apple creates products:

there's quote about magic:

> Sometimes magic is just someone spending more time on something than anyone else might reasonably expect. - Teller

The 3x code is all the magical "stuff" and that goes on in the background to create the illusion of something magical just working as well as non-essential "flourishes" like animation of different font support

However the key difference is that one magical feature is worth more than 1.5x a list of features to sell to various customers who only care about a different subset of those features.

In both cases though, it's understood that there is an additional burden of complexity and upkeep in order to achieve an end goal. Every line of code adds additional entropy to the system until it caps out based on whatever rate of entropy expulsion the culture can maintain.

The diminishing return on additional lines of code may be an unavoidable part of large systems. So it always feels like returning to the "Beginning" via a new project or new startup increase agency and leverage. Which is then perceived by marketing/sales/etc... as a constant refusal to move into the "future" b/c of "bad code danger".

[tmpz22]

The problem is tech debt blows up sometimes. Maybe a critical engineer quits. Maybe there's a big outage. Maybe a big client churns because they've run into one too many points of friction.

There absolutely is a time and place to ship "good enough code". But we have to factor in that for every ounce of credit a dev gets for shipping early there is three ounces of blame for when it goes way wrong.

[niedzielski]

Thanks for positing this thought exercise. You kept me thinking on it all week! I reworded the hypothetical slightly to avoid magical loophole thinking and posed it to my team but they assumed I was being a trickster anyway. I posted some of my thoughts on it here: https://niedzielski.com/log/2023-08-20.

[webnrrd2k]

I think that taking the bargain would depend on the project... If it was software for a product that was on the market and had a lot of competitors, then it's a good deal as it would allow you to get ahead of the competition. Or, say, it was a new market and the features allow you to establish a strong lead. I'd definitely take the deal and then set up a team to do a refactor/rewrite or something.

If the deal was used on internal software that already did it's job relatively well, then it's probably not worth the long-term trade off.

I think that your larger point still stands, that most business people don't care about software engineering issues, but just want features, or solutions to problems, or whatever. Negotiating those issues in a business can be tough.

[patrick451]

Knowing what quality of code to ship when is part of the craft. This skill applies to a lot of professions. No carpenter puts the same detail into framing that they do into stain grade trim. Nor will they go furniture grade fasternerless install in a cheap tract home.

This isn't a revolutionary idea, but for some reason, software devs suffer from an excess of black and white thinking. Things must always be done a particular way. It's such a bad tick, we have created a host of tools that try to enforce as much rigid uniformity as we can manager to automate.

[m_0x]

You're stating

> you're not really paid for agonizing over eloquent or great code, but just code that "gets the job done".

Somebody might interpret this statement as if nobody (in their context) should worry about writing good code. If you're writing good or bad code it doesn't matter as long as it works. Package and ship it and call it a day.

But the author addresses this:

> It's not even about good work. This is also a given. That's the default expectation, it's part of the package. The cake will be good.

Then I'd say that you're paid for "good code that gets the job done".

[biogene]

>Somebody might interpret this statement as if nobody (in their context) should worry about writing good code.

The comment you quoted refers to great/eloquent code. But you took it to mean something different.

Given the rehashing of these same memes in dev communities since the dawn of programming, I don't believe there is a strong agreement on what "good code" even means practically speaking, even though we mostly agree on abstract principles.

IMHO, I think there is an understandable hesitation among developers to accepting that they're doing 'job for hire' work, instead aligning more with the idea that they're put in charge to produce something "beautiful".

Ultimately, it's all messy machine code with goto's and jumps everywhere and "elegant" data structures turning into bits mashed together in memory. The comments, naming conventions, coding formats, etc are all long gone.

This is in stark contrast when producing something physical where the finer engineering aspects shine through in the final product.

[broken_clock]

Doesn't this depend heavily on the scale of the company you're at?

At Google taking this is a no-brainer since for a myriad of reasons, feature development is slow.

At a 6-mo startup this much tech debt this early on might just kill it.

[awkward]

Reading this, I am absolutely sure that several of my former employers have done a little djinn based outsourcing.

[gymbeaux]

People are taking this comment literally and ignoring the spirit of it e.g. “for 1.5x I would but not 1.1x”… okay fine, what about 1.2x? The number doesn’t matter… the point is that SWEs care about code quality more than PMs and other non-devs ever will.

[Justsignedup]

I think about it in stages. What do we need more? To get shit done or to maintain. Great code helps with maintenance. Shit code can help ship fast.

Your goal is to decide when to go from ship to maintain. And what level of quality should be the base level regardless.

[brightball]

One thing that you do get paid for is productivity, which has tradeoffs if you're not agonizing over maintainability that will eventually catch up to you.

[sbjs]

The second best code is the code that gets the job done.

The best code is the code that also doesn't make it harder to continue to get the job done.