Hacker News Reader

> It does bring results, but I feel there are significant costs; usually difficult to measure.

This is my big gripe with the "data-driven cargo cult". It completely disregards the qualitative, and focuses solely on things that are easy to measure. The problem is that some of the most important properties are hard to measure. Optimizing on data feels good, but refusing to make decisions on critical parts of your business that are hard to measure will lead to suboptimal outcomes.

What gets measured gets done, which is awkward when the important things are hard to measure and don't get measured.

"data-informed" is preferable to data-driven, but requires more thought unfortunately.

I have seen the Lean/Six sigma people trying to apply manufacturing principles to software and it's the main reason I left my previous employer. For things to be measured in a way that can be compared, things need to be standardized. In manufacturing, you have a standardized product that you can improve upon. All sort of things are being repeated exactly the same way. In software, we have repeating ourselves. There is no process that can be measured in a similar manner.

Well...

You're right, of course. Development by definition requires novelty. If we just built the same thing over and over, we wouldn't be developing. We'd be manufacturing.

But development still does entail repetition on some level. We pull features through the implementation process, over and over again. We review code, over and over again. We hold retrospectives, over and over again. We do status updates, over and over again. We make supposedly backwards-compatible changes, over and over again. We deprecate features, over and over again.

If you look, you can find all sorts of things that repeat.

These things can actually benefit from being standardised. Standardisation does not mean preventing any future changes; it means doing things consistently, and systematically evaluating and implementing proposed improvements.

But why bother? You can't improve anything unless you can do it consistently. You avoid spending creative energy on repetitive processes, and can use it where it matters: on the actual development. You can learn faster what does and doesn't work, because everyone does the same thing on the same schedule.

A big difference between software and hardware, is that Development, Manufacturing, and Distribution are pretty much all the same thing.

One person can create, duplicate, and distribute earth-shattering functionality. They can then, iteratively, improve or alter the product, almost in "live" fashion.

Manufactured goods have a lot of constraints that come from rather immutable structures; like the laws of physics. There's usually a number of parallel engineering efforts that converge, and that's before the product even rolls off the assembly line.

Once there, it still needs to be placed in position to be accessed by the end users.

Each of these steps are quite different from the others, and require a confluence of disciplines, skills, and experience. Many of them can be subjected to measurable process. Maybe only the initial engineering step could be fairly compared to software development. Even then, prototyping introduces some considerable structure.

Software throughput may not be quite so standardized, and that might prevent you from applying every single nitty gritty specific improvement that someone found in a maufacturing-oriented LSS implementation. But there are still things you can meaningfully quantify.

The thing that Kanban software development chooses to focus on, lead time, would be my top candidate. That seems universal. I'm guessing most others would be team-specific things that come out of a DMAIC analysis. If you've got a problem with too much rework due to team miscommunication, the specifics of how you measure that are going to depend a lot on how your team defines rework in the first place.

> I have seen the Lean/Six sigma people trying to apply manufacturing principles to software

That's great. It tells you which stock to short.

There is a constant tension in product development between delivering value and creating reusable knowledge.

Creating reusable knowledge is not in itself wasteful, but neither will it in itself deliver value. (The reason we do it is because it makes value delivery more efficient in the future.)

Many people today will emphasise delivering value and sacrifice reusable knowledge. They will call it "wasteful" to create reusable knowledge, but it's not.

The trick is finding the right balance, of course.

I think we need to develop a notion of 2 sided value: there is value in delivering additional profit/revenue, but there's also value in reducing costs. Creating reusable knowledge is an example of reducing (the expected) cost.

Correct. The Ward approach to product development accounts for this. He suggests that the organisation structure should reflect that tension. Here's how:

Functional departments and their managers are responsible for creating reusable knowledge. A project leader (chief engineer, in Toyota speak) is responsible for delivering value in a particular project.

The project leader accomplishes their goals by help from the functional departments. However, the project leader has no formal authority over the engineers in the functional departments.

In other words, there will be a constant negotiation between the project leader who argues for something to be designed for a project, and the functional department which must be convinced it's worth spending time to do that thing.

The way a Toyota executive put it was "A great car is made from lots of conflict".

I'm not doing this approach justice in my description. I suggest just reading Lean Product and Process Development by Allen Ward. Lots of good ideas in it.

The organisation structure of a car maker can be seen in a car dashboard. There is a light for the tyre pressure gauge because there is a business function for "tyres".

