Category Archives: Software Development

Jason Fried: Why work doesn’t happen at work

In this TED talk, Jason Fried, founder of 37 signals, discusses how people get work done. When asked where do you go when you really need to get something done, almost no-one says: the office (unless it is early in the morning or late at night)? This is especially for creative people and knowledge workers. They need long stretches of uninterrupted time to concentrate. “The real problems in the office are the managers and the meetings.”

The main theme is that interruptions can severely damage performance, especially for what Peter Drucker called knowledge workers.

He offers 3 suggestions to make the office a place people can get work done. No talk Thursdays. And if that is too much how starting with 1/2 a day Thursday once a month. Second, replace active distraction (meeting, going and talking to a person) with passive distraction (email and IM) that a person can turn off when they need to focus. I have found this very useful myself. And third, cancel meetings. He closes with: I hope I have given managers reasons “to think about about laying off a little bit and giving people some time to get work done.”

Related: Understanding How to Manage GeeksBetter MeetingsWorkers Allowed Recreational Use of the Internet are More ProductiveManagement By IT Crowd Bosses

No True Lean Thinking or Agile Software Development

“There is no true value of any characteristic, state, or condition that is defined in terms of measurement or observation.” – Dr. W. Edwards Deming.

The value depends on your operational definition.

Once you operationalize management ideas in a real organization it necessarily should have differences from how it is operationalized elsewhere. As Deming said there are no effective simple recipes for management. It is one of the frustrations people have with Dr. Deming: that there is no cookbook telling you what you should go do as a manager. You need to understand things like: interactions, variation, psychology, systems thinking, how we know what we know (and what we “know” that isn’t so). And then you need to make decisions about how to apply these concepts in your organization.

There is value in being able to think and discuss ideas in a broader context than your organization. You lose a great deal of learning opportunities if you can’t. And having common idea about what common principles a lean thinking organization or agile software organization should have is helpful I believe. That is aided by abstract ideals of these management practices.

Dilbert comic on the futility of process and arbitrary deadlines

One of agile’s guiding principles is individuals and interactions over processes and tools. I am a Deming follower and that emphasizes the importance of process and system. The words in agile are anti-process. But in my experience it is really a specific type of process – and that is basically idiotic adherence to process that the software developers are sick of. This attitude is best summed up in Dilbert. There are plenty of what I would call process in the practice of agile – sprints, kanban, work in process limits, define what done means, using user stories, retrospectives, build in quality… Basically I think it is important to understand what the principles mean, but don’t get locked into dogmatic ideas.

There are principles that seem to me necessary to, for example, consider an effort as lean management. There must be respect for people in lean management. If it isn’t there, then I don’t think it is lean. It might be management using some ideas and tools from lean, but it isn’t lean management. Exactly how respect for people is manifest is up to the organization. The same thing holds for other principles.

Thoughts on No True Agile, No True Lean, No True Latte

Related: Dr. Deming: There is No True ValueHow to Manage What You Can’t MeasureInvolve IT Staff in Business Process ImprovementThe Illusion of Knowledge

Continue reading

The role of leadership in software development

The webcast of Mary Poppendieck’s talk, The role of leadership in software development, at Google. As usual Mary does a very nice job of providing some good historical background while exploring wise management practices (tied to software development but plenty useful for any manager).

via: Sheep of a different fold

Related: Lean, Toyota and Deming for Software DevelopmentWebcast on the Toyota Development ProcessDon’t Use Performance AppraisalsLean Software DevelopmentThe Leader’s Handbook

Stop Starting and Start Finishing – Jason Yip

Jason Yip explores the value of reducing work in process and reducing context switching costs to optimize throughput. By designing processes to work on projects serially instead of in parallel we reduce context switching, and other costs, of multitasking.

Related: Multi-Tasking: Why Projects Take so LongThe Importance of Making Problems VisibleOne piece flow (continuous flow)Kanban

Involve IT Staff in Business Process Improvement

I started out basically working on management improvement from the start of my career. My makeup (I am never satisfied and figure things should always be better) along with a few traits, experiences and probably even genes made this a natural fit for me. I tend to take the long view and find fire fighting a waste of time. Why fix some symptom, I want to fix the system so that problem doesn’t happen again. My father worked in statistics, engineering and business improvement and as I was growing up I had plenty of experience with process improvement, understanding variation, experimenting, measuring results

