Currently browsing the Software Development Category

Recommended posts: Google Software Engineering - Lean Software Development - If Tech Companies Made Sudoku - Agile Management - Metrics and Software Development - Sub-Optimize part for the Overall Good


Toyota’s Journey to Lean Software Development

Posted on March 18, 2010  Comments (0)

Toyota’s journey from Waterfall to Lean software development by Henrik Kniberg

Toyota builds cars (duh). In the past that didn’t involve much software, and the little software that was needed was mostly developed by suppliers and embedded in isolated components. Toyota assembled them and didn’t much care about the software inside. But “The importance of automatic electronic control system has been increasing dramatically year by year” said Ishii-san.

A modern car is pretty much a computer on wheels! In a hybrid car about half of the development cost is software, it contains millions of lines of code as all the different subsystems have to integrate with each other. He mentioned that a Lexus contains 14 million lines of code, comparable to banking and airplane software systems. Ishi-san concluded that “Therefore Toyota needs to become an IT company”.
…
Most of Toyota’s ideas about how to do Lean software development resonated well with me. My feeling was that they are on the right track.

One thing bothered me though – the extreme focus on detailed metrics. I agree with the value of visualization, standardization, and data-driven process improvement – but only if used at a high level. My feeling was that Toyota was going to far. They say engineer motivation is critical, but how motivating is it to work in an organization that plans and measures everything you do – every line of code, every hour, every defect, how many minutes it takes to do an estimate, etc?

via: Justin Hunter

Related: Toyota IT Overview – Toyota Canada CIO on Genchi Genbutsu and Kaizen – Lean Software Development – My First Trip to Japan by Peter Scholtes – Toyota IT for Kaizen

Improving Software Development with Automated Tests

Posted on March 8, 2010  Comments (7)

Automated software testing is a mistake proofing (poka-yoke) solution for software development.

The way automated testing works is that software code is written that tests the software code of the application. This automated testing code test that business rules are correctly being followed by the code in the application.

So for example, a user should not be able to create a new account without entering password. Then you create code that does not allow an account to be created without a password. And you write a test that passes if this is true and fails if it is false.

The best implementation will then not allow deploying code to your production environment until the code has passed all the automated tests. So if a software developer changes the code, the automated tests are all run and if there is an error noted by the automated testing the code cannot be deployed to the production environment. So, in the example above, if somehow the changes made to the application code somehow now let an account be created without a password the test would fail, and the developer would know to fix the problem before putting the code into production.

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. But it is 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.

Related: Combinatorial Testing for Software – Metrics and Software Development – Checklists in Software Development – Google testing blog – Hexawise software testing blog

Observations of a New Googler

Posted on February 6, 2010  Comments (2)

Some interesting thoughts from a new Google engineer, Things I’ve learned at Google so far

I would describe Google’s culture as “creative chaos”. There was some confusion about where I was supposed to be when I started. This resulted in the following phone call, “Hello?”, “Hello Ben, this is Conner (that’s my new manager), where are you?” “Mountain View.” “Why are you there?” “Because this is where the recruiter said to go.” “Good answer! Nice of them to tell me. Enjoy your week!” This caused me to ask an experienced Googler, “Is it always this chaotic?” The response I got was, “Yes! Isn’t it wonderful?” That response sums up a lot about Google’s culture. If you’re unable to enjoy that kind of environment, then Google isn’t the place for you.
…
Paul Buchheit was a software engineer at Google. He didn’t need permission to write something like gmail. Corporate culture says that if you need something like that, you just go ahead and do it. In fact this is enshrined as an official corporate policy – engineers get 20% of their time to do with pretty much as they please, and are judged in part on how they use that time. I found a speech claiming that over half of Google’s applications started as a 20% project. (I’m surprised that the figure is so low.) To get a sense of how much stuff people just do, visit Google Labs. No corporate decision. No central planning.
…
Sick day policy. Don’t show up when you’re sick and tell people why you’re not showing up. Note what’s missing. There is no limit to how much sick time you get if you need it.

I think he overestimates the lack of central planning, still it is another interesting view of Google.

