If I’d listened to customers,
I’d have given them a faster horse.
– Henry Ford

It’s so easy to say yes. Yes to another feature, yes to an overly optimistic deadline, yes to a mediocre design.

Soon, the stack of things you’ve said yes to grows so tall you can’t even see the things you should really be doing.

Start getting into the habit of saying no -even to many of your best ideas. Use the power of no to get your piorities straight. You rarely regret saying no. But you often wind up regretting saying yes.

These days I’m re-reading Steve Maguire’s Debugging the Development Process, which is one of the first “realistic development process” books I read, almost two decades ago!

By “realistic” I mean that it takes into account that it is human beings who make software, and that how we communicate and what we feel about ourselves, the team and the process itself is crucial. Processes do not create software: people do. People comes first, processes second; it follows that it is processes that must fit people, not the other way around.

But, back to the book…This book is at least 16 years old, and it shows: no agile-speak here, for example. Yet, this must be the third or fourth time I read it, and the book still feels fresh.

Why is this so? I think that Maguire just keeps pounding on some underlying principles that will always hold, timeless principles that will never change:

You must be focused and have a clear purpose.

You must be concrete and explicit.

You must do things, instead of letting them happen.

You must be courageous.

You must believe that good enough never is: there’s always a better way.

The declared problem tends not to be the real problem: difficult problems tend to be difficult because they are not what they look like, what you are seeing is not what is there.

You must care about people: care that is shown via actions, not PR speeches -people almost always resent just-talk-the-talk PR campaigns aimed at them.

You must choose the right people/company: you must know your culture and choose the people and companies that are closer to it, because bypassing what’s deeply important to us is very straining, and you just can’t be the best at doing something you don’t believe in.

…

If you read the book paying attention to this, you will find Maguire provides a thousand concrete policies that work in the right direction to fulfill one or more of these timeless principles. Here are some examples…

Be focused

From chapter 1, Laying the Groundwork:

“Focus on improving the product… any work that does not result in an improved product is potentially wasted or misguided effort”

“The project lead should ruthlessly eliminate any obstacles that keep the developers from the truly important work: improving the product”

“Always determine what you are trying to accomplish, and then find the most efficient and pleasurable way to have your team do it”

“…one way to keep (housekeeping work) to a minimum is to regularly ask the questions ‘what am I ultimately trying to accomplish?’ and ‘How can I keep the benefits of the task yet eliminate the drawbacks?’”

From chapter 3, Of Strategic Importance:

“Don’t waste time on questionable improvement work. Weigh the potential value returned against the time you would have to invest”

From chapter 4, Unbridled Enthusiasm:

“If you hold a meeting that doesn’t end in a decision, that meeting has probably been a waste of time…Try to eliminate unnecessary follow-up work. I think you’ll be surprised at how many follow-up tasks don’t seem nearly as important by the end of the meeting as they did earlier, in the middle of an intense discussion”

From chapter 6, Constant, Unceasing Improvement:

“People often ask for something other than what they really need. Always determine what they are trying to accomplish before dealing with any request”

Be concrete and explicit

From chapter 1:

“At the very least, you should establish a ranking order for these priorities: size, speed, robustness, safety, testability, maintainability, simplicity, reusability, portability…in addition to ranking coding priorities, you should also establish a quality bar for each priority…otherwise, the team will have to waste time rewriting misconceived or substandard code”.

From chapter 2, The Systematic Approach:

“As you put systems in place, explain the purposes behind them so that the development team can understand what aspect of the product the systems are meant to improve”

From chapter 6, Constant, Unceasing Improvement:

“If you want your team members to make great leaps as well as take incremental daily steps to improvement, you must see that they actively pursue the greater goals…let them choose the skills they want to pursue…and merely verify that each goal is worth going after [by making sure] the skill would benefit the programmer, the project, and the company…the goal is achievable within a reasonable time frame…the goal has measurable results…[ideally] the skill will have immediate usefulness to the project”

Be courageous

From chapter 3, Of Strategic Importance:

“Sometimes there are questionable requests…a large corporate client had requested the LAYOFF macro so that they could lay people off without anybody being able to claim that the selections were biased [!]. The company would be in a position to simply point to Excel to prove their innocence…The task fell to me and I refused to implement the request…for months we beat the marketing team’s persistent requests for the feature. Marketing felt they needed the macro to close the sale…”

Care about people

From chapter 6, Constant, Unceasing Improvement:

“If you constantly expose a team member to new tasks that call for new skills, he or she will eventually reach a point at which your project no longer offers room to grow…for the benefit of the company, you should kick such an expert off your team…You have a duty to the programmers and the company to find the programmers positions in which they can grow”

From chapter 8, That Sinking Feeling:

“If your project is slipping, something is wrong. Don’t ignore the causes and demand long hours of the team members. Find and fix the problems”

On and on…

Maguire keeps on adding lots of foolproof advice throughout the book; most of it solidly rooted on the belief that it is people that makes software great -or a mess. I can’t agree more with him!

Yes, Debugging the Development Process is old…so, what? Some principles are timeless, and Maguire knows how to materialize them with concrete policies.