I took my first programming class (FORTRAN, of course) in college in 1970. I spent a lot of time in the past half-century doing software work: requirements, design, user experience, programming, testing, project management, writing documentation, process improvement leadership, writing 7 books and many articles, consulting, and training.
Sure, there were some side trips along the way, like getting a PhD in organic chemistry (one-third of my thesis was computer code) and working as a research scientist for a few years. But basically I’m a software guy.
Over all that time, I’ve accumulated numerous insights about the software business. Here I offer 66 of those lessons. Perhaps you’ll find them as helpful as I have.
On Requirements
1. If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project. You will fail.
2. A collection of sticky notes you found on your desk after lunch, saved voice mails and emails, and a half-remembered collection of random hallway conversations do not constitute a set of requirements. It’s just a pile of information.
3. Nowhere more than in the requirements process do the interests of all the project stakeholders intersect.
4. Without high-quality requirements, stakeholders might be surprised at what is delivered. Software surprises are almost always bad news.
5. When exploring requirements, think beyond the hands-on users. Your customer once removed is still your customer.
6. People don’t simply “gather” requirements. Requirements elicitation is a process of exploration, collaboration, discovery, and invention, not a simple collection process. A business analyst is not a mere scribe.
7. The purpose of requirements elicitation is to bring the voice of the customer — the VOC — as close as possible to the ear of the developer — the EOD. The business analyst facilitates bridging that communication gap.
8. Two commonly used requirements elicitation practices are telepathy and clairvoyance. They don’t work.
9. Despite what our culture maintains, the customer is not always right. Sometimes the customer is misinformed, unreasonable, or in a bad mood. But the customer always has a point, and you have to understand and respect that point.
10. Requirements development demands iteration. You can’t get all the requirements right with the first discussion; you probably can’t get them all right ever. Effective requirements development involves the progressive refinement of detail and clarity.
11. Don’t be afraid of documenting requirements. The cost of recording knowledge is small compared to the cost of acquiring that knowledge.
12. If some capability or characteristic is not described in the requirements, no one should expect to see it in the product.
13. The deliverable from requirements development is not just a set of written requirements. It is a shared understanding and a shared set of expectations.
14. The realistic goal of requirements development is not to create a perfect set of requirements, but to create requirements that are good enough to let the team proceed with construction at an acceptable level of risk. That risk is having to do excessive, unplanned rework because of overlooked, unnecessary, incomplete, ambiguous, or poorly communicated requirements.
15. We sometimes express requirements casually because we assume the reader has a “sensibility filter” similar to our own, but people often interpret the same statements in different ways. This ambiguity leads to mismatched expectations and surprises upon delivery.
16. Keep requirements workshops and review teams small. A large group of people cannot agree to leave a burning room, let alone agree on exactly how some requirement should be worded.
17. The first question to ask when someone proposes a new requirement is, “Is this in scope?” If yes, it must be addressed. If no, it does not, at least not now. But if the answer is “No, but it ought to be,” then you must adjust the scope to accommodate it. This has implications for cost, schedule, resources, commitments, priorities, and trade-offs.
18. If you don’t have a documented and agreed-to project scope, how can you even tell if you’re experiencing scope creep?
19. Avoid “decibel prioritization” when deciding which features to include in a product or iteration. The loudest customers aren’t necessarily demanding those features that are most important from a business perspective.
20. Project stakeholders must understand the difference between discussing a possible requirement and committing to include it in the product.
21. Two terms that should make your blood run cold are “assumed requirements” and “implied requirements.” Strive to communicate requirements expectations explicitly.
22. Requirements quality is in the eye of the reader. It doesn’t matter if the author thinks the requirements are “good enough;” the audience for the requirements make that determination. That’s why you need their input through peer reviews of requirements.
On Project Management
23. There’s no such specific activity as “project management.” Project management is an amalgam of people management, requirements management, risk management, opportunity management, expectation management, commitment management, change management, resource management, and supplier management.
24. Why do organizations never have time to build software right, yet they always find the time, money, and people to fix it later? It’s a mystery.
25. Everyone likes to think their team has top-flight talent, but half of all software developers are below average in capabilities. Where do all those people work?
26. Don’t give anyone an estimate off the top of your head. The best response to a request for an estimate is, “Let me get back to you on that after I’ve thought about it.”
27. No matter how much pressure others apply, never make a commitment you know you cannot fulfill.
28. You’re in a stronger negotiating position when you have data available to build your case, because the other person almost certainly has no data at all.
29. Unless you record your estimates and compare them to what actually happened, you will forever be guessing, not estimating.
30. An estimate you give someone should not be influenced by what you think they want to hear.
31. The project manager must have some flexibility around at least one of the five key dimensions: scope, schedule, staff, budget, and quality. If these are all imposed as constraints, you will fail.
On Quality
32. When it comes to software quality, you can pay me now or you can pay me a lot more later.
33. Strive for perfection; settle for excellence.
34. Never let your boss or your customer talk you into doing a bad job.
35. Quality should be your top priority. Long-term productivity is a natural consequence of high quality because the teams need not spend so much time on wasteful rework.
36. Strive to have a peer, rather than a customer, find a defect. Technical peer reviews are a proven technique for improving quality and productivity.
37. Software people are always looking for cool tools, but remember that a fool with a tool is just an amplified fool.
38. An ounce of design is worth a pound of refactoring.
39. Today’s “gotta get it out right away” development project is tomorrow’s legacy system maintenance nightmare.
40. Many problems with software systems take place at the interfaces: software-to-software, software-to-hardware, software-to-people, people-to-people. Study them carefully.
On Process Improvement
41. I’ve never known anyone who could honestly say “I am building software today as well as software could ever be built.” If you can’t, then you should always spend part of your time seeking better ways to work and learning how to apply them in practice.
42. No software engineering technique will work if you’re dealing with unreasonable people.
43. When people are asked to work in some different way, their instinctive reaction is to ask “What’s in it for me?” But that’s the wrong question. The right question is “What’s in it for us?”
44. Enabling process change is hard when people aren’t aware of the pain caused by their current ways of working. It’s hard to sell a better mousetrap to people who don’t know they have mice.
45. Q: How many software process leaders does it take to change a light bulb?
A:Only one, but the light bulb must be willing to change.
46. Don’t underestimate the need for — and the difficulty of — changing an organization’s culture as it moves toward new ways of working. Installing a new process is faster than instilling a new culture. You need both to succeed.
47. Regardless of good intentions, improvement action plans that don’t turn into actions are not useful.
48. Common sense, good judgment, and experience should trump formal process in many cases. Sometimes the process is there for a good reason, though. Find out before you decide to bypass it.
49. When steering an organization toward new ways of working, use gentle pressure, relentlessly applied.
50. The best motivation for changing how people work is pain. Not artificial, externally-applied pain, but the very real pain the team experiences from its current ways of working. Select those improvement activities that will ultimately reduce the pain.
51. Unless you take the time to conduct retrospectives, study lessons learned, and continuously improve your team’s process, there’s no reason to expect the next project to go any better than the last project.
52. You can’t change everything at once. Identify those process changes that will yield the greatest benefits and begin to implement them next Monday. I’m not kidding: next Monday!
53. Adopt a “shrink to fit” philosophy with document templates. Begin with a rich template that reminds you think of information that should perhaps be included, and then mold it to the size, nature, and needs of each project.
54. Many teams are being asked to do more with less. Too often, though, they aren’t provided with ways to enable them to do more with less. Without training and process improvement to increase efficiency and effectiveness, don’t expect higher productivity to magically happen.
55. Informal processes that work fine for four people working in a single room do not scale to multiple development teams working on different continents.
56. If there’s one thing the software industry is repeatable at, it’s doing the same silly things on project after project. Use retrospectives to learn, to understand, and to improve continually.
57. Any time people aren’t following an established process you have only three choices: (1) start following the process; (2) adjust the process to make it more effective and practical and then follow it; or (3) throw away the process and stop pretending you follow it.
Other Insights
58. Artificial intelligence is no substitute for the real thing.
59. In the technology world, if you’re one week ahead of the other guy, you are a wizard.
60. People talk a lot about their “rights.” The flip side of every right is a responsibility. Think and act collaboratively.
61. Watch out for “Management by Businessweek,” the rush to adopt the Hottest New Thing in software development just because someone read about the fabulous results it promises.
62. Hold your thumb and index finger one inch apart. Most of the time that’s the only difference between quality and crap. It’s a matter of listening a little bit more, checking your work, running the test again, referring to the checklist, reading the directions, asking one more question. Often that’s all it takes to close the crap gap.
63. You don’t have time to make every mistake that every software practitioner before you has already made. Read and respect the literature. Learn from your colleagues. Share your knowledge freely with others.
64. Software development is perhaps 50 percent about computing and 50 percent about communication. But business analysis is entirely about communication. We are much better at the computing part.
65. If you’re hanging out a shingle as an independent consultant or a contractor, you need to inform the world that you’re available. It doesn’t matter how good you are if no one knows you’re there.
66. We do a lot of pretending in software. We pretend we’ve identified the right stakeholders, they understand their business objectives, and they know their requirements. We pretend the right people communicated the correct requirements to us and that we understood them and recorded them accurately. We pretend our estimates are accurate and that we’ve thought of all the necessary tasks. We pretend none of the risks that could undermine our project will materialize. I’m not a big fan of pretending. Sometimes I’m not that crazy about reality, but it’s all I’ve got, so I have to deal with it. Let’s stop pretending.
Author: Karl Wiegers, Principal Consultant at Process Impact
Karl Wiegers is Principal Consultant at Process Impact, a software development consulting and training company in Portland, Oregon. He has a PhD in organic chemistry. Karl is the author of numerous books on software development, most recently Software Requirements, 3rd Edition (with Joy Beatty). He’s also the author of Successful Business Analysis Consulting: Strategies and Tips for Going It Alone, a memoir of life lessons, and a forensic mystery novel, The Reconstruction. You can reach him at ProcessImpact.com or KarlWiegers.com.