Related: Eric Schmidt on Management at Google – Google: Ten Golden Rules – The Myth of the Genius Programmer

Statistical Learning as the Ultimate Agile Development Tool by Peter Norvig

Posted on November 5, 2009  Comments (1)

Interesting lecture on Statistical Learning as the Ultimate Agile Development Tool by Peter Norvig. The webcast is likely to be of interest to a fairly small segment of readers of this blog. But for geeks it may be interesting. He looks at the advantages of machine learning versus hand programming every case (for example spelling correction).

Google translate does a very good job (for computer based translation) based on machine learning. You can translate any of the pages on this blog into over 30 languages using Google translate (using the widget in the right column).

Via: @seanstickle

Related: Mistakes in Experimental Design and Interpretation – Does the Data Deluge Make the Scientific Method Obsolete? – Website Data – An Introduction to Deming’s Management Ideas by Peter Scholtes (webcast)

Managing to Test Result Instead of Customer Value

Posted on October 19, 2009  Comments (5)

Computer hardware and software creators use benchmarks as one tool to compare the performance of alternative products. At times this can be very useful. You can learn what software of hardware is faster and that may be a very valuable factor. However, any measure is determined by the operational definitions used in collecting the measure. And if people have incentives to improve the measured number they often will do just that (improving the measure) rather than improving the system (the measure is meant to serve as a proxy for some function of that system).

Information technology people actually understand this much better than most mangers (who also rely on measures for many things like return on equity, profit growth, productivity of various plants…) – so actually I find they are not nearly as fooled by measures compared to managers. On Reddit there is an interesting discussion on coding the product to provide good benchmark results [in this context benchmarking has to do with measured results on standard performance tests – not TQM style benchmarking). The technical details in this case don’t matter so much to my point, which is just that when people treat the measure as the true value instead of a proxy for the true value it is risky.

Technology companies compete fiercely and claiming the software or hardware is faster is one big area of competition. And the comment on Reddit is claiming one competitor changed some code only to get a better measure (that provides no benefit to customers). The problem with such actions, is they provide no actual value: all they do is make the measure less meaningful as a proxy.

Now it is also perfectly understandable why it would be done – when you are focused on improving the number, it might well be easier to distort the system to provide a better number (used by to measure performance) instead of actual improve the performance. It is easy to see why a company would do this if they want to have marketing claim their products are the fastest.
Continue reading →

Understanding How to Manage Geeks

Posted on September 12, 2009  Comments (3)

The unspoken truth about managing geeks by Jeff Ello

IT pros are sensitive to logic — that’s what you pay them for. When things don’t add up, they are prone to express their opinions on the matter, and the level of response will be proportional to the absurdity of the event. The more things that occur that make no sense, the more cynical IT pros will become… Presuming this is a trait that must be disciplined out of them is a huge management mistake. IT pros complain primarily about logic, and primarily to people they respect. If you are dismissive of complaints, fail to recognize an illogical event or behave in deceptive ways, IT pros will likely stop complaining to you. You might mistake this as a behavioral improvement, when it’s actually a show of disrespect. It means you are no longer worth talking to, which leads to insubordination.
…
Good IT pros are not anti-bureaucracy, as many observers think. They are anti-stupidity. The difference is both subjective and subtle.
…
The primary task of any IT group is to teach people how to work. That’s may sound authoritarian, but it’s not. IT’s job at the most fundamental level is to build, maintain and improve frameworks within which to accomplish tasks.
…
it’s all about respect. If you can identify and cultivate those individuals and processes that earn genuine respect from IT pros, you’ll have a great IT team. Taking an honest interest in helping your IT group help you is probably the smartest business move an organization can make. It also makes for happy, completely non-geek-like geeks.

The article makes very good points. As I have said before software developers expect more of management than most staff do. And I would say software developers are seen as more cynical than most staff because they accurately evaluate management’s failures (and are more willing to speak up about problems).