I came into the IT world as I had needs and found the best solution was to write some software to help me accomplish what I wanted to. One thing that better software tools allowed is this type of thing when organizations failed to use technology well, individuals could just do so themselves. Without these tools people had to rely on the organization, but today atrophied IT organizations can often be circumvented. Though the IT organizations often try to avoid this largely by bans (instead of by providing the tools people need), which is not a good sign, in my opinion.

I then spent more and more of my time working with technology but I always retained my focus on improving the management of the organization, with technology playing a supporting role in that effort. That is true even as where I sat changed. And I have become more convinced organizations would be served well by using the information technology staff as business process experts.

At one point I sat in the Office of Secretary of Defense, Quality Management Office where I was able to focus on management improvement and using technology to aid that effort. Then I went to the White House Military Office, Customer Support and Organizational Development office and focused largely on how to using technology to meet the mission. Then I was moved into the White House Military Office, Office of Information Technology Management.

And now I work for the American Society for Engineering Education in the Information Technology department. My role started as partially program management and partially software development and as we have grown and hired more software developers I am now nearly completely a program manager.

I believe technology is a central component of understanding business processes today. But the truth is, many business people don’t have as complete an understanding as I feel they should. Now I believe, most anyone interested in planning their management career needs to develop a facility with technology and specifically how to use software applications to improve performance. You don’t need to be an expert programmer but you need to understand the strengths, weakness, limits of technical solutions. You need to understand how technology can be used (and the risks of options).

At the same time I just don’t think it is likely management everywhere will get a decent understanding of application software development. I also believe that in many cases organizations should do software development in house. This is a issue that certainly can be argued (but I won’t do it here). Basically I don’t think organizations should cram their processes into designs required by off the shelf software. Instead I believe they should design processes optimal for their organization and using off the shelf software often does the opposite (forces the process decisions around what software someone decided to buy). There is plenty of use for off the shelf software that doesn’t force you to make your processes fit into them (and sometimes even if it does that is the business decision that has to be made – I just think far too often organizations look at short term costs and not the overall best solutions for the system).
Continue reading

Trust Your Staff to Make Decisions

The failure to give your organization the flexibility to serve customers is a big mistake. Many companies make this mistake. Often the basic problem is managers don’t trust that their systems to hire and develop people that will make good decisions. The solution to this problem is not to give your staff no authority. The solution is to manage your systems so that you can trust your people. This is not as easy to do as it is to say, I will grant that.

Southwest Airlines and Zappos are companies that do respect employees. And those employees then provide great service. But it isn’t a simple thing. To truly manage a system with respect for people isn’t as easy as just putting up some slogans. But if you want to provide good customer service this is one requirement. There are plenty of others: continual improvement, evidence based management, customer focus, systems thinking

These thoughts were prompted by a nice post, jetBlue Just Blew It

You see, when I booked my flight last night I used their online system (good) and made a mistake in booking the date for my return (bad). I’m going to Boston for the weekend and accidently booked by return flight a month later in August instead of the 4 days I was looking for.

Of course their site has a lot of bookings and almost no one makes an error like this. But any UI designer who looks at their site could see that it’s absolutly possible since the length of the trip is never revealed except for the flight dates. (I”m arguing that they could put in a little fading header that tells you how long your trip is for.) If’ I’d see anywhere that my trip was scheduled for 35 days I’d have immediately know there was an issue. (I could make a simple change to the jetBlue UI that would solve this problem for everyone within a day.)

Today when I looked at my emailed itinerary I immediately spotted the problem and went online to change my ticket. They have a $100 change fee which I paid thinking I’d give them a call and that surely they’d waive that. After all, it wasn’t a change I was asking for, it was the ticket I wanted in the first place. It was less than 24 hours and the flight wasn’t for a month.

But no.

In speaking to the customer service rep who ‘called’ a manager. I was informed that I had only a 4 hour window to make any changes and that after that, there was nothing anyone could do. You see, no one at jetBlue customer service has the ‘authority’ to refuse this fee. It was company policy that they couldn’t actually do anything.

Continue reading

Mistake Proofing Deployment of Software Code

This is a continuation of my previous post: Improving Software Development with Automated Tests. Lets look at a typical poka-yoke example. A USB connector must be put in the right way up – for the connection to work properly and the communication to occur as intended. So to mistake proof the process the connector won’t allow the USB device to be put in upside down – the hardware connection designed to not allow that type of connection.

