Stop me if you’ve heard this one before: A developer walks into a business meeting and an argument ensues. The developer is furious about being asked to cut corners, write shoddy code and generally hack bits of software together in a way that makes a cheap plumber look good. Meanwhile the other side of the table is furious about the slow pace of development: the developers are spending weeks or months with no new features being shipped and nothing changing. The two sides have very different viewpoints on the best way to be successful.
Unfortunately, this isn’t a joke and there’s no punchline. It’s a very real problem in many companies. One I’ve seen many times. The business technology divide splits too many companies in half.
From talking to people on both side of this split it come down to a lack of understanding, neither side “gets” the other. Each side has a different set of basic assumptions they’re operating from, assumptions about value generation, accountability, professionalism, motivation and many more. It’s worth taking a quick overview of the areas where these differing assumptions come up. Needless to say this isn’t a complete list, nor is any point true in every (or even many) companies, rather its a range of the sort of issues that might come up.
Those with a business background think in terms of delivering value to customers. They argue that the purpose of a business is to create something valuable and give that to the customer (in return for money), and that quality software is one of a number of ingredients in doing so (along with others like speed of delivery, customer service, good relations and training users to use the software to name a few). From this perspective, if cutting a few corners means you can deliver some value to the customers sooner, then maybe it’s a good idea trade that off against software quality.
Developers tend to operate from the perspective that long-term value for customers comes as a side effect of good, well written software. Software that is well written tends to be faster, more secure, less buggy and easier to adapt, which leads to it being better suited to the customers needs, and hence providing more value. From this perspective, cutting a few corners and lowering software quality is a really bad idea, akin to shooting yourself in the foot.
Business make use of deadlines to solve the problems of decision making, cost control and coordination. When a faced with a choice of ideas it’s natural to want to know enough details to make a good decision. That means knowing how long something is going to take, which allows predictions on cost and revenue to be drawn up allowing the two to be compared. If the predicted revenue is higher than the predicted cost, great, and if a different project looks like it will generate more revenue with less cost, then that is a better choice. Once a project is in progress, progress vs deadlines are used to raise a flag if the costs look like they will be more than predicted, and to ensure that other parts of the business machine (marketing, distribution) are ready at the same time – after all, its not good to launch something to the market 4 months after your marketing department told everyone it would be available!
Developers on the other hand tend to use deadlines as a source of humour. Development can be split into 3 categories: Applying known solutions to known problems, applying known solutions to unknown problems, and creating unknown solutions to unknown problems (the question of unknown solutions to known problems is worth a post in its on right!). In practice, the first of those, known solutions to known problems tends to be very quick, leaving the developers spending most of their time working on the unknown in one form or another. Trying to apply a deadline to solving a problem with unknowns is fundamentally flawed, it’s trying to predict the unpredictable, which just ain’t rational behaviour. So no-one takes deadlines seriously and when they are not the target of ridicule, they are at best tolerated or at worst simply ignored.
Accountability is a word you hear a lot in business, though its rarely defined, so I thought it would be worth paraphrasing the wikipedia definition
A person is accountable for something when obliged to inform others about (past or future) actions and decisions, to justify them, and to suffer punishment in the case of eventual misconduct
The business view of accountability is a positive one. It’s the basic building block which allows work to be delegated, and in doing so allows the clear communication required for business to scale. A CEO can delegate a department to a senior manager, and that manager is accountable for that area of the business. (S)he can then delegate parts of the department to middle managers, who are accountable or them and so on. Without accountability you would have chaos, with no-one knowing who was doing what. Some work would get done multiple times, and other bits of work would not get done at all!
Developers also tend to have a positive opinion of accountability, for the same reasons, but they often have a poor experience of it. The crux of the problem is the either/or nature of accountability, it tends becomes a case of “either justify your decisions or suffer the punishment”. Software is both complex, and unpredictable, so complicated problems often come up and cause delays (or other issues) which results in a “justify your decisions” meeting. When the explanation and justification is given, it tends to be as complex as the problem, it needs to be to be accurate. However the technical explanation doesn’t make sense to the average business person. The technical details go over their head or are “dumbed down” making them sound condescending, either way it doesn’t feel like a good justification, it feels like an excuse. That tends to trigger the “suffer the punishment” clause. In the software world that often means working overtime, or engaging in a death march, at which point the developers feel that they are being punished for the fact that software is complex.
The above list is certainly incomplete, and it’s almost certainly inaccurate. Solutions exist to a lot of these problems and they’re starting to be more wide spread. I plan to grow this list, and to look at each of the items in more detail in future posts, including some of the ways in which they are being tackled in real organisations.