Pretending software bugs don’t exist doesn’t work. Pretending management bugs don’t exist doesn’t work either, but most are willing to pretend management bugs don’t exit. Programmers often figure bugs should be acknowledged and dealt with, rather than pretending they don’t exist. But they are called cynical when they mention management bugs – which only makes them less confident in the ability of management to preform their responsibilities.
Continue reading →

YouTube Uses Multivariate Experiment To Improve Sign-ups 15%

Posted on August 17, 2009  Comments (2)

Google does a great job of using statistical and engineering principles to improve. It is amazing how slow we are to adopt new ideas but because we are it provides big advantages to companies like Google that use concepts like design of experiments, experimenting quickly and often… while others don’t. Look Inside a 1,024 Recipe Multivariate Experiment

A few weeks ago, we ran one of the largest multivariate experiments ever: a 1,024 recipe experiment on 100% of our US-English homepage. Utilizing Google Website Optimizer, we made small changes to three sections on our homepage (see below), with the goal of increasing the number of people who signed up for an account. The results were impressive: the new page performed 15.7% better than the original, resulting in thousands more sign-ups and personalized views to the homepage every day.
…
While we could have hypothesized which elements result in greater conversions (for example, the color red is more eye-catching), multivariate testing reveals and proves the combinatorial impact of different configurations. Running tests like this also help guide our design process: instead of relying on our own ideas and intuition, you have a big part in steering us in the right direction. In fact, we plan on incorporating many of these elements in future evolutions of our homepage.

via: @hexawise – My brother has created a software application to provide much better test coverage with far fewer tests using the same factorial designed experiments ideas my father worked with decades ago (and yet still far to few people use).

Related: Combinatorial Testing for Software – Statistics for Experimenters – Google’s Website Optimizer allows for multivariate testing of your website. – Using Design of Experiments

Baking in Quality to Software Development

Posted on August 15, 2009  Comments (2)

One of the reasons my organizations switched to Ruby on Rails for software development was the great integration with automated testing. We always wanted to have good test coverage on our software applications (which are web applications – some used only inside our organization) but didn’t actually find the time to do so. Since we adopted Ruby we have been doing much better in this regard. It isn’t just the switch to Ruby, of course, but the switch to Ruby coincided with the beginning of many improvements to our software development practices that have continually improved over the last couple of years.

Here is a post on How to build quality software by an agile, Ruby, lean software developer

I’ve mentioned previously about baking-in quality and not having developers throw code over a wall to testers.
…
Everyone on the team is concerned with not only assuring quality in what we deliver, but making it visible to ourselves and the business.

We work in an agile manner, iterating through development with extreme programming practices and Behaviour Driven Development. Facilitating our relationship with the business is Scrum and we utilise kanban principles and systems thinking to maintain a speedy throughput of high-quality work. This mixture allows us to communicate effectively, develop the correct features properly and continuously deploy our work when it is complete, thus maximising business value. I should also mention that we are fortunate enough to have our business people/customer sat across from us.
…
Without testers or a QA team there is no wall over which work can be thrown and the responsibility for quality absolved.
…
The inspection typically carried out end-of-cycle only yields bugs that were low severity and of no real impact to the end user.
…
An agile testing must-have, we use TeamCity to continuously run our unit tests on each check-in. We also execute our Cucumber acceptance tests on scheduled runs. The status of the builds are visible on dedicated monitors around the office as well as a nice 6′ projected screen.

via: @benjaminm

Related: Combinatorial Testing for Software – Checklists in Software Development – Software Supporting Processes Not the Other Way Around – Software Development and Business Process Support – Top Blogs for Software Development – Hexawise: more coverage, fewer tests (my brother’s company)

Three Years of Real-World IT Projects In Ruby

Posted on July 16, 2009  Comments (0)

Nice webcast by Martin Fowler, Three Years of Real-World Ruby. This talk is probably only of interest to those of you in software development, but for them I think it is an excellent presentation.

At work we have been use Ruby for the last 3 years and have found it to be a powerful language that helps make writing software applications fun. And that is important. By providing a powerful language and a rails framework that takes away much of the drudgery of writing code you can create an environment where develops are happy and productive. We are hiring, by the way.

