Lean Software Development: An Agile Toolkit - The Book

Lean Software Development: An Agile Toolkit - The Book - sfeldman.NET

Lean Software Development: An Agile Toolkit - The Book - sfeldman.NET — Sat, 27 Jun 2009 15:25:16 GMT

Pingback from Lean Software Development: An Agile Toolkit - The Book - sfeldman.NET

Braking Myths | Nexo IT - Information Technology News

Braking Myths | Nexo IT - Information Technology News — Wed, 24 Jun 2009 01:17:19 GMT

Pingback from Braking Myths | Nexo IT - Information Technology News

I love .NET! » Blog Archive » Braking Myths

I love .NET! » Blog Archive » Braking Myths — Tue, 23 Jun 2009 15:42:39 GMT

Pingback from I love .NET! » Blog Archive » Braking Myths

Braking Myths

sfeldman.NET — Tue, 23 Jun 2009 04:21:02 GMT

I was chatting with an old mate of mine, Lev  Ozeryansky, with whom we graduated together computer

re: Implementing Lean Software Development – The Book

Sean Feldman — Mon, 22 Jun 2009 04:38:59 GMT

@Jiang,

Dude, if you don't like my blog, why the hell are you commenting? Just for the sake of useless argue? I see no point in that. You are definitely got stack in the world of data-centric applications code wise, and in the world of "good managers / evil developers" management wise. Good for you.

Yes, the majority of developers are adopting themselves to the painful reality and produce defects, poor quality, delay and don't deliver what managers want. At the same time look how these developers are managed, and you will not only be horrified, but also partially understand why those developers screw up big time. Agile has no tolerance to defects and low quality. If you don't think that Lean production is the right way to apply to software, then don't tell me that waterfall is the way -- I've seen that shit enough to know that it's nothing but bull. Gantt charts? Oh, wait, a few weeks of testing just before the end of the project? Wait, better, lets do BDUF (Big Design Up Front) first! Maybe a tight schedule of the entire project described in MS Project up to to a day level that never works? How about getting it requirements from the client once, and then giving it *software* in a year from the interrogation. Or lets have pile of documentation to replace the client for that year, why to bother, let developers just code. And lets code all the features up front so that we don't have to worry (we'll worry what the hell to do with it once start maintaining it). I know! We'll have DB schema first, so that the application design sit there, and developers "deliver the changes management wants". Wonderful! Absolutely better than agile. Now you have a plan to entertain the software world (like it wasn't for the past few decades).

Now seriously, Jiang -- please wake up. Inventions like "measurement of a developer performance by LOC (Lines Of Code) counting was NOT developers invention". Developers are thinkers. If they don't think, they just-do-something. This is what was happening for too long. Agile (that is not new BTW) is helping to fix what was mistaken. Agile has to be applied at both management and developement level.

In the future I hope you read a book before jumping into criticzing it. That's what mature people do.

re: Implementing Lean Software Development – The Book

Jiang — Mon, 22 Jun 2009 00:07:41 GMT

“The world has changed, and managers need to adopt a new way of thinking. Delays, mistakes, defective workmanship, and poor service are no longer acceptable.”

hmm... I think Edward Deming got it backward. Actually, it's the developers who think that delays, mistakes, defective workmanship and poor service are acceptable. Managers always wanted timely delivery with zero bugs. There are so many books out there that spread falsehood, half-truth and semi-acedemician purism. The trend is agile, meaning making it good enough and worry about other things later (read, refactor).