Kaizen for Developers: No Inventory | Hacker News Reader

Kaizen for Developers: No Inventory

continuations.com

12 pointsdanw9 comments

This is not just strained, but wrong. From Emacs (read all the document into memory) to Linux (ignore pre-386 processors, majority at the time) to Java (drop C memory handling requirements) and of course any web app that runs on a dynamic language, successful designs choose simpler code supported by more powerful hardware rather than opposite.

There's a good reason for this: hardware consistently gets cheaper and more powerful, because it is something we understand how to engineer. Code, so far, doesn't really get easier to write, because it's more of a craft than a science.

Reading the title I thought that the Inventory the author was talking about would be unfinished work. In our startup we often have many half done tickets, because something else a lot more "urgent" comes along - or one of the founders (like me) comes along and changes the focus.

We've come to realize that the real waste in our inventory (or like the author states: bodies in the swamp) is this unfinished work. This points to inefficiencies in our process. So whenever we realize we have unfinished tickets that have been worked on and open for more than a month - we know we have a problem in our process. Finishing tickets completely (as far as the tests/specs go) keeps our code sane, branches clean and helps us integrate earlier.

A much better analogy for Kaizen principle of no inventory in software development is unfinished work.

I agree, and I think specifically its about the agile iead of not addressing future, nebulous, requirements. The minimum necessary that will possibly work.

I don't know what "Kaizen" is, but I smell a strained metaphor. Going from "no inventory" to "don't buy excessive hardware", no matter how the latter may or may not be a good idea, seems like a stretch. Are you sure "no inventory" doesn't actually translate to "don't keep excess code around"? (Multiple plausible translations implies none of them are particularly solid.)

Kaizen is a quality/continuous improvement methodology...kind of like Six Sigma, ISO 9000, etc. It has its benefits over those programs, is less formal, and is more realistic for small companies.

Spending 10x more on hardware will give you roughly 10x more value; I don't think spending 10x more on programmers will give you roughly 10x more value. And that's not even counting the fact hardware is cheap while programmers aren't.

I disagree with the blanket statement that "spending 10x more on hardware will give you roughly 10x more value", especially in the context of this article. You only receive 10x value increase IF your software will scale to use the better/more hardware AND your software is rate-limited by hardware AND you receive value based on the speed of the software. Those are pretty big predicates. Of course, there are sensible ranges and strawman ranges. That's true for programming talent, too. But the article wasn't advocating for hiring more people.

The idea of the article is that footprint matters and needs to be reexamined periodically. This is true for programmers (sadly) as well as hardware. "Hardware is cheap" is not a sustainable growth substitute for efficient solutions. We see the same thing with outsourcing, where a company discovers that ten programmers for the price of one does not always yield the desired outcome (faster, cheaper, better).

Because of course everyone wants to be in a position to use your math (10x more on hardware == 10x more value), but you can not be confident of that unless you know that your solution has a hardware bottleneck. And you don't know that until you drain the swamp (or stress test extensively).

The key part of the article is this: "But you have to go look for those and that takes time and smarts." If you don't have those kind of resources (the smarts is the tough one to find), hardware becomes much more efficient.

kaizen at code level, i try to eliminate as many as temp vars as possible by using closure, map, macro etc

it's because i'm dumb, my brain doesn't have much STM capacity (that's why i don't use OOP)

Reply on news.ycombinator.com