The talk provides a good background on their experience using ruby to manage projects; and how they manage ruby application development projects.

Related: Combinatorial Testing for Software – Checklists in Software Development – Future Directions for Agile Management

The Myth of the Genius Programmer

Posted on June 29, 2009  Comments (1)

Nice talk on fear of looking foolish. The speakers discuss the idea that visibility is good. Don’t hide. Make everything visible and the benefit from many people’s ideas. The talk focuses on software development but is true for any work.

“criticism is not evil” – Very true. “At Google we are not allowed to submit code until there is code review.” At the bottom line they are repeating Deming’s ideas: improve the system – people are not the problem, bad systems are the problem. Iterate quickly.

Related: 10x Productivity Difference in Software Development – The Software Engineering Manager’s Lament – Respect for People, Understanding Psychology

Google Innovates Again with Google Wave

Posted on June 25, 2009  Comments (1)

Google Wave is a new tool for communication and collaboration on the web, coming later this year. They are developing this as an open access project. The creative team is lead by the creators for Google Maps (brothers Lars and Jens Rasmussen). A wave is equal parts conversation and document. People can communicate and work together with richly formatted text, photos, videos, maps, and more. You really have to watch to understand what it is.

This is a long webcast (1 hour and 20 minutes) and likely will be best only for those interested in internet technology solutions. But it also provides useful insight into how Google is managing the creation of new tools. But the ideas are not explicit (the demo was meant to present the new product Google Wave, not explain the thought behind producing useful technology solutions), so you have to think about how what they are doing can apply in other situations.

For software developer readers they also highly recommended the Google Web Development Kit, which they used heavily on this project. They also have a very cool context sensitive spell checker that can highlight misspelled words that are another dictionary word but not right in the context used (about 44:30 in the webcast). And they discuss using Wave to manage bug tracking and manage information about dealing with bugs (@ 1 hour 4 min point).

Very cool stuff. The super easy blog interaction is great. And the user experience with notification and collaborative editing seems excellent. The playback feature to view changes seems good though that is still an area I worry about on heavily collaborative work. Hopefully they let you see like all change x person made, search changes…

Related: Eric Schmidt on Management at Google – Joel Spolsky Webcast on Creating Social Web Resources – Great Marissa Mayer Webcast on Google Innovation – Google Should Stay True to Their Management Practices – Amazon Innovation

Top 10 Reasons Why Employees Leave in IT

Posted on June 23, 2009  Comments (1)

Some of the problems expressed in the post linked to are specific to IT, and some are more important in software development (where as I have said before employees have higher expectations of management than most employees do), but many have truth for many employees. A good manager can create an environment where these problems are eliminated or reduced.

Top 10 Reasons Why Employees Leave in IT

No prioritization on items therefore constant interruptions in projects are the norm leaving projects unfinished due to a shift to “yet another project or task unexpectedly”
…
Boss doesn’t communicate things that affect the team or you as an individual and makes all decisions without your knowledge only you finding about it later through another source
…
Managers who fail to promote the very people who deserve it rather than who is popular or who they like
…
Bad co-workers who do not get stomped out (let go) and hurt the culture
…
Teams work best when they collaborate and are allowed to question what the proposed process or standard is, not just following and doing what is told 100% of the time. If the process suggested or currently ongoing sucks, question it and expect your team to question it!
…
Employee comes up with an idea and manager disregards it because “no I’ve always done it my way” even if it’s a 1999 way of doing things

Related: Helping Employees Improve – Information Technology and Business Process Support – Stop Demotivating Me! – The Manager FAQ – Flaws in Understanding Psychology Lead to Flawed Management – posts on managing people

Job Listings Online Filled with Jargon

Posted on June 5, 2009  Comments (2)

The job market is not great, 9.4% unemployment in the USA, and not efficient either. At my full time job, we hired a ruby on rails developer (web programmer) this month, and are looking to hire another.

Job listings online filled with jargon