Changing that is hard. Tesla has a screen where software decides what lights to flash - and dollars to doughnuts it's because there was not dozens of decades old business departments fighting to keep control.

And the example you have above - a Product manager persuading functional teams is a separation of powers problem - think of the US government as a surprisingly long lived example

One would need a lot of top management support to keep that from falling into one of two more stable systems - either the functional team leader tells the PMs what they are going to ask for, or the PMs get hold of budgetary control

Either way the conflict is resolved.

I was just pontif- er...talking about this, yesterday.

I am not a fan of the "MVP" concept, as it is defined in the software startup industry. I feel that it delivers time-delay disasters.

Mostly, because of the deliberate, and premeditated, willingness to ablate Quality, in a drive for deliverable.

We get bad stuff, fast. All too often, that bad stuff forms the nucleus of the product, for the rest of its lifetime. Basically, a foundation of sand.

It's hard to argue against the "dollars and cents" rationale for it. People make money, this way; lots of money.

As long as money and profit are the main measure of success (and it can be argued that they are the only ones that matter), we will have this drive to deprecate Quality, in favor of profit.

Quality is expensive. Real expensive. I've talked about this before.

But I've worked for hardware companies, for most of my life, and it's fairly rare, when hardware companies can get away with it; often, because laws and regulations. Also, tooling up a product line is a major commitment. You really don't want to cheap out on that. Distribution channels are also some heavy-duty overhead.

For whatever reason, software shops believe that we are exempt from the restrictions that have governed all engineering; throughout history.

In a way, this is true. Software is not hardware, and requires a drastically different approach. I always had a devil of a time, convincing hardware people of this.

On the other hand, I don't like the idea that we are also exempt from the requirement to deliver a baseline level of Quality.

Personal gripe. I'm an old curmudgeon.

This is an all too common misunderstanding of what an MVP is.

A bad MVP is a bunch of features thrown together badly in the hopes that parts of it will match market demand and that the market is willing to look past the quality problems. What follows after moderate success with this approach is a long journey to try to build back in some of the quality that was avoided at the start. The end is predictable: sprawling, mediocre software. With some luck it makes money. Often it does not.

A good MVP delivers a single, deliberately chosen feature to a well-researched segment of the market. This single feature has excellent quality characteristics and blows any competition out of the water. On that success follows continued incremental, high-speed development, always with quality as a primary driver.

But it takes discipline. In order to economically deliver quality, you must do the research, and you must be willing to deliver in really small, very well chosen increments.

And that is hard. That takes excellent developers. It's easier to just throw something together and hope to get lucky.

Well, I'm not sure that I "misunderstand" "MVP," because, after the dust has settled, and the smoke has cleared, a significant percentage of what is out there, and carries the label "MVP," is duct-tape-and-baling-wire-last-checkin-five-seconds-before-ship dross.

I know what I consider "MVP" to be, ideally, and that pretty much jives with your description.

It's just that I don't think most folks actually do it. It's like "Agile," in that respect.

As someone that practices high-Quality development, I am regularly laughed at and told that I'm "wasting my time," doing Quality coding.

Words come to mean whatever their most common usage implies, so I think that both of these wonderful words now mean something other than what they used to mean.

https://www.youtube.com/watch?v=G2y8Sx4B2Sk

To echo the peer comment, I personally don't think an MVP should be poor quality, rather have fewer features. For example, it may present the end user a good experience, with well tested code. On the other hand, it may connect to a database without a cluster setup, or setting up a new enterprise account may require someone to run some SQL. Features are missing, but the features that exist are executed well.

It is the first order effect we are able to measure. It is often the second or higher order effect that are impactful. Quality, product market fit, etc

The study was based on patient qualitative spadework, not arbitrary metrics.

Understood, but I wasn’t talking about “arbitrary metrics.” I was talking about the concept of data-driven, feedback-generating optimization, and metrics are just a part of that.

There’s also the concept of “triaging” for “waste.”

One man’s garbage, is another man’s treasure.

I have learned not to summarily dismiss a lot of practices and artifacts as “waste.”

This still feels dismissive. The categories are derived from close cooperation with experienced professionals who were reflecting on their practice and experiences.

Put another way: they weren't being data-driven optimizers. They were exercising judgement. That seems to be what you're arguing for.

Well, it looks like this is one of those places where we probably won't be seeing eye-to-eye. I wasn't being dismissive of the topic, and regret that my post made it seem so. I was just doing what we always do, here, riffing on a theme.

Not an issue.

Have a great day!

I'll do my best, I hope yours goes well.