Using a deployment process that prevents code from being submitted that has an error follows a nearly identical process. The process blocks an error from being made. It seems to me a process that blocks code with a bug from being deployed with an error is the basically the same as a USB connection that will not accept the device being put in upside down.

Mistake proofing in no way should limit focusing on improving the process. Mistake-proofing a process both improves it (many poka-yoke solutions make the process easier to use) and prevents an error in case you still try something wrong. So I see the automated tests as a way to serve as a backstop, in case the process improvement you made to the software development process failed in some form. Then the automated testing required to deploy would prevent the introduction of that error to the production environment.

Related: Checklists in Software DevelopmentBaking in Quality to Software DevelopmentCombinatorial Testing for Software DevelopmentGreat Visual Instruction Example

Combinatorial Testing – The Quadrant of Massive Efficiency Gains

My brother, Justin Hunter, gives a lightning talk on Combinatorial Testing – The Quadrant of Doom and The Quadrant of Massive Efficiency Gains in the video above. The following text is largely directly quoted from the talk – with a bit of editing by me.

When you have a situation that has many many many possible parameters and each time only a few possible choices (a few items you are trying to vary and test – in his example in the video, 2 choices) you wind up with a ridicules number of possible tests. But you can cover all the possibilities in just 30 tests if your coverage target is all possible pairs. When you have situations like that you will see dramatic efficiency gains. What we have found in real world tests is greatly reduced time to create the tests and consistently 2 to 3 times as many defects found compared to the standard methods used for software testing.

You can read more on these ideas on his blog, where he explores software testing and combinatorial testing. The web base software testing application my brother created and shows in the demo is Hexawise. It is free to try out. I recommend it, though I am biased.

Related: Combinatorial Testing for SoftwareVideo Highlight Reel of Hexawise – a pairwise testing tool and combinatorial testing toolYouTube Uses Multivariate Experiment To Improve Sign-ups 15%What Else Can Software Development and Testing Learn from Manufacturing? Don’t Forget Design of Experiments (DoE)Maximize Test Coverage Efficiency And Minimize the Number of Tests Needed

Justin posted the presentation slides online at for anyone who is interested in seeing more details about the test plan he reviewed that had 1,746,756,896,558,880,852,541,440 possible tests. The slides are well worth reading.
Continue reading

Interruptions Can Severely Damage Performance

Interruptions can severely degrade your performance. The type of work you are doing impacts the cost greatly. I have spent some of my time programming web applications. When I am doing that interruptions are a huge drain on my performance (for me the costs of interruptions while programming are far higher than any other type of work I have done – many times higher). If the interruption disrupts my flow (an interruption needn’t necessarily disrupt it I found, instant messages may not, while speaking to someone else almost surely would – it is a factor of how much of your brain much shift focus I imagine) it can take a huge amount of time to get back into a high performing state. Other work I do can be interrupted with much less impact. I am easily able to slip back into what I was doing.

For me the main cost of interruptions is the time it takes to get back to where I was before the interruption. And the cost is related to how much focus is needed to address what you are working on. Most programming takes a huge amount of focus.

Another big cost of interruptions is the increased risk of mistakes. When people are distracted and then have to go back to a task, and then are distracted, and then go back and… it is more likely they will miss a step or miss noticing some issue than if they can work without distraction. One tool to help cope for distractions that can’t be designed out are checklists.

Paul Graham addressed the importance of managing the system to provide uninterrupted time very well in, Maker’s Schedule, Manager’s Schedule

One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more

Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

Paul Graham’s article also shows why managers so often fail to adequately address this issue. Manager, by and large, work in an environment where interruptions are the work. I know, much of my time as a program manager is driven by interruptions and is doable even with many interruptions every day.

When managing you need to understand how big a cost interruptions have and design systems appropriate to optimize system performance for all parts of the system. The design of the system needs to take into account the costs and benefits of interruptions for those people working on various processes in the system.

Related: Understanding How to Manage GeeksExplaining Managers to ProgrammersWhat Motivates Programmers?Joy in Work – Software DevelopmentProgrammers CartoonChecklists in Software Development

Toyota’s Journey to Lean Software Development

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 OverviewToyota Canada CIO on Genchi Genbutsu and KaizenLean Software DevelopmentMy First Trip to Japan by Peter ScholtesToyota IT for Kaizen