With unemployment reaching historic levels, online job search traffic is heating up. Sites like Monster.com, Dice.com, and HotJobs.com are gaining steam with anywhere from a 20-90% increase in traffic in February. Somehow CareerBuilder.com managed to dip 3% but SimplyHired.com achieved a 290% increase in traffic, and other sites like Craigslist and LinkedIn are also gaining momentum.

Job search sites are gaining traffic and providing a great service to the unemployed and unhappily employed. Unfortunately, the inability of corporations and recruiters to provide prospective applicants with sensible job postings threatens to render these sites useless.
…
Filling the entire job posting with corporate and industry acronyms, abbreviations, and jargon – By filling the job posting with nonsensical jargon, a recruiter further inflates their false sense of importance and also avoids the issue that they know absolutely nothing about the job. The applicant is left wondering whether they just applied for a job responsible for fixing Boeing 747s or installing Kimberly-Clark toilet paper dispensers. Pretty much a toss up.
…
It’s scary to imagine what job postings might look like in 10 years if this trend continues. If anyone is interested in building a Google Translate with a “Recruiter to English” option, I can serve as your Subject Matter Expert.

In the information technology field the standard practice is to include a large number of basically irrelevant skills as requirements. And then managers wonder why they don’t get decent applicants. You need to include the knowledge, skills and experience you really need and not all sorts of details that an employee can easily pick up, if needed, once they are on the job.

Related: Hiring: Silicon Valley Style – Interviewing and Hiring Programmers – IT Talent Shortage, or Management Failure? – Joy in Work: Software Development – Management Improvement Career Connections

Joel Spolsky Webcast on Creating Social Web Resources

Posted on May 4, 2009  Comments (1)

Joel Spolsky webcast on creating Stack Overflow (with the goal of providing answers to professional programmers) using ideas from anthropology. Once again he provides great information. This is particularly interesting for software development but also just a good presentation for understanding the importance of customer focus and systems thinking.

What they focused on and did:

  • Voting – Reddit… (see our management Reddit)
  • Tags – lets you see what you want and to block tags you don’t want to see.
  • Editing – letting users edit the questions and responses. For a technical question and answer system this is very useful (based on my experience).
  • Badges – people like to earn “credit” (psychology)
  • Karma – “people are willing to do for free what people are not willing to do for small amounts of money” (psychology)
  • Pre-search – provide quick view of previously answered questions
  • Google is UI – Assumption: “the front page is Google search” – build based on the idea people will search via Google
  • Performance – 16 million pages a month with 2 web servers. They are using the Microsoft stack, not open source.
  • Critical mass – they focused on getting a large user base on day one of the beta site

Related: posts related to Joel Spolsky – Dell, Reddit and Customer Focus – Information Technology and Management – What Motivates Programmers?

Checklists in Software Development

Posted on April 7, 2009  Comments (2)

Verify your work with checklists

WHO has recently shown that surgical deaths can be reduced by a third when hospitals follow their Surgical Safety Checklist. The checklist is very low tech. It includes questions like whether the patient has been properly identified, whether the proper tools are available, and whether everyone knows what kind of procedure is about to be done.

If a checklist so simple can save so many lives, I thought the technique could surely help us do better as well. So after reading about this study and their checklist, I’ve been pushing us to create checklists for all the common procedures at 37signals.

We now have checklists in Backpack for confirming that a feature is complete, we have a checklist for preparing the feature for deployment and for executing the deployment, and finally for verifying that the feature is working as expected in the wild.
…
It’s the kind of stuff that we all know, but that we’ll often forget if we’re not being reminded about it in the moment. Thinking back to the mistakes we’ve made in the past, there are plenty of those that could have been avoided or caught much earlier if we had been using checklists.

This is a great reminder of two things: using checklists and adopting good ideas. Checklists are a simple and effective quality management tool. We use them for our software development (I have been a bit slow at getting them in place but we have been making progress recently). Also this shows how management improvement should work. You get good ideas from others and adapt them for use in your systems. Copying what others do, doesn’t work well. But understanding the concepts they use to improve performance and then adapting those concepts to your organization is the path to improved performance.

