Stories Told

Even a mediocre plan will work if everybody follows it

I have been astonished in my life by how few problems are truly unsolvable. I have also noticed that, most of the time, when a problem ends up not being solved it is for one of two reasons: people deny the problem, or they won’t work together on the solution.

I make software for a living. We have a saying in software development: There are two things you don’t want to know how are made – sausage and software.

There are any number of ways to make software. All of them involve programming, of course; it’s the core activity. But there are other jobs to perform, and the bigger the software being developed, the more people you need to perform them. It becomes necessary to organize the people and form work processes. The ways to do that range from loose and chaotic to structured but flexible to ponderous and formal. They all have their strengths and weaknesses; they all can work. I’ve made software in all of these situations.

Scenes from US 50One of my past employers sequestered its programmers in a room to hack code together as fast as they could. When they were done, a couple people would play with the product for a week or two in hopes of finding some bugs, which the programmers might or might not fix. Then we shipped it to five customers, who upon installing it invariably found that it failed spectacularly. When we fixed all the problems they found, we chose five more customers. We repeated this process until the software stopped failing, and then announced to the rest of our customers that it was ready.

At the other end of the scale, another past employer had such a heavy software development process that following it felt like slipping into a straitjacket. There were reams of documentation to write and keep with layers of approval at each step. I worked on a team that tested the software to make sure it did what it was designed to do. We had to take a screen shot of every test step, print it, and put it in a folder. At the end of a project, we had boxes and boxes and boxes of printouts, hundreds of pounds worth, that we would send to an offsite storage facility. This was in case our only customer, which happened to be the U.S. government, wanted to audit us.

Both companies are still in business.

Brick segment of old US 40/NRA third past employer carefully hired smart people and trusted them to know what to do. Because they hired well, this worked for a long time. But as the company grew, this approach became more and more difficult to manage. Product quality became a problem. A big part of the software was an accounting package, and in one fateful release the general ledger simply would not balance. This affected every customer, and to make a long story short, it took the company almost a year to fix it. Several customers quit us.

Too often it takes great pain to drive important change. This pain made us face that we needed more structure to deliver successfully. So we hired a consultant to guide us toward a better software development process. He showed us a way with just enough checks and balances that we could have greater confidence in our work without being too bogged down. We also hired a consultant to help the management team (of which I was a part) work more collaboratively. She taught us how to lead the company through this transition.

It worked. In the very first product release under the new process, quality problems fell off dramatically and we delivered on time for the first time anybody could remember.

The more important hire was the second consultant. The new methodology was good, but it wasn’t magic, and it might not have worked for us if we had not done a good job helping the team through the changes. You see, a few people didn’t understand why the old way couldn’t still work and still others thought our new process wasn’t going far enough. Our task was to overcome the resistance and get everybody singing from the same sheet of music, and it was the hardest thing we did. But we pulled it off.

It’s a rare organization that faces its failings and works to change. It’s a rarer organization still that drives change collaboratively.

The company with the ponderous process
fired me.
 I’m so glad. Read that story.

Advertisements
Standard

10 thoughts on “Even a mediocre plan will work if everybody follows it

  1. ryoko861 says:

    I think they call it “teamwork”. A well oiled engine works best if all the components are working in sync with eachother. When one of those components decides it doesn’t want to go for the long haul, it will effect the others in their own components, causing friction and over worked parts.
    Yes, it is rare to find an organization that agrees to spend a little money that will result in making MORE money!

    Like

    • I sometimes jokingly say, “My favorite problems are the ones that go away when you ignore them long enough.” I think that sometimes recognizing that there’s a problem is hard, and then coming up with a solution is hard, and then working together to implement it is hard. So it’s often easier to just hope it fixes itself in time!

      Like

  2. Angel says:

    I have been reading your blog via email updates for over 2 years now, but I rarely comment. I just have to say, though, that this was an outstanding post. I hope you don’t mind if i show it to my instructor for my Database Design class. (With proper credit to you given, of course!) We’ve been having some problems with teamwork, getting people to collaborate and communicate – and all we are doing is a very basic, incredibly simplified database project, which we had 10 weeks to complete. It’s nearly impossible that I will get any credit for it, however, since our “team leader” has kept the master and won’t email it to the rest of the team for update or review. Teamwork is so powerful; it can either make or break even the simplest of tasks.

    Like

    • Angel, you most certainly may share this post. Sometimes those short, simple projects are the hardest, because the players underestimte the need for collaboration and process.

      Like

  3. Anonymous says:

    An excellent post again, Jim.
    I proofread for a living for a family-owned communications company. If it weren’t for a whole slew of intangibles that has kept me there, I should have bolted long ago when they proved themselves unwilling to deal effectively with solicited anonymous negative criticisms of their culture and operation. They are just SO fortunate to be blessed with people who have a strong work ethic that makes doing their best for themselves enough motivation to keep them plugging away. If only the company knew how blessed they are with their workforce, and was willing to show them how valued they are, I can hardly imagine just where we could go.
    Thanks again for your excellent posts. I have never yet been disappointed.

    Like

    • I’m so glad you enjoy reading along. I’m going to challenge you a little bit, though. You and your co-workers may inadvertently be enabling your company’s poor culture by always rising to the occasion so things get done!

      Like

  4. Lone Primate says:

    I remember when I started as a tech writer… they used to make us work from these design documents. They were full of screen captures from the GUI design team, elaborate lists of where the user clicks, in what order, to fill out what dialog, to do what job… in conjunction with software that was being tweaked, changed, and given a facelift on a weekly basis. I hated working with them. I said, why can’t we just work with the finished software? (See, I was still a little naive about the realities of software development and timely releases including the contractually obligatory documentation…)

    Then I changed jobs to a company where the design documents were not much more than one of the VPs blueskying stuff like, “Program starts, module is selected, magic happens”. And they wanted us to work with that… alongside software that was being tweaked, changed, and given a facelift on a weekly basis. Boy, did I miss the old design documents then. It’s funny what will spin straw into gold for you.

    Like

    • The trend for 10+ years has been away from voluminous up-front design documentation. Our tech writers have been so frustrated with how wrong those documents ended up being that they used them only as a rough guide but worked with the product managers and developers to get the real skinny. They learned how to insert themselves into the right discussions so they would have half a clue about the product as it evolved. It’s not perfect, but they seem to find this to be more effective than relying on up-front design docs that end up not being true because reality intervened during programming.

      Like

Share your comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.