When starting a project for a company that's not primarily a programming company, one of the expectations is that there's a finished product at the end free of all bugs and does everything needed right away. However, that's rarely the case.
What are some ways to manage expectations and explain to non-programmers how software development differs from other types of product development?
Pretty much everybody with a computer has encountered the concept of "bugs" these days, so you might start there. "What's the most annoying way an application has ever failed on you? Multiply that by ten, and you'll have our users' experience if we don't devote enough resources to testing and maintenance."
And don't underestimate the value of establishing a good working relationship with the non-programmers. If you can establish that your judgment may be trusted, they'll take you seriously when you sound the alarm that X is going to fail spectacularly if you don't do Y pronto, even if they don't completely understand your reasoning.
One approach that I've found successful is this:
We all know that a computer does only and exactly what it is told to do.
Programming is the way that we tell a computer now what we what it to do later.
This means that the way your behaviour behaves now is due to the combined intentions of everyone who wrote any of the code that is running on your machine. When you consider the complexity of the operating system, drivers, programming environment, libraries and so on, it's easy to see that in most systems there must be upwards of 20k people involved, and that there could be over 100k.
The code written by each person reflects their own understanding, motivation, intention and capability. Given that flawless operation of the system requires that all of the code written by these 20k people interacts without error - that all of the code must agree on the meaning and interpretation of the required behaviour, the suprising fact is not that we have bugs, but that we have so few of them.
IMO, I've found that the transparency offered by agile processes (e.g. Scrum, Crystal, etc.) goes a long ways towards showing how development works to the average stakeholder.
Explanation by metaphor is a leaky abstraction, but here are some ideas that often work for me:
Note that none of these explanations excuse sloppy work.
Think of a computer program as machine, where every variable is a moving part. That makes even a trivial program a machine composed of hundreds of moving parts.
When that fails, I fall back on the fact that while it is mathematically possible to prove that a program has no errors, it takes huge amounts of time and won't be worth the effort.
Finally, I ask if Intel and Microsoft are unable to avoid bugs, how do they expect us to?
I've answered a similar question in more detail, but the gist is, "Programming is like building a factory or an assembly line."
The traditional way of stating it is the Project Management Triangle: the three competing criteria of scope, cost, and schedule; typically expressed as "cheap, fast, good -- pick two".
At the end of a design, development and deployment process, the expectation that a product is is relatively free of design flaws and operates with a specified functionality is perfectly reasonable. The same expectation is completely unreasonable with respect to a project, process, or profession.
What professional based on sciences, hard or soft, does not go through a process of exploration, forming inaccurate and imprecise conceptualizations, following less-than-optimal (or just plain wrong) tactics, discovering what works through trial and error, and repeating the process over and over again till either resources run out or a sufficient level of performance is attained?
No process is ever free of flaws, although it can asymptotically approach higher quality levels.
That is true of the medical profession where tactics often involve guesswork and protocols, and much of the activity is basically debugging a mostly wetware machine. It is true of civil engineering and architecture where applications of novel engineered materials have to be field validated and can fail abruptly after years of service despite strict adherence to standards. It is true of the automotive field where age and changes in operating conditions commonly affect performance to the point of failure, through no fault of the engineering or repair services applied. Software development is not fundamentally different from these professions in such respects, it just has a greater part of its focus involved in contriving novel, purposeful machines.
If you have any familiarity with hi-rel software development, such as for nuclear reactor control, deep space communications, or medical implant devices (etc.), you might explain how the cost and delivery time structure for that level of priject management and QA might be magnitudes greater than what typical businesses can afford for their software projects.
You might compare it to something they can see and if possible, use everyday.
For example, the automobile. Cars started as much less refined and reliable devices than we have today. While cars have been made for over 100 years, but software probably about half that long. Cars are available with significant customization, some included in the price (like choice of color), others like engine size, transmission type, wheel/tire, trim level are significant cost drivers.
There are many feature, quality, and cost drivers for cars, and for software. Then you can discuss how software technology, availability of expertise, maybe even where it is built will make a big difference. Appropriately development cycles (for example, yearly models with small changes, body/engine/platform changes about every three years) are driven by a combination of customer needs and a complex design process. Some products start small and dumpy looking (think of the Honda Accord), but get improved every year until they are top rated.
Cars have recalls (often way more costly than software upgrades) and incremental improvements in the form of running changes to their parts lists (think bug fixes), and often they need long term support (think backward/forward compatibility). Much of the cost of your car comes after you drive it home. Much of the software cost comes after the initial product release as you update and upgrade customers.
In some cases, you can reference well known products that include software or other software products. For example, phones have a release cycle and updates and methods of adding functionality after the initial sale to build more revenue. Phones are a great illustration of forward / backward compatibility. Too much, and people won't dump the old one to buy a new one. Too little, and customers get desperate to have a phone they won't hate before its contract is up.
Products like Windows, Microsoft Office, web browsers, and web pages are all software that can be used in discussions. They have been updated on annual or three year cycles, but may have automatic updates more frequently. They have bugs and security holes that affect customers to varied degrees, but are a part of the landscape despite our best efforts. Customers can get fixes free, but generally pay for enhancements, often as a bundle, sometimes as an individual module or via an licence key.
Industry leaders like Microsoft, Apple, Google, and Amazon all deliver relatively inexpensive customers to users. But they have huge expenses that enabled those products. Their experience shows that software is expensive, but valuable and profitable. They often compromise between quality, having all the features they want, and getting into markets when the timing is right. Not every product they make is a success, and they sometimes turn dogs into winners by renaming, improved marketing and sales, or cutting their losses and using what they learned in later products.
Perhaps try walking them through, one-on-one or in small groups ideally, use cases of software you have to develop. As they describe the use cases, identify points in the case where different things could happen (unexpected but not unreasonable cases). Start to enumerate them, ask for some clarifications, and illustrate all the decisions and directions that need to be made or settled on, and the trade-offs being made in doing so. Keep going until they are stumped and can't give you an answer. Get them to understand that, what you're doing now with them, is exactly what you do all day, probably on your own, probably with a lot less clear direction, both deciding the course and writing the code, for hundreds or thousands of use cases that may or may not even be laid out by anyone. And when there's a case you had not thought of yourself, you can't guarantee what the program will do. Maybe it does the "right" thing, maybe note. And that's what a bug is. And that's why writing software takes time. The less time you have, the less cases that you had a chance to consider and accommodate, and the more likely the program will not do the "right" thing in an unknown circumstance.
Cost and Time.
Time
Set expectations that you would deliver X in Y amount of time. It will have nothing more, nothing less. Then tell them what the next version will have in what time. At first they might get surprised to believe that building X takes Y amount of time - this is where you explain the time taken and complexities of building a software. If they are not surprised, either you estimated very less time or they knew better than you think about building software.
Cost
This is from Steve McConnel's Code Compete book(quoting from memory, so pardon me if I couldn't convey it with the same effect) - It is easy for customers to ask for new features. As a product manager, you should not say to what customer asks. You should estimate how much effort and cost it takes to build that new feature. They will slowly understand that the new feature is not really worth the money/time or perhaps that they don't even require it. I'm not suggesting that you use this a weapon to scare them, but use it honestly and it might help in driving the point home.
Metaphors are leaky abstractions, yet they are little step that take you closer to understanding.
My fave is that building software is often though as a process similar to architecting a house. Yet it's more precise to think of it as creating a system which prints out a custom-architected blueprint based on some parameters and builds a different one for each of its users. In geek talk that be meta-architeting.
I have discovered, that it might actually help when you show them what it means to write code. Show the stakeholders the codebase you're working with. Even when you've chosen good variable and method-names, most of the people will think you're using some sort of black magic. Maybe they'll understand, why you need more than "a few days" to implement a new feature for their software.