Related: Checklists Save Lives – Find Joy and Success in Business – Lean, Toyota and Deming for Software Development – The Power of a Checklist – Most Meetings are Muda

The Importance of Making Problems Visible

Posted on April 2, 2009  Comments (1)

Great, short, presentation webcast by Jason Yip showing the importance of making problems visible. Anyone interested in software development should watch this, and it is valuable for everyone else, also. Great visuals.

Related: Future Directions for Agile Management – Agile Software Development Slideshow – Leading Lean: Missed Opportunity – Information Technology and Management – Curious Cat Micro-financiers – posts on project management – Toyota Institute for Managers

Combinatorial Testing for Software

Posted on March 26, 2009  Comments (8)

Combinatorial testing of software is very similar to the design of experiments work my father was involved in, and which I have a special interest in. Combinatorial testing looks at binary interaction effects (success or failure), since it is seeking to find bugs in software, while design of experiments captures the magnitude of interaction effects on performance. In the last several years my brother, Justin Hunter, has been working on using combinatorial testing to improve software development practices. He visited me this week and we discussed the potential value of increasing the adoption of combinatorial testing, which is similar to the value of increasing the adoption of the use of design of experiments: both offer great opportunities for large improvements in current practices.

Automated Combinatorial Testing for Software

Software developers frequently encounter failures that occur only as the result of an interaction between two components. Testers often use pairwise testing – all pairs of parameter values – to detect such interactions. Combinatorial testing beyond pairwise is rarely used because good algorithms for higher strength combinations (e.g., 4-way or more) have not been available, but empirical evidence shows that some errors are triggered only by the interaction of three, four, or more parameters

Practical Combinatorial Testing: Beyond Pairwise by Rick Kuhn, US National Institute of Standards and Technology; Yu Lei, University of Texas, Arlington; and Raghu Kacker, US National Institute of Standards and Technology.

the detection rate increased rapidly with interaction strength. Within the NASA database application, for example, 67 percent of the failures were triggered by only a single parameter value, 93 percent by two-way combinations, and 98 percent by three-way combinations.2 The detection-rate curves for the other applications studied are similar, reaching 100 percent detection with four- to six-way interactions.
These results are not conclusive, but they suggest that the degree of interaction involved in faults is relatively low, even though pairwise testing is insufficient. Testing all four- to six-way combinations might therefore provide reasonably high assurance.

Related: Future Directions for Agile Management – The Defect Black Market – Metrics and Software Development – Full and Fractional Factorial Test Design – Google Website Optimizer

What Managers can Learn From Open Source Project Management

Posted on February 23, 2009  Comments (1)

What managers can learn from Open Source by Murray Cumming

Motivation: People work on open source projects because they enjoy it. These happy developers are productive developers. Managers of open source projects must ensure that the developers feel valued and fulfilled. They must minimise the tedious aspects of the work to ensure that development remains interesting. Otherwise, projects fail.

Although money can provide some incentive it does not provide as much. Managers who say that money is the greatest motivator are justifying their own poor performance. Managers of proprietary software, just like managers of open source software, must ensure that their developers are motivated properly. It is not enough to think that they should feel motivated.
…
Open source projects have the benefit of direct feedback from users. Systems such as bugzilla and open mailing lists make it easy for customers to express their needs. That is the necessary first step to satisfying those needs. See the Structural Solutions section.

For instance, proprietary application server projects such as BEA and WebSphere seem deaf to the frustrations of their customers, but the open source JBoss project is happy to hear about those problems and avoid them in its own product.

Standards/Consensus: Open Source projects must conform to, and reuse, accepted, up-to-date standards. Proprietary projects, without the benefit of high visibility or feedback are free to make inferior decisions.

Don’t miss this great essay by Paul Graham: What Business Can Learn from Open Source. And you know what else? I don’t think open source projects use the annual performance review.

Related: Open Source: The Scientific Model Applied to Programming – Dangers of Extrinsic Motivation – What Motivates Programmers? – Open Source Management Terms

Helping Employees Improve

Posted on February 12, 2009  Comments (2)

