Hacker News new | past | comments | ask | show | jobs | submit login

I get the feeling that the "wasted effort" in the second approach is about rewriting code.

Rewriting code is good in my experience. It's always better the second time around (or third, or fourth). It's not that my first attempt was rubbish, it's that I didn't understand the problem as well as I did the second time (and so on).

Lean is also about avoiding premature optimisation. Which is hard because it cuts against the grain of our engineer sensibilities. Doing something "good enough for now" is tough, when you know that with just a few more days' effort you could make it bulletproof. But I've had to delete "bulletproof" code so many times, because it turns out the product didn't need that feature, or it needed to work differently.

In the long term, Lean avoids more wasted effort, in my experience.






There's a difference between Lean and Instant Legacy Code. The key difference is focus on simplicity including cyclomatic, compositional etc. Simple is not the same as simplistic. Lean as a methodology is meant to remove obstructions and waste in manufacturing. Effort is not a thing that can be wasted. Excess code is the waste. Fixing bugs is wasted time compared to not having them.

"Good enough for now" is a great excuse to keep hacks around and letting them accumulate to the point where code is unmaintainable. Meaning too much code, meaning waste. Even better is "it works now, do not touch" especially when current code base is untested.

Programmers are typically lazy and do not bulletproof anything ever. Thus rampant security issues.

The alleged wasted effort is from the point of view of some manager who doesn't get to tick boxes quicker. (And disregards later massive drop in development velocity while presumably demanding same results.) This means spotted issues are pushed towards never unless a customer reports them. Which they won't or even can't so you get your software brand recognized as buggy trash - with workarounds being commonly peddled among users and devops.


This is probably out of place, but are you OK? I burnt out about a decade ago, and would have agreed with a lot of what you're saying back then. It took me years to get back into a happy place with tech.

Dysfunctional teams and organisations produce this kind of cynical rage, not Lean.


Dysfunctional companies produce buzzword laden or metric based management. (As opposed to good software.)

Lean is not a software development methodology. It is made for factories and production lines, a terrible fit for most kinds of software. The only salvageable parts from it is iteration and listening to frontline workers to get process improvements. "Autonomation"/Poke Yoke as in automated tests. Which is not enough of a methodology.

The "Lean for software" page gives contradictory definition of waste - you're supposed to minimize defects while at the same time minimizing rework. I'd like a crystal ball that enables it. Plus you cannot apply it without absolute control over the whole development process. Any place that is a black box (say, both set of features and deadlines are given) the process. Thus it fails in corporate environment.

Likewise, general agile methodologies are easily perverted into what I just described - by skipping refactoring and redesign parts in service of deadlines. That model works only if you throw things away like startups do or the project is small and self-contained.

Usually small projects are low value or grow big. C.f. Twitter or YouTube when it started and now. Even worse if you get to interact with quickly changing parts controlled by another team you do not control in even a medium sized project.


I agree with everything you said, but I must point out that Lean comes from Toyota. While most people know about the production system, which is indeed applied to factories, Toyota applies this to the product development too. Product development is much closer to what software development is. Unfortunately there is a lot of misinformation on the topic, but there is a very good book, called "Toyota Product Development System", which describes how Lean is applied there. There is an insane amount of valuable information in there, every software company should be at least aware of those engineering practices.

Any project that has both features and deadline set by management is going to fail. That's a fact of software development. Lean/Agile doesn't solve that, or even attempt to.

It also doesn't attempt to minimise rework (it values iterative approaches), and is strong on exploratory prototypes.

Again, I think what you're criticising is "Agile as implemented in dysfunctional organisations" rather than actual Agile.

I'm building a startup, though. My definition of "good" software is probably different to yours (and that's as it should be).


This is a common view these days. But as a technical founder, I disagree with this view. Once you launch the bare minimum first version, there are different customer segments who pull you in different directions. Often you chase one path and find that the customer segment is not lucrative enough and chase the next. Till you find a compelling usecase with money making potential, you will end up with various set of features used by different customer segments.

This might still be less wasteful when compared to building an entire product and finding no customers. But, it is taxing on the technical founder! Lean washing shouldn't set a wrong expectation for the technical founder involved in startups that follow the rapid prototyping approach.


man, I feel your pain. I've been through this a few times. Just about to go through it again. Yes it's tough. I keep hoping that there's a non-tough bit later when most of the technical problems are solved and we get to sit back a bit and watch the business folk hustle. Haven't found that point so far though

I agree, ultimately you never know if your effort was wasted until the prototype is made and you know if it's successful or not which is the only purpose of a prototype.

> It's not that my first attempt was rubbish, it's that I didn't understand the problem as well as I did the second time

I think thats too soft, I know my first attempt will be rubbish so I intend it to be so. To me the point of a prototype is to help you learn the problem more than to solve it.

If you plan to keep your prototype if it works out then I think you have missed a trick, a prototype should aim to fail quickly.

If your prototype is useful then I think it fails its point as a prototype.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: