
Kaizen for Developers: No Inventory - danw
http://continuations.com/post/61496327/kaizen-for-developers-no-inventory
======
nir
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.

------
spif
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.

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

------
jerf
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.)

~~~
ssharp
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.

------
Hexstream
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.

~~~
dmv
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).

------
bprater
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.

------
hs
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)