One aspect of managing people is to provide positive feedback and show appreciation. Doing so is important. People benefit from encouragement and reinforcement. In addition to just telling them, take action to show your appreciation.

The Dilbert workplace is alive and well. And even in above average management systems there is plenty of resistance faced by those looking to improve systems. For those employees that are making the attempt to improve the organization go beyond saying thanks: actually demonstrate your appreciation. Do what you can to help them achieve.

A manager should be enabling their employees to perform. That means taking positive steps that help them perform. This is even more appreciated than saying thanks. And has the added benefit of helping the organization by helping along their good idea. It is win, win, win. They win, you win and the organization wins.

Thoughts on: Rewards and Recognition

Related: Keeping Good Employees – Respect for People Requires Understanding Psychology- People are Our Most Important Asset – Motivation – Incentive Programs are Ineffective

Curious Cat Management Carnival: Select 2008 Highlights

Posted on January 12, 2009  Comments (6)

Over the last couple of years the quality of management material available online has increased dramatically. And blogs have provided much of the best management material. The Curious Cat Management Improvement Carnival now provides highlights 3 times a month. Each carnival post highlights recent management related posts from several management blogs. And for the 2008 year in review 9 blogs have each taken a handful of management blogs and provided annual highlights.

In this post we will cover four blogs: Lean Software Engineering, Timeback Management, Know HR and Quality and Innovation. All I aim to do in the post is highlight a few excellent posts for the year. To capture the depth of these blogs add them to your RSS reader and read them throughout the year.

Lean Software Engineering by Corey Ladas (a management carnival host) and Bernie Thompson does an excellent job of discussion the application of lean manufacturing ideas in software development. Corey also published: Scrumban, Essays on
Kanban Systems for Lean Software Development this year. The blog is a must read for anyone working in software development applying lean thinking.

  • Boehm’s Spiral Revisited by Bernie Thompson – “Twenty years ago this month, in response to the problems associated with waterfall-style approaches to software projects, Barry Boehm proposed his Spiral Model of Software Development. Which bore some resemblance to Deming’s “Plan, Do, Check, Act” cycle.“
  • Queue utilization is a leading indicator by Corey Ladas – “there is a very pragmatic reason to adopt a Lean workflow strategy, regardless of what sort of product you are building: Lean scheduling provides crystal clear leading indicators of process health. I am speaking of kanban limits and andon lights.”
  • Two axioms of lean software development by Corey Ladas – “Axiom 1: It is possible to divide the work into small value-adding increments that can be independently scheduled. Axiom 2: It is possible to develop any value-adding increment in a continuous flow from requirement to deployment. “
  • Perpetual multivote for pull scheduling by Corey Ladas – “In our system, development capacity can free up at any time. When it does, the next candidate should have been previously selected so that the team can get right to work. That means we’ll have to make frequent updates to the selection process. If we’re going to do this frequently, it has to be inexpensive. Consensus building is expensive. My goal is to do this with no estimates and no meetings.”

The Timeback Management blog by Dan Markovitz focuses on applying lean principles to promote effective management. And as the name suggest he also posts on making effective user of your time.

  • The Danger of Easy Access – “When we don’t value our limited time and attention sufficiently, we open the floodgates to infinite requests from coworkers — to our detriment… Get lean: in the tradition of Toyota’s andon, put up a sign at your cube or office that says when you’ll be available to talk.” [I must admit I have challenges with the common lean view of open offices, for the same reasons Dan mentions here. I prefer the model Joel Spolsky uses for software development staff, where collaboration is encouraged but developers have private offices. I am sure I benefit from a distraction free environment. There is debate in the lean blogosphere about the proper lean model though. My belief is that partially the answers lies in examining what is right for the specific office in question (though perhaps I am just clinging to an outdated idea). I find Instant Messaging (IM) useful (for encouraging collaboration and providing less distraction - including allowing people to work from home). This disruption from IM seems less obtrusive and you can set a status as Dan mentions to indicate how hesitant people should be before sending an IM. - John Hunter]

Continue reading →

  • Recent Trackbacks

  • Comments