Blog posts on lean software

Posts selected fromManagement Blog - Engineering Blog - Investing Blog and other blogs

• Agile Software Development and Deming's Ideas

  It's one of the reasons for "people over process" and all that; they believe that a software developer should be respected. Yes, they should. Factory workers should be respected, too. Everyone should be respected. That's what Deming was talking about. So then the idea that Deming was trying to impose on software developers some rigid controls that they shouldn't be subject to is not so. And not only wasn't he doing that, he wasn't doing that to factory workers either.

  continue reading: Agile Software Development and Deming's Ideas
• The Edge-case Excuse

  I have found “edge cases” to actually mean we don’t want to fix it. Often the issue isn’t needing some special code to deal with an “edge case” it is the coding was done poorly and breaks in many different “edge cases.” It isn’t that those edge cases need to be coded for. It is that the code should have been written in a robust way that didn’t break for lots of “edge cases” but the excuse given for not fixing the fundamental coding fragility is the bugs found are just “edge cases.”

  continue reading: The Edge-case Excuse
• Software Testing and the Impact on Quality

  The aim for software testing is not just to fix the bugs software testers catch but to function as part of a system to figure out the reasons those bugs were created and improve processes so fewer bugs are created in the future.

  continue reading: Software Testing and the Impact on Quality
• Applying Toyota Kata to Agile Retrospectives

  Retrospectives are a good method to help improve but if there is no time to think about the issues raised and come up with experiments to improve and review of whether those experiments worked or not and why failure to improve is the expected result.

  Creating a culture where it is expected that any improvement ideas are tested and evaluated is one of the most important changes on the path to a company that will be able to continually improve.

  continue reading: Applying Toyota Kata to Agile Retrospectives
• Examine the Results of Your Testing Practices and Continually Improve Your Methods

  The idea of delibrately examining your software development and testing practices will be familar to those using agile retrospectives. The power of continually improving the development practices used withing the organization is hard to appreciate but it is immense. The gains compound over time so the initial benefits are only a glimpse of what can be achieve by continuing to iterate and improve.

  continue reading: Examine the Results of Your Testing Practices and Continually Improve Your Methods
• Add Constraints to Processes Carefully

  Frequently I see unnecessary constraints creating the edge case excuse. By burdening your process with unnecessary constraints you create edge cases that fail and then use the excuse that each of the edge cases is rare and therefore you can’t justify the expense of fixing them.

  But if you designed the process sensibly in the first place the edge case never would have failed and you wouldn’t need special work arounds for such “edge cases.” A simple example of this is unnecessarily complex web page code that fails if to submit a button without javascript. Yes, a small number of users won’t have enabled all javascript to run (today anyway) so it is an “edge case” to deal with if you don’t have the form work without javascript. But there is no decent reason to have it fail in most cases.

  continue reading: Add Constraints to Processes Carefully
• Software Code Reviews from a Deming Perspective

  I think the “inspection” in code reviews is different enough that we can use code reviews as a valuable tool for managing software development. The waste of having processes that create defects and then use inspection to catch them is certainly something to avoid. A significant part of the effort in code reviews should be geared toward capturing learning that can be applied to current processes to improve them so fewer bugs are created in the future.

  In my experience this part of code reviews (using it to improve the existing processes) is not given the focus it should be. So I do believe that code reviews should focus more on why did we find something we decided to fix?

  continue reading: Software Code Reviews from a Deming Perspective
• Testing Smarter with Matt Heusser

  Hexawise: You have written about the benefits of lean thinking in software testing. What advantages do organizations gain when they adopt a lean thinking view of software testing?

  Matt: You know that thing that happens, where you can't do your job because you filed a ticket and it will take the DBA's a week to add a column to a table, so you can't do your job, for a week?

  Or whatever else it is? Right now I've got a contractor billing on my team with no laptop. He'll have it nine days after he started ... if we're lucky.

  Typically, when a company goes to lean thinking, that kind of stuff stops happening.

  continue reading: Testing Smarter with Matt Heusser
• Lean Information Technology

  It is very easy for waste to be hidden in IT. I think it is more difficult to notice the inefficiencies in IT because much of the work is done in virtual space, not real space. I think that can make it more difficult to see the waste.

  ...

  Instead of taking the time to design these properly something is created quickly, for today. If the code had a physical existence I think much of it would look like a rube Goldberg contraption.

  continue reading: Lean Information Technology
• Toyota's Planet Kaizen

  It requires flash to view Planet Kaizen. I think it has amazingly bad visual controls (as do many flash applications). I can’t figure out why it would be done in flash – other than some marketing person, or IT person, thought it would be cool. I certainly don’t see how kaizen practices could have produced such an application. It seems to me one of the examples of how far Toyota still has to go.
  
  Of course, as an automobile manufacturer failing to develop web applications well, is better than failing at manufacturing cars well.

  continue reading: Toyota's Planet Kaizen
• Lean Software Development

  Software development can be extremely complicated and can benefit greatly from making problems visible – jidoka. 

  ...

  Lean thinking has a great deal to offer for those involved in software development.

  continue reading: Lean Software Development
• If Tech Companies Made Sudoku

  We often seem to add unnecessary complexity to software; creating fragile code that is frustrating to use.

  Unnecessary complexity in internet development has increased greatly since I wrote this in 2006.  I can't believe how often simple actions like clicking a link on web sites with huge budgets fail because instead of just being a link it is some complex code that is fragile and fails.  The huge downloads needed for many websites today should shame them but the explosion of waste continues unabatted.  At some point it will stop, but I am amazed how long the extermely poor management practices have continued. 

  Related: The Edge-case Excuse

   

   

  continue reading: If Tech Companies Made Sudoku
• Toyota IT for Kaizen

  IT often does the opposite of lean management and makes things more complex, more prone to error, less effective, etc.. Often all in search of only one thing – cutting costs. For that people should not be faulted for being skeptical of IT solutions. However, that does not mean that IT cannot play a part in improvements. It can, just be careful.

  I find it a good sign when the CIO office is helping people find solutions at the request of the users rather than dictating solutions from on high. Some of the dictating might be necessary to optimize the system of IT (some local sub optimization may be required for the overall good) but in my opinion this is used as an excuse far too often.

  Related: The Edge-case Excuse (a post I wrote more recently on the topic of error prone IT solutions)

  continue reading: Toyota IT for Kaizen
• Bringing Lean Principles to Service Industries

  Iteration is very important. It is important in proper use of the PDSA cycle – many quick iterations are much better than one long slow one. And for software application development it is an excellent strategy.

  I think iteration is even more important in software application development than most other areas (for now anyway) because many stakeholders cannot visualize what they need from software. Therefore attempts to force rigid requirements up front fail...

  continue reading: Bringing Lean Principles to Service Industries
• Improving Software Development with Automated Tests

  ... Thus automated testing mistake proofs the process. Now the mistake proofing is only as good as the test that are added. Software development is complex and if the code has an error (based on the business rules) that is not tested then the code can be deployed to production and affect customers. Automated software testing tools are a huge help in preventing many errors from affecting customers.

  It seems pretty obvious but until the widespread adoption of agile software development techniques and frameworks that make it easy to adopt automated testing (like Ruby on Rails) this sensible process improvement tool was used far less often than you would think.

  continue reading: Improving Software Development with Automated Tests