Hacker News Reader

Comment by strict9 | Hacker News Reader

>the McKinsey framework only measures effort or output, not outcomes and impact, which misses half of the software developer lifecycle.

>“The McKinsey framework will most likely do far more harm than good to organizations – and to the engineering culture at companies. Such damage could take years to undo,” Orosz and Beck argue.

I would go further and say it will likely damage user experience too. Cranking out features to game productivity scores and ignoring outcomes is a good way to get bloat, bugs, cluttered and overly complex UI, and an overall degraded user experience.

View on HN

I'm very much a hacker myself, but isn't this a little unfair? There is an entire column in the framework described as "Outcome focus" and the items seem to make sense on a first glance.

I'm not saying that the framework is good, but this specific criticism to it seems wrong.

The incentives for software development are somewhat broken.

In the "old" days, there was an infinite amount of basic software to write (Operating Systems, file editors, compilers, etc.) and very few developers working on extremely expensive equipment. They had to write software that would just work, features were added based on need, and the idea of a continuous, high-effort, software development activity for a piece of software wasn't the rule. Once the job was done, the developers simply got paid and moved on. Updating, patching, etc was hard to do.

So the incentive was to deliver high-quality working software that did what it needed to do for decades without there being a continuous development effort to keep it "updated" because you only got paid by moving on to new jobs.

Today, the theme is CI/CD, which translates into "figure out how to keep an overstaffed engineering department occupied long after they delivered the working system". This translates into shipping broken, buggy, incomplete, software with the intention to keep the department occupied over the long-term with bug fixes, patches, feature updates and releases, and probably the occasional all-up rewrite. The industry says that the ideal form of this is to not only push releases every so often but to do it continuously in a never ending unbroken stream of work. But what happens when the software really is "done"?

The answer is that we see it all the time. Often in various forms of enshittification (i.e. rent-seeking). Feature reductions, refactoring parts of a perfectly working system stack, changing languages.

The incentive is to vertically integrate rent-seeking, companies are incentivized to seek new monetization sources (I want to say as a way to grow their business, but often it's to keep paying a crushing labor pool), down to developers who aren't incentivized anymore to ship-and-move-on. We also see other bizarre symptoms like taxi companies writing scalable message passing services and geospatial systems, or social networking companies building state of the art AI systems.

So here's an idea, what if the way it should work is thus?

- Developers are payed by the job, they pre-negotiate the price and the payment cadence (monthly, milestone, etc.)

- Groups of developers could form an Agency if they want to centralize the negotiating and business bits.

- Companies hire developers or Agencies for the job. A certain level of bug fixes are included in the contract. (x-number of months, so many bugs, certain number of hours, etc.)

- Feature updates are new jobs.

- Terms to include: "so long as we continue to use the software on our systems, the developers will get payed residuals." Modeled on how other Agency-based industries like acting or music continues to pay-out for use of the systems.

- Good developers can end up on a big passive income stream, and could either continue working in the industry, or perhaps start spending part of or all of their time working on open-source projects that could provide reuse across projects within their industry.

- The Best developers could go into a company, negotiate a nice contract, and the job could mostly be to yank the code out of a repo, compile, configure and run -- then collect passive income for the next few years as the company gets value out of that simple exercise.

It's not the effort of the developer that bring value to the company, it's the value of the solution, so why doesn't the industry incentivize that?

> Today, the theme is CI/CD, which translates into "figure out how to keep an overstaffed engineering department occupied long after they delivered the working system". This translates into shipping broken, buggy, incomplete, software with the intention to keep the department occupied over the long-term with bug fixes, patches, feature updates and releases, and probably the occasional all-up rewrite

you are looking at it from the wrong end. This model is prefered and delivers better results because nobody was able to say what the "complete" sofware should look like. So better to deliver MVP and ask the users what they want to change rather than develop something for years only to discover that its very bad fit.

> nobody was able to say what the "complete" sofware should look like

We had "complete" software for decades. You can use an iterative development model until all of the major goals are achieved then ship a final product. After that it's just maintenance.

Iterative development has consumed the ship and maintenance parts of product delivery to the point that the industry no longer even can recognize or remember that such a thing can exist.

Enshittification is the result because if you keep going in and messing with a shipped product, the temptation to try to squeeze it for revenue when its market maxes out becomes irresistible. Modern development practices like CI/CD were invented to enable this behavior and really only build value during the earlier core development stages. After that it becomes an extractive process.

It's kind of like how when colonial powers were building railroads in India, or Korea, or wherever. The intention was to use the rail lines to extract resources from the colonized territory, but the side effect is that the local people in the country also suddenly had improved transportation infrastructure and oh yeah, jobs. For a while the people who work on or near the rail line "prosper" but nobody remembers that the goal was to suck all of the lifeblood out of the countryside and move it to the ports. Once the line is complete the model flips to extraction and the development activity ceases, and everybody who had previously prospered because they could use the rail line to get jobs, education and health care wonders why life sucks now.

> We had "complete" software for decades. You can use an iterative development model until all of the major goals are achieved then ship a final product. After that it's just maintenance.

well or its not, depends on the industry but most likely there will be new features etc. You need to be able to ship security features and bug fixes continously - e.g. without manual user action because most users simply don't have mental capacity to upgrade software. Alas continous delivery.

We had "complete" software in the same sense that we had "complete" technology when we discovered fire and caves. There is always something that can be improved or optimized further, although it may require rethinking the problem.

"then" or "than"? Both sentences plausible depending on perspective.

than sorry

> Today, the theme is CI/CD, which translates into "figure out how to keep an overstaffed engineering department occupied long after they delivered the working system". [...] with the intention to keep the department occupied

I disagree on this causal part: That malaise does not exist because Machiavellian engineers created a job-security program stealthy enough to persistently escape action from bean-counting executives.

Instead, it's caused because other business stakeholders are paying a premium in order to avoid deeper commitment of some sort.

A few examples:

* They want to avoid the risk of a big innovative product that may be a similarly-big flop.

* They can't bear to drop any customers by streamlining the product, always adding bells and whistles to appeal to the potential client du jour.

* They are unable/unwilling to spend/risk political capital in substantially altering how their own corporate structure operates.

* The company's leadership isn't capable of making different business-units work in harmony so the software becomes a slow battleground/mediator of their competing interests.

I actually don't disagree with you on any point. But I do think the relationship can become an unhealthy codependency that causes organizations and developers to lack the discipline that would be more ideal.

You are definitely reinventing something that already exists: Consulting. I worked as a consultant on projects in a model similar to the one you describe in the early 2000's.

This does work. It just requires a sales staff. And usually a 'bench' (the ability to pay developers in-between jobs).

And to be clear: it's only one way of approaching the current set of problems caused by well-intentioned management consultants.

FYI: The cult-classic movie "Office space" actually dealt with what the fallout from management consultants looks like (specifically with software development)

Do you continue to get residuals long after you've left a job?

In most agency-based industries, the workers don't get paid between gigs, only during. Good workers hunt around for good agents, and they can make massive amounts of money per job with the agents getting a handsome cut for their job working as sales staff.

I think the second that you need to do maintenance on the system, you've nullified the "as long as we continue to use the system" term. There is a strong argument to be made that it's a fundamentally different system after you make changes.

There already are contractors, who at least in my company are used to build new systems and bring in new ideas. So them and interns do all the ground breaking new work, while us regulars end up maintaining and extending legacy systems.

that sounds horrible, maintenance is the worst part of software dev

It's not the most exciting thing out there, but the hours are good and the pay covers the bills. In these times it's also rather safe place to be.

It could be more interesting, but then again, it's just work.

Why do you say that?

I think it depends a lot on the developer. But it _also_ depends on the company. "The work that isn't appreciated" is commonly the worst type of work; and maintenance work falls into the bucket in a lot of companies.

people are frequently quite bad at writing code to be read, so actually understanding what's going on can be a mess.

> CI/CD, which translates into "figure out how to keep an overstaffed engineering department occupied long after they delivered the working system".

CI is only about what happens before software is delivered.

And I don't see what CD has to do with staff size.

I think you're pointing out valid problems and misattributing their causes.

Making an example up that I don't know to be true, but please just go with it:

Google likely has a dedicated team who do nothing but tweak the front page of www.google.com

I bet there's a Kanban-like board somewhere within that team with tickets like "change the button for image search to new branding icon" and "move the "About" button to the left-most upper corner from the right-most upper corner." "Make the corners on the search box more round" or whatever.

Looking at the page now, somebody definitely had to generate work, and some poor front-end developer definitely had to perform the work to put the "Our third decade of climate action: join us".

Every couple of years the team will take on some kind of task like moving the front-page to a new internal framework, or connecting it to some new search/advertising API. Remember when google would show real-time search results as you typed?

"Let's put a Pacman game as the logo!"

Here's Google's front page from 10 years ago https://web.archive.org/web/20130101000532/http://www.google...

Somebody is making those changes, they exist. The decision to CD that page keeps them around.

However, there is effectively almost no perceptible difference in the program performance, features, capabilities, or really even the aesthetics of that page in that time period to the user.

It should be on maintenance mode with checking in on it being a part-time job for a single person. I bet that there's more than a dozen people who's sole job it is to keep that page "fresh".

That's how CD results in inflated team sizes -- it's the "C". CI/CD never makes it over the wall into CM (continuous maintenance) and as a result becomes it.

Well, looking into bookish definition of CI/CD will not help here.

In real world I regularly CI/CD pipelines reflects to delivery/product managers how fast features are churned out by team to be presented to business. A 10K ft view of CI/CD is often used by group leads, executives to show whats being achieved even at company level.

CI/CD is making sure your code is always in a production ready state and validating with tests and other tools automatically.

Okay. So?

JIRA is supposed to track work that is to be done. Now JIRA is used to generate work when none exist because if there are hundred JIRA ticket resolved this week there must have lot of work done.

You make valid observations but you conflate issues. Continuous development is not a problem per se; overdevelopment is. Companies need to be able to say when something is done, put on maintenance mode, and move on to something else. One problem that you did not mention is that business incentives can run counter to product demands; ticking more checkboxes just sells better with certain kinds of buyers. Many companies have not sown the seeds for new products to shift resources to; one trick ponies are the order of the day. So that would mean shedding staff, which looks bad for the company, and is bad for the workers' jobs :)

I don't really disagree with any of your points either.

> one trick ponies are the order of the day. So that would mean shedding staff, which looks bad

What I think I'm arguing is that most companies really don't need dedicated full-time staff in that way. Agency models work well in many industries that are built around one-trick ponies, which I'm arguing is what most development really is.

In those industries there really isn't a negative connotation to ending a project, shipping it, saying goodbye and thanks for the hard work to the team who did it. If they did a good job and the activity was successful, many of them will likely be hired back for the next job anyways.

Great points here.

With exception of perhaps top end of successful commercial products or some usable patents during development of technology most developers do not get any passive income no matter how much good work is delivered over decades. Everyone is just about as good as their next JIRA task completion. This all just means half-assed broken, bloated feature deliveries which is to be fixed in next scrum or whatever.

Reply on news.ycombinator.com