em

HackNot - Management

Part of Hacknot: Essays on Software Development

To The Management 1

I am frequently frustrated and disappointed in the standard of management I am subject to. Discussions with my peers in the software industry lead me to believe that I am not alone in my malaise. So on behalf of the silent multitude of software professionals who are disappointed with their management, I would like to remind you - the project manager, team leader or technical manager - of those basic rights to which your staff are entitled.

The Right To Your Courtesy And Respect

Of the complaints I hear directed towards management, the most frequent concern dishonest, abusive or otherwise inappropriate behavior. Remember that no matter how angry or frustrated you may be feeling, it is never okay to direct that anger towards your associates. Intemperate outbursts only engender disrespect and generate ill feeling. As a leader, you are obliged to behave in an exemplary manner at all times.

Respecting your staff implies valuing their opinions, and being prepared to accept their determinations in areas where their expertise is greater than your own. It means acknowledging and accommodating the technical obstacles they encounter, rather than trying to usurp reality with authority.

The Right To Adequate Resources

Skimping on software and hardware resources is an obviously false economy, as a deficit of either impedes your most expensive resource – your people. More commonly overlooked are such environmental resources as lighting, storage space, desk space, ergonomic aids and whiteboards. Workers quickly become dissatisfied if the basic elements of a productive environment are absent.

The resource generally in shortest supply in a software development environment is time. It’s not surprising then that unrealistic scheduling is one of the greatest sources of conflict between technical staff and their management. Please keep this in mind

  • successful scheduling is a process of negotiation, not dictation. Nobody knows more about how long a particular task will take to complete than the person who is to complete it. Your team has the right to be consulted on the scheduling of those tasks they are responsible for, and to be able to meet their commitments without undue stress or hardship.

The Right To Emotional Safety

In many corporate cultures there is a stigma associated with being the bearer of bad news. To ensure that individuals feel safe in expressing unpopular truths, you must not only accept, but also welcome bad news as an opportunity to avert a more serious problem later. Ultimately, you are reliant upon others to keep you apprised of the project’s technical progress, so it is obviously beneficial to obtain their insights in uncensored form. For their part, technical staff need to feel that they can openly seek help with their problems, without risk of punitive repercussions.

In a human-based endeavor like software development, mistakes and failures are inevitable. Staff rightfully expects a compassionate attitude from you when dealing with their own failures. When they underestimate a task’s completion time, or inject a defect into the code base, they need help in correcting the underlying problem, not castigation for the symptom.

The Right To Your Support

Your staff has the right to expect your assistance in dealing with the issues they encounter. Responsiveness is paramount - issues need to be dealt with in a timely manner, before they can fester into full-blown crises. You must be willing to put aside self-regard and do whatever is necessary to resolve the issue as quickly as possible. This may mean making an unpopular decision, or entering into conflict with other managers. Without the courage and integrity to support your team in this manner, you compromise the well being of the project and the people on it.

Failure to proactively support your team’s efforts will necessarily disadvantage them. They have a right to presume you will use your experience and your high level view of the project to forecast the risks they may encounter, and prepare mitigation strategies accordingly.

The Right To Know

Your team expects decisions affecting project staffing, scheduling and scope to be communicated to them quickly and honestly. Unnecessary delays can limit their ability to respond effectively to changing conditions, with consequent stress and time pressure.

Some managers feel they have to shield their subordinates from the political machinations of their organization. This attitude betrays little respect for their team member’s maturity, and a basic ignorance of the technical personality, which values painful truths over comforting lies. Your staff has the right to know about anything that impacts on their work, so that they can maximize the chances of achieving their goals.

The Right To Self-Determination

There is nothing so disempowering as to be set goals, but have no control over the means by which one is to achieve them. This is the predicament in which you place your staff if you deny them the flexibility to tailor their work practices to the problem at hand, insisting instead on rigid adherence to methodological or corporate dogma. You may find political safety in playing it by the book, but your people want to work in a way that makes best use of their time and energy, and expect your support in achieving that goal.

It is my recurring observation that management practices that infringe upon the abovementioned rights are common. Equally common is the software professional’s lamentation that their management “doesn’t have a clue.” The two may well be causally related.

So I urge you to put aside your spreadsheets and Gantt charts for a moment and consider the rights of your subordinates. Focus on the basic principles of a humane management style - integrity, respect, courtesy and compassion. Their application cannot guarantee your success as a manager, but their absence will guarantee your failure.

Great Mistakes in Technical Leadership 2

“If you are a good leader who talks little, they will say when your work is done and your aim fulfilled, ‘We did it ourselves.’” – Lao-Tse 3

Perhaps the most difficult job to do on any software development project is that of Technical Lead. The Technical Lead has overall responsibility for all technical aspects of the project – design, code, technology selection, work assignment, scheduling and architecture are all within his purview. Positioned right at the border of the technical and managerial, they are the proverbial “meat in the sandwich.” This means that they have to be able to speak two languages – the high-level language of the project manager to whom they report, and the low-level technical language of their team. In effect, they’re the translator between the two dialects.

Observation suggests that there are not that many senior techies who have the skills and personal characteristics necessary to perform the Technical Lead role well. Of those I have seen attempt it, perhaps ten percent did a good job of it, twenty percent just got by, and the remaining seventy percent screwed it up. Therefore most of what I have learnt about being a good Technical Lead has been learnt by counter-example. Each time I see a Technical Lead doing something stupid, I make a mental note to avoid that same behavior or action when I am next in the Technical Lead role.

What follows is the abridged version of the list of mistakes I have assembled in this manner over the last thirteen years of watching Technical Leads get it wrong. It is my contention that if you can just avoid making these mistakes, you are well on your way to doing a good job as a Technical Lead. You might consider it a long-form equivalent of the Hippocratic Oath “First do no harm,” although given the self-evident nature of many of these exhortations, it is more like “First do nothing stupid.”

Mistake #0: Assuming The Team Serves You

Perhaps the most damaging mistake a Technical Lead can make is to assume that their seniority somehow gives them an elevated status in their organization. Once their ego gets involved, the door is open to a host of concomitant miseries such as emotional decision making, defensiveness and intra-team conflict.

I can’t emphasize enough how important it is to realize that although the Technical Lead role brings with it many additional responsibilities, it does not put you “above” the other team members in any meaningful sense. Rather, you are on an exactly equal footing with them. It’s just that your duties are slightly different from theirs.

If anything, it is you that is in service of them, given that it is part of your role to facilitate their work. To put it another way, you are there to make them look good, not the other way around.

Mistake #1: Isolating Yourself From The Team

In some organizations, having the title of Technical Lead gives you entitlements that the rank and file of your team do not enjoy. Sometimes, the title is considered sufficiently senior to entitle you to an office of your own, or at least a larger workspace if you must still dwell in cubicle land.

It is a mistake to take or accept such perquisites, as they serve to distance you (both physically and organizationally) from the people that you work most closely with. As military leaders know, it creates an artificial and ultimately unhealthy class distinction between soldiers and officers if the latter are afforded special privileges. To truly understand your team’s problems and be considered just “one of the guys” (which you are), you need to be in the same circumstances as they are.

Mistake #2: Employing Hokey Motivation Techniques

Different sorts of people are motivated by different sorts of rewards. Programmers and managers certainly have very different natures, yet it is surprising the number of managers and aspiring managers who ignore those differences and try to reward technical staff in the same way they would like to be rewarded themselves.

For example, managers value perception and status, so being presented with an award in front of everyone, or receiving a plaque to display on their wall where everyone can see it, may well be motivating to them. However programmers tend to be focused on the practical and functional, and value things that they can use to some advantage. Programmers regard the sorts of rewards that managers typically receive as superficial and trite. They have a similar view of “team building” activities, motivational speeches and posters and the like.

So if you want to motivate a developer, don’t start cheering “Yay team” or force him to wear the team t-shirt you just had printed. Instead, give him something of use. A second monitor for his computer will be well received, as will some extra RAM, a faster CPU, cooler peripherals, or a more comfortable office chair. It’s also hard to go wrong with cash or time off.

Developers are also constantly mindful of keeping their skill sets up to date, and so will value any contribution you can make to their technical education. Give them some time during work hours to pursue their own projects or explore new technologies, a substantial voucher from your local technical book store, or leave to attend a training course that interests them – it doesn’t have to be something that bears direct relationship to company work, just as long as it has career value to them.

Mistake #3: Not Providing Technical Direction And Context

A common mode of failure amongst Technical Leads is to focus on their love of the “technical” and forget about their obligation to “lead.” Leading means thinking ahead enough that you can make informed and well-considered decisions before the need for that decision becomes an impediment to team progress.

The most obvious form of such leadership is the specification of the software’s overall architecture. Before implementation begins, you should have already considered the architectural alternatives available, and have chosen one of them for objective and rationally defensible reasons. You should also have communicated this architecture to the team, so that they can always place the units of work they do in a broader architectural context. This gives their work a direction and promotes confidence that the team’s collective efforts will bind together into a successful whole.

A Technical Lead lacking in self-confidence can be a major frustration to their team. They may find themselves waiting on the Lead to make decisions that significantly effect their work, but find that there is some reticence or unwillingness to make a firm decision. Particularly when new in the role, some Technical Leads find it difficult to make decisions in a timely manner, for they are paralyzed by the fear of making that decision incorrectly. Troubled that a bad decision will make them look foolish, they vacillate endlessly between the alternatives, while their team-mates are standing by wondering when they are going to be able to move forward. In such cases, one does well to remember that a good enough decision now is often better than a perfect decision later. Sometimes there is no choice amongst technical alternatives that jumps out at you as being clearly better than any other – there are merely different possibilities, each with pros and cons. Don’t belabor such decisions indefinitely. In particular, don’t hand over such decisions to the team and hope to arrive at some consensus. Such consensus is often impossible to obtain. What is most important is that you make a timely decision that you feel moderately confident in, and then commit to it. If all else fails, look to those industry figures whose opinions you trust, and follow the advice they have to give.

Finally, always be prepared to admit that a decision you’ve made was incorrect, if information to that effect should come to light. Some of the nastiest technical disasters I’ve witnessed have originated with a senior techie with an ego investment in a particular decision, who lacks the integrity necessary to admit error, even when their mistake is obvious to all.

Mistake #4: Fulfilling Your Own Needs Via The Team

You will occasionally hear people opine that one should not let the personal interfere with the professional. In other words, difficulties at home should not interfere with the execution of duties in the workplace. In some environments, the obvious expression of emotion is simply taboo. But such ideas don’t mesh with reality too well. People are holistic creatures and our life experience is not so conveniently compartmentalized, no matter how desirable some Taylorist ideal may be.

Just the same, there are practical and social limitations upon workplace behavior which some may be tempted to flaunt, to the discomfort and embarrassment of their colleagues. The broader one’s influence, the greater the opportunity to co-opt activities that should be focused on work, and turn them to personal effect.

For example, meetings (complete with buffet) make a fine social occasion for those not concerned with making best use of company time. Teambuilding exercises provide an easily excused opportunity to get away from the office and out into the sun, as do off-site training courses and conferences.

Pair programming seems to be most appealing to those who like to chat about their work … continually. An excessive focus on group consensus-based decision-making for all technical aspects of the project, even the trivial ones, may be a sign that a Technical Lead is more concerned with the sociology of the project and their place amongst it, than with leadership and making efficient use of people’s time and effort.

Mistake #5: Focusing On Your Individual Contribution

Changing roles from developer to Technical Lead requires a certain adjustment in mindset. As a developer you tend to be focused upon individual achievement. You spend your time laboring on units of work, mainly by yourself, and can later point to these discrete pieces of the application and say, with some satisfaction, “I did that.”

But as a Technical Lead your focus shifts from individual achievement to group achievement. Your work is now to facilitate the work of others. This means that when others come to you for help, you should be in the habit of dropping everything and servicing their requests immediately. A fatal mistake some Technical Leads make is to try and retain their former role as an individual contributor, which tends to result in the Technical Lead duties suffering, as they become engrossed in their own problems and push the concerns of others aside.

The constant alternation between helping individuals with low-level technical problems and thinking about high-level project-wide issues is very cognitively demanding. I’ve come to call the problem “zoom fatigue”

  • the mental fatigue which results from rapidly changing between the precise and the abstract on a regular basis. It’s like the physical fatigue that the eye experiences when constantly switching focus from long distance to short distance. The muscular effort required within the eye to change focal length eventually leads to fatigue, making the eye less responsive to subsequent demands. Similarly, you get cognitive fatigue when in one moment you are helping someone with an intricate coding issue, and in the next you’re examining the interaction between subsystems at the architectural level. The latter requires a more abstract mental state than the former, and alternating between the two is quite taxing.

As a result, people may come to you seeking help with something that has been the sole focus of their attention for several hours or days, and you will find it difficult to “task switch” from what you were just doing into a mindset where you can discuss the problem with them on equal terms. I find it helpful to just ask the person to give me ten minutes to get my head into the problem space, during which I might retreat to my own machine and study the problem body of code in detail, before attempting to help them with it.

Mistake #6: Trying To Be Technically Omniscient

Just because you have the last word in technical decisions, don’t think that it is somehow assumed that you are the programming equivalent of Yoda. With the variety and complexity of development technologies always growing, it is increasingly difficult to maintain a mastery of any given subset of that domain. As in most growing fields, those who call themselves “expert” will progressively know more and more about less and less.

It is therefore entirely possible that you will be learning new technologies at the same time as you are first applying them. The mistakes you make and the gaps in your knowledge will be abundantly obvious to your team members, so it is best to abandon at the outset any pretext of having it all figured out.

Be open and honest about what you do and don’t know. Don’t try and overstate or otherwise misrepresent the extent and nature of your familiarity with a technology, for once you are found out, the trust lost will be very difficult to regain.

There is an opportunity here to widen the knowledge and experience of all team members. You might like to appoint certain people as specialists in particular technologies, giving them the time and task assignments necessary to develop a superior knowledge of their assigned area. To avoid boredom and unnecessary risk, be sure to give these resident experts plenty of opportunity to spread their knowledge around the team, and to exchange specialties with others.

Adopting this “collection of specialists” approach makes it clear that you are not presuming to be all things to all people; and that you have faith in the abilities of your colleagues. But it will require you to park your ego at the door and be prepared to say “I don’t know” quite frequently.

But be careful not to lean on others too heavily. It is still vitally important for you to have a good overarching knowledge of the technologies you are employing, particularly those elements of them that are critical to their successful interoperation in service of your system’s architecture.

Mistake #7: Failing To Delegate Effectively

To successfully lead a group, there must be an attitude of implicit trust and assumed good intent between the leader and those being led. Therefore a Technical Lead must be willing to trust his team to be diligent in the pursuit of their goals, without feeling the need to watch over their shoulder and constantly monitor their progress. This sort of micromanagement is particularly loathed by programmers, who recognize it as a tacit questioning of their abilities and commitment.

But ineffective delegation can also arise for selfish reasons. Several times now I’ve seen Technical Leads who like to save all the “fun” work for themselves, leaving others the tedious grunt work. For example, the Technical Lead will assign themselves the task of evaluating new technologies, constructing exploratory and “proof of concept” prototypes, but once play time is over and the need for disciplined work arrives, hand over the detailed tasks to others.

Not only is effective delegation desirable with respect to team morale and project risk, on large projects it is simply a necessity, as there will be too much information to be managed and maintained at once for one person to be able to cope.

Mistake #8: Being Ignorant Of Your Own Shortcomings

Some people simply don’t have the natural proclivities necessary to be good Technical Leads. It’s not enough to have good technical knowledge. You must be able to communicate that knowledge to others, as well as translate it into a simpler form that your management can understand.

You also need good organizational skills. Coordinating the efforts of multiple people to produce a functionally consistent outcome is not easy, and demands a methodical and detail-oriented approach to planning and scheduling. If you can’t plan ahead successfully, you will find yourself constantly in reactive mode, which is both stressful and inefficient.

If you don’t have these qualities naturally, you may be able to develop them to some extent, through training and deliberate effort. But it may ultimately be necessary for you to lean on others in your team to support you, should they have strengths in areas in which you have weaknesses.

Mistake #9: Failing To Represent The Best Interests Of Your Team

Perhaps the most nauseating mistake a Technical Lead can make is to become a puppet of the management above them. As the interface between management and technicians, it is the Technical Lead’s role to go into bat with their management to represent the best interests of their team. This means standing up to the imposition of unreasonable deadlines, fighting for decent tools and resources, and preventing the prevarications of management from disturbing the rhythm of the project. A weak-willed or easily manipulated Technical Lead will incur the disrespect of his team.

Unfortunately, such spineless behavior is quite common amongst the ranks of the ambitious, and you don’t have to look far to find obsequious Technical Leads who will gladly promise the impossible and impose hardship on their team, in the interests of creating a “can do” image for themselves.

Mistake #10: Failing To Anticipate

An essential part of the Technical Lead’s role is keeping an eye on the “big picture” – those system-wide concerns that are easily forgotten by programmers whose attention is consumed by the coding problem they currently face. These “big picture” issues include those non-functional requirements sometimes called “-ilities” - maintainability, reliability, usability, testability and so on. If you don’t make a conscious effort to track your progress against these requirements, there is a high probability of them slipping through the cracks and being forgotten about until they later emerge as crises.

If you don’t have a dedicated project manager, it may also fall to you to handle the scheduling, tracking and assignment of tasks. It isn’t uncommon for Technical Leads to find themselves playing dual roles in this manner. You may not be very fond of such “administrative” duties, but their efficient performance is critical to the smooth running of the project, and for the developers to know where they are and where they’re going. Don’t make the mistake of ignoring or devaluing these tasks simply because they are non-technical in nature.

Mistake #11: Repeat Mistakes Others Have Already Made

It is common for developers to dismiss the experience reports of others as having no relevance to their own situation. Indeed, it is wise to approach all anecdotal evidence with skepticism. But it is unwise to completely disregard the advice of others, particularly when it is accompanied by sound reasoning, or can be independently verified. Ignoring good advice can be very expensive; as Benjamin Franklin said, “Experience keeps a dear school but fools will learn in no other.”

The unwillingness of developers to learn from the mistakes of others, and the ease with which you can encounter software project horror stories in the literature and recognize your own projects in them, is evidence suggesting that the software industry as a whole is not getting any wiser.4 You need not contribute to that collective stupidity.

Mistake #12: Using The Project To Pursue Your Own Technical Interests

Remarkably, developers can reach quite senior levels in their organization without having learnt to appreciate the difference between work and play. Many are attracted to programming to begin with because, as hobbyists, they enjoyed fooling around with the latest and greatest technologies. Somehow they carry this tendency to “play” with technologies into their working lives, and it becomes the aspect of their jobs that they value most. From their perspective, the purpose of a development effort is not to create something of value to the business, but to create an opportunity to experiment with new technologies and pad their CV with some new acronyms.

Their technology selection is based upon whatever looks “cool”. But a rational approach to technology selection may yield quite a different result to one guided by technical enthusiasm or a fascination with novelty. New technologies are often riskier choices, as the development community has not had much time to apply the technology in varying circumstances and thereby discover its weaknesses and shortcomings. Putting an immature technology on a project’s critical path is especially risky. So an older, tried and true technology may be a more rational choice than a new, unproven one.

Mistake #13: Not Maintaining Technical Involvement

In order to fully appreciate the current status of the project as well as the difficulties your team is facing, it is vital that you maintain a coding-level involvement in the project. If you’re not cutting code, it is too easy to become divorced from the effects of your own decision making, and to be seen by other developers as being out of touch with the technical realities of the project.

Mistake #14: Playing The Game Rather Than Focusing On The Target

In some organizations, being a Technical Lead is a politically sensitive position. Technology choices, work assignments and project outcomes are all just tools to be used in the pursuit of personal agendas. To some, this “game” of political influence is both fascinating and addictive. They play it in the hope of gaining some advantage for themselves, and do so to the detriment of the project and the individuals upon to Machiavellian maneuverings than to the technical difficulties of the project, then the project inevitably suffers.

Mistake #15: Avoiding Conflict

Many people find interpersonal conflict distasteful. Some dislike it so much that they will do practically anything to avoid it, including giving up in technical disputes. Such people are prone to being walked over by those more aggressive and forthright.

This is bad enough for the individual, but worse if that person is meant to be representing the best interests of a team. A meek Technical Lead can be a real liability to a development team, who will find themselves buffeted about by external forces that they should have been shielded from, and burdened by demands and goals that are not informed by the project’s reality.

With such a disposition, a Technical Lead may be unable to even deal effectively with unruly behavior or inadequate performance from members of their own team.

Mistake #16: Putting The Project Before The People

It’s one thing to be focused on the project’s goals, but quite another to adopt a “succeed at all costs” attitude. Ambitious Technical Leads, concerned with the image they project to their management, sometimes accept impossible goals or unreasonable demands, because they lack the courage or integrity to say “no.” These goals then become the development team’s burden to shoulder, leading to increased stress, higher defect injection rates, longer working hours and lower morale. There is a tendency to be so focused on the end goal that the effects of the project on the developers gets overlooked. It is not uncommon for successful delivery on a high pressure project to be followed by the resignations of several disgruntled team members, making the project’s triumph a pyrrhic victory indeed.

Given the costs of hiring and training staff, treating developers as expendable resources makes no financial sense, quite aside from the ethical implications of such treatment. A wise Technical Lead will know that putting the well-being of the developers first also produces the best results for the project and the business. Project success should leave the participants satisfied with their achievement, not burnt out and demoralized.

Mistake #17: Expecting Everyone To Think And Act Like You

Being a Technical Lead may be the first time you are exposed so frequently and directly to the problem solving styles and low-level work habits of others. Programming is traditionally an individual activity. Programmers are often able to face the technical difficulties of their work in isolation, emerging sometime later with the completed solution. But as a Technical Lead you will frequently be called on to help those who are stuck part way through the problem-solving process, unable to proceed. Seeing a solution that is “under construction” might be a bit of a shock to you at first, as you may find your colleagues approach to problem solving dramatically different to your own. Some people work “outside in”, others “inside out”, others jump all over the place, some work quickly with lots of trial and error, others slowly and methodically. It is tempting to stand in judgment of approaches and methods that don’t gel for you, pronouncing them somehow inferior. Avoid the temptation. Learn to accept the varieties of cognitive styles on your team, and recognize that this cognitive diversity may actually be an asset, for the variety of perspective it brings.

Mistake #18: Failing To Demonstrate Compassion

Although I’ve put this last, it is in some ways the most important of all the mistakes listed here. Always remember that your team members are people first and programmers second. You can expect them to be temperamental, inconsistent, proud, undisciplined and cynical – perhaps all in the same day. Which is to say they are flawed and imperfect, just like you and everyone else. So cut them some slack. Everyone has good and bad days, strengths and weaknesses; so tolerance is the order of the day.

If someone breaks the build, it’s no big deal. If a regression is introduced, learn something by finding out how it got there, but don’t get upset over it or attempt to assign blame. If a deadline is missed, stand back from the immediate situation and appreciate that in the grand scheme of things, it really doesn’t matter. Mistakes happen and you should expect your colleagues to make many, as you will surely make many yourself.

The Architecture Group 5

An organizational antipattern that I have seen a few times now is the formation of an Architecture Group. Architecture Groups generally have the following purposes:

  • To design the enterprise architecture shared by a group of applications within an organization
  • To review the design of projects to ensure they are consistent with the enterprise architecture
  • To prescribe the standard technologies to be used across projects in the organization

In summary, the Architecture Group is an internal “governing body” and “standards group” rolled into one. Membership of the group tends to be restricted by seniority – the architects and senior technical staff.

In general, the Architecture Groups I’ve witnessed in action have been disastrous. That’s not to say that it need necessarily be so – I have no legitimate basis for generalizing beyond my direct experience – but based on the reasons that I’ve seen these groups fail, I conject that failure is a likely outcome of any such group.

The negative impact of an Architecture Group often originates from the tendency to create an “us and them” mentality amongst staff. Because the group makes technology and design decisions which are then imposed upon other projects, those working on individual projects come to resent the architecture group for the constraints they have placed upon the project. Working at the overview level, as an architecture group does, it is difficult or impossible to keep track of the low level details of a variety of projects. And yet the details of those projects are key determinants of the suitability of the technologies and designs that the architecture group deals with. Project staff come to view the architecture group as dwelling in an ivory tower, from where they can afford to overlook the troublesome aspects of the projects in their influence.

Members of the architecture group can begin to share this view. They consider their decision making more objective and sensible precisely because it is not influenced by the low level concerns of individual projects. Once high level consideration has occurred, any difficulties encountered while implementing those decisions are dismissed as “implementation details” that are beneath the group’s level of concern.

The major source of trouble with architecture groups seems to be the social dynamic that builds up around them. They have a tendency to become a clique that is in overestimation of its own collective abilities, because it is deprived of any negative feedback concerning the consequences of the decisions it makes. The absence of feedback results in part from the unwillingness of project staff to criticize those senior to them, and in part of the self-imposed isolation of the architecture group, which makes its decisions from behind closed doors.

The issue of seniority is a real stumbling block, because senior staff may have great difficulty in admitting that they have made a poor decision, even when it is perfectly obvious to project staff that this is the case. Any adjustment to the decrees of the architecture group, once made, results in a perceived loss of face which the members of the architecture group can ill afford. Being senior, they are perhaps more cognizant of the political forces at work in the organization. Perhaps they are more ambitious, and therefore reticent to concede wrong doing for fear of the impact it might have on their reputation. Perhaps they view the objections of project staff as a challenge to their authority. In any case, members of the architecture group develop an ego identification with the decisions they make, which leads them to ignore or devalue negative feedback from project staff – leading to the reinforcement of the architecture group’s external image as being isolated from the project community.

Consider also that people working in architectural roles tend to be abstractionist by nature. They are comfortable working at a high level and just trusting that the low level details will work themselves out. When project staff object that a decision made in the abstract has resulted in concrete difficulties at the implementation level, the abstractionist is prone to characterizing the situation as one of a well conceived plan that has been fumbled in the execution. In other words, they shoot the messenger, preferring to blame the implementation of their decision rather than the decision itself, which is perfect – as long as it is only considered in the abstract.

Conclusion

Those who institute an architecture group in their organization may be courting disaster. There is a strong tendency for the group to become cliquish, divorced from the consequences of its decision making, and the object of wide-spread resentment within the organization. Coordination of projects and adherence to enterprise architectures should occur in a way that does not impinge upon individual project’s chances of success, nor rob them of the ability to solve the particular problems of their project in an effective way.

The Mismeasure of Man 6

Software developers are drawn to metrics for a variety of reasons. Generally, their motivations are good. They want to find out something meaningful about the way their project is progressing or the way they are doing their job. Managers are also drawn to metrication for a variety of reasons, but their motives are not necessarily honorable. Some managers view metrics as an instrument for getting more work out of their team and detecting if they are slacking off.

Performance metrics – metrics intended to quantify individual or group performance – can be useful if they are employed sensibly and in full awareness of their limitations. Unfortunately, it is very common for performance metrics to be gathered and interpreted in ways that are ultimately harmful to a project and its developers. Many is the metrics program that, through inept implementation and application, has engendered anger and resentment amongst those it was intended to benefit.

Below, we consider various performance metrics commonly encountered in development environments, the ways they are abused, and illustrate their misuse with some examples taken from my own experience and the experience of others as they have related it to me.

The Number Of The Counting

Face Time

This is perhaps the most commonly abused “metric” in the software development world. For reasons of both tradition and convenience, many managers and developers alike persist in considering the number of hours spent in front of the screen as being some indication of how devoted a programmer is to their work. Those that work long hours are considered “hard workers,” those that keep regular hours are considered “clock watchers.”

The fault behind such thinking is the assumption that software development is a manufacturing-like process, rather than a problem-solving process. If a worker on a production line works an extra hour then the result is an extra hours’ worth of stuff. If they work an extra three hours then the result is an extra three hours worth of stuff; which will be exactly three times the quantity of extra stuff they would’ve produced had they only worked a single extra hour. If their role on the production line is menial assembly work, then the quality of the stuff they produce in their third hour of overtime will be the same as the quality of the work from their first hour of overtime. In such an environment, it is reasonable to see productivity as a direct function of time on the job.

But software development is nothing like this mechanistic process. It is a complex, intellectual effort conducted by knowledge workers, not a menial assembly task performed by laborers. So more hours spent in front of the screen does not necessarily equate to more progress. For example, long work hours might be a result of problems such as:

  • Relying on trial and error rather than thinking ahead
  • Goofing off surfing the web or socializing
  • Solving the wrong problem, and having to start again
  • Gold-plating (extending scope beyond what is required, simply for the satisfaction of it)
  • Using a lengthy, inefficient algorithm rather than a smaller, elegant one
  • Writing functionality that should have been purchased in a third party library
  • Making the solution more generic than is necessary
  • Poor understanding of the technologies employed, resulting in a lot of thrashing
  • Losing a lot of time to debugging, because of the higher defect injection rates that occur when working while fatigued
  • Overly ambitious scheduling resulting from poor self-insight and lack of experience

So by expecting or encouraging long working hours, we may simply be rewarding poor performance and inefficient work practices.

I first encountered the obsession with working hours at a small “dot com” company I once had the misfortune to work for. Full of bright and enthusiastic young people, the CTO of this company considered his stable of go-getters a resource to be exploited to the fullest. Not being the most technically aware of CTOs he was unable to assess the performance of the technical staff that reported to him in any meaningful way, so he was forced to rely on what he considered to be secondary indicators of performance – the number of weekly hours each employee logged in their electronic time-sheet.

Those with more experience of his somewhat indirect approach to assessment were quite generous when it came to such time-keeping tasks, logging some spectacular hours – some of which they actually worked. Those unfamiliar with the man’s chronological obsession, such as myself, made the mistake of working efficiently and recording their work hours accurately. This did not go down so well.

In my letter of resignation I cited unscrupulous and irrational management practice as one of the principal reasons I was leaving. On my last day at said company I received what is, to date, the only written response to a resignation that I have ever encountered. The response contained a month-by-month tabulation of average daily working hours – both the company average and my personal figures. Of course, my “performance metric” was disgustingly normal, whereas the company averages seemed to indicate that many staff were dedicating all their waking hours to work. The conclusion was obvious – I was not putting in the sort of effort that was expected of me. How right they were.

Lines Of Code

It should be common knowledge that lines of code (LOC) and non-comment lines of code (NLOC) are not measures of size, productivity, complexity or anything else particularly meaningful. It is none-the-less very common to find them being used in the field to quantify exactly these characteristics. This is probably because these metrics are so easily gathered and there is an intuitive appeal to equating the amount of code written with the amount of progress being made.

But it is a big mistake to consider large quantities of code necessarily a good thing, for large volumes of code may also be symptomatic of problematic development practices such as:

  • Unnecessarily complex or generic design
  • Cut-and-paste reuse
  • Duplication of functionality

Large quantities of code can also bring such problems as:

  • A greater opportunity for bugs
  • A greater maintenance burden
  • A greater testing effort
  • Poor performance

So by rewarding those who produce larger quantities of code, we may simply be encouraging the production of a burdensome code base.

The story is told of a team of developers whose well-meaning but uninformed manager decided that he would start measuring their individual contributions to the code base by counting the number of lines of code each of them wrote per week. Fancying himself as more technically informed than most other middle managers, he wrote a simple script to count the number of lines of code in a file.

The project was written in C. Figuring that most statements in C ended in a semicolon, he presumed that his script could just count the number of semicolons in the file and that would give him the number of C statements. He congratulated himself on thinking of this clever counting method, which would not be susceptible to differences in coding style between developers, nor any of the techniques developers sometimes employed to try and manipulate metrics in their favor by changing the layout of their code.

However a few of the developers got wind of the technique their manager was using, and started writing function comments containing long rows of semicolons to delineate the beginning and end of the comment block.

Their measured rate of code production skyrocketed … so much so that their manager became suspicious and, looking at the code to manually verify that his script was working correctly, discovered what was going on. But the developers simply claimed that their recent change in comment style was just an innocent search for greater code readability The manager could not prove otherwise.

Function Points

In some circles, Function Points (FPs) have currency as a way of measuring the size of a piece of software. There are complex counting procedures that enable functionality to be expressed as a number of FPs in an ostensibly language-independent way. The formation of the IFPUG (International Function Point Users Group) and the amount of semi-academic study they have received has invested FPs with a certain amount of faux credibility. However, this credibility is undeserved, as FPs are a fundamentally flawed metric. They are not a valid unit of measurement, nor can they validly be manipulated mathematically. Any metric involving them is approximately meaningless. FPs have been discussed at length in a previous article7.

Screens

Having worked principally in the area of rich-client and desktop applications, I’ve witnessed numerous mismeasures of progress from this domain. The most foolish of them was to use a “screen” (dialog / window) as a unit of measurement. Thus, if programmer A implemented two dialogs in the time programmer B implemented one, A was considered to be twice as productive as B.

The faults with such an approach are alarmingly obvious, but often ignored by an unthinking management that is too impressed by the fact that they can attach numbers to something, which creates a false impression that they are measuring something. Such are the perils of metrication in the hands of the ignorant.

To labor the obvious, here are a few reasons one programmer might produce more “screens” than another, that have nothing to do with productivity:

  • Their screens were simpler in appearance and/or behavior.
  • Their screens were sufficiently similar in appearance and/or behavior, so there could be code re-use between them.
  • Their screens could be constructed with standard GUI components, without the need for custom components being developed.
  • Their screens were not the end result of a usability-based design process, but were whatever was most programmatically expedient.

By counting “screens” as a measure of progress, we encourage programmers to race through their tasks, giving short shrift to issues of usability and reuse.

I once worked for a small firm in the finance industry. Their flagship product was a client/server application for managing investment portfolios. I was brought in, together with another GUI guy, to extend the functionality of the system and clean up a few of the existing screens and dialogs. Under the hood, this product was a disaster. Poorly coded, undocumented and architecturally inconsistent, it was the end result of the half-hearted, piece-meal hacking of many previous generations of contractors.

The gentleman who had shepherded all these contractors through the company doors, and who considered himself both Technical Lead and Project Manager, was not heavily into software. Indeed, he never actually bothered to look at the application’s code. He had only one way to gauge individual or collective progress and that was on the basis of appearance. If a piece of work involved lots happening on the screen, then he figured that it represented a lot of work. If it wasn’t visually significant, then he figured there probably wasn’t much to it. Let’s call him Senior Idiot.

He and I did not get on so well, right from the start. I’m told I don’t suffer fools lightly and as fools go, this guy was an exceptional specimen. My fellow GUI guy was no better. Examining the code that he wrote and the work he delivered, it was clear he was working at a level consistent with the noxious quality of the existing code base. Let’s call him Junior Idiot.

A few months after I started, Big Idiot took me aside and asked why my progress was “so slow.” I thought this was an interesting comment, given that by my own analysis I was generating good quality code at a rate several times the industry average. Both the code and the resulting interfaces were some of the best they had in the entire, sorry product. When I enquired how he had determined my progress was “slow” given that he never actually looked at code, he explained that he was comparing the “number of screens” Little Idiot had managed to grunt out, to what I had developed in the same time. Little Idiot was some way in front.

He was correct. Little Idiot had produced several rather large screens (large in the sense that they occupied many pixels, not in the sense that they represented a lot of functionality). They were usability disasters, every one of them, and the product of some pretty deft cut-and-paste but, scatological in quality as they were, they were there to be seen.

After some chuckling, I tried to carefully explain to him the “discrepancy” that he saw was because Little Idiot was spitting out rubbish as quickly as possible, and I was taking some time to do a decent job. Additionally, Little Idiot was producing non-reusable code , whereas I was writing general purpose code, reuse of which would mean that future work, both my own and others, would progress much more quickly than Little Idiot could ever do. He was not convinced and my time at this little company came to an end shortly thereafter, much to our mutual relief.

Iterations

Unbelievable as it is, I can honestly say that I’ve seen entire projects compared on the basis of what iteration they are up to in their respective schedules. Suppose projects A and B both employ an iterative methodology. A is in the third of five planned iterations, B is in the fourth of seven planned iterations. Some observers may then conclude that project A is behind project B because “three” is less than “four.” Others might conclude that project A is ahead of project B because it has completed 60% of its iterations and B only 57%.

I recall the organization in which I first encountered this. A rather hubristic, research oriented environment in which some very clever people worked. Sadly, the quality of the management was not on a par with the quality of the technical staff. As they say, “A fish rots from the head down,” so it was no surprise that the manager at the top was not as clued up in many areas as one might like.

At this time, “data warehousing”, “knowledge management”, “project cross-fertilization” and “knowledge repositories” were the buzzwords that substituted for critical thought. Mashing all these concepts together in his head, the top guy decided to establish a “project wall” in the office, upon which the project managers were required to post the Gantt charts for their respective projects, and keep them up to date. This strategy was meant to promote some sort of comparison and knowledge sharing between projects, although exactly how this was to be done meaningfully was never quite made clear. The device became widely known as “The Wall Of Shame”, as that was its obvious but unstated purpose – to publicly shame those managers whose projects were running behind schedule. Presumably, the potential for embarrassment was meant to encourage individual project’s to maintain schedule.

It came as a surprise to no-one but the man who instituted the scheme, that it had precisely no effect on anything, except to become the focus of widespread derision.

Tasks / Bugs

Many software development teams allocate work to individuals on a per-task basis. Typically, these tasks are tracked in some electronic form – perhaps as bugs in a bug tracking system or tickets in a trouble ticket system. XP projects like to track tasks on pieces of card because the arts-and-crafts association creates the illusion of simplicity (an illusion which disappears when reports of any kind are required, or when the first strong breeze comes along).

Regardless of the mechanism used, “the task” is so useful as a unit of work allocation that it is very tempting and convenient to think of it as a unit of measurement. Of course, it is not a unit of measurement, as no two tasks are the same. A tiny, one-line bug fix might be captured as one task, as might the implementation of an entire subsystem. The granularity is ever-varying, making any mathematical comparison of task counts meaningless.

But convenience outweighs reason and so one frequently finds, particularly amongst the ranks of management, the tendency to equate high rates of task completion with high productivity and effort, and lower rates with lower productivity and effort. The mistake is so common that developers become quite practiced at gaming the system to make themselves look good. Common image enhancement techniques include:

  • Breaking work down into unusually small tasks, thereby enabling a greater number of tasks to be completed at a faster rate.
  • Registering tasks as completed before they have been properly tested. This enables bugs to be readily found in the work, each of which will be considered a separate task. These tasks can be completed relatively quickly because the programmer is familiar with the code at fault, having just written it.
  • Registering tasks multiple times, describing it in slightly different ways each time. Once completed, all the tasks are closed, with all but one marked as duplicates. If the management forgets to exclude duplicate tasks from their reporting, the programmer’s rate of task completion is artificially inflated. He might also “forget” to mark some of the duplicate tasks as being duplicates, to further enhance the effect.
  • When a task is found to be more involved than originally thought, rather than revise the scope of the existing task, new tasks are spawned to capture the unanticipated work. Their eventual completion will mean that the number of “completed” tasks registered against the programmer’s name is greater.
  • When selecting work to do, programmers gravitate towards the short tasks which can be easily dispensed with, enabling them to quickly get runs on the board.

When invalid metrics are gathered, the result is often to contort the team member’s work practice so as to create the best perceived performance, regardless of what their actual performance might be.

A colleague once related to me the story of two teams of developers in a multinational company who reported to the same manager. One team contained three developers working mainly on maintenance tasks, documentation and bug fixing. The other, containing six developers, worked on per-client product customizations. Both happened to use a common issue tracking system.

A developer from the smaller team complained to the manager about the discrepancy in work loads between the two teams. He felt that his own team was dreadfully overburdened while the larger one just seemed to be taking it easy. Although uncertain that the developer’s complaint was valid, the manager felt compelled to “handle” the situation in a managerial kind of way. Turning to the issue tracking system he did a few simple queries and discovered that the small team was closing issues at nearly twice the rate of the larger team. This struck him as confirmation of the developer’s complaint. After all, a team twice as large should be getting through issues much faster than a team half its size.

So the manager sent an e-mail to all members of both teams, and CC’d the general manager. In this e-mail he highlighted the discrepancy in issue closure rate for the two teams, chastised the larger team for slacking off and praised the smaller team for their hard work.

The original complainant was suitably appeased, but the other members of his team, along with the entirety of the larger team, were not quite so happy. The following day, the leader of the larger team came to the managers office and explained to him, in a tone of barely suppressed hostility, that the two teams worked on completely different sized issues, and so comparing issue closure rates across the two was quite meaningless. The smaller team addressed issues that could generally be resolved in a single day, two days at the most, and so naturally they got through them at a fairly rapid pace. His team, the larger one, addressed implementation issues that might legitimately involve weeks of effort, including design, requirements gathering and testing. He was more than a little offended that his hard working team was being reprimanded on such an irrational basis.

The manager admitted his error – but of course, never apologized to those he had offended.

Version Control Operations

Astonishing as it may seem, some developers like to commit changes to their version control system frequently to create the impression that they are hard at work. This only works if you are managed by the technically incompetent. In other words, it works more frequently than you would like.

Requirements Completed

Regardless of whether you capture your requirements in tabular, use case or story card format, individual requirements make spectacularly bad units of measurement.

Consider the enormous variation in scope that can exist between one requirement and another. “The user shall not be able to enter an age greater than 120 or less than 0” counts as “one requirement”; so does “The system shall reserve the section of track for the given vehicle in accordance with safe-working procedure SP-105A.” But the latter is probably a far greater undertaking than the former, and we would expect it to take significantly more time and effort to complete. Pity the developer who is assigned the task of satisfying this requirement, only to have his labors viewed as an achievement “equal” to that of his colleague who was assigned the simpler age-related requirement.

Noise Generated

Some programmers just get the job done. Others seem to find it necessary to let others know that they are getting the job done. You’ve probably met the type before. Every little obstacle and difficulty they encounter seems to be a major drama to them – almost a theatric opportunity. These are the same programmers who will work overtime to fix problems of their own creation, then seek credit for the extra hours they’ve put in. Although there is no number associated with their vociferations, they effectively multiply the amount of perceived work they are doing, and inflate the perceived effort they are making by drawing attention to their actions.

I once worked with such a programmer. He was a hacker of the first order; and I use the word “hacker” in the pejorative sense. Each day over the lunch room table he would regale us with stories of his mighty development efforts, the technical heights to which he had scaled, and the complex obstacles he had overcome – all of these adventures apparently having happened since the previous day’s story-telling episode. But when you actually looked in the source code for evidence of these mighty exploits, you would find only an amateurish and confused mess, and be left wondering how so much difficulty could have been encountered in the achievement of such modest results.

Pages Of Documentation

Used intelligently, documentation makes a useful component of the development process. But when seen as an end in itself, documentation becomes a time-consuming ritual for comforting self-serving administration. Strange then that we should so frequently see, most often in heavily bureaucratic environments, people striving to generate technical specifications that are as voluminous as possible, apparently fearing that brevity will be interpreted as evidence of laziness. A page fails to measure either effort or progress for all the same reasons that “Lines of Code” fails. Stylistic variations mean there is little relationship between volume of text and effective communication as there is between volume of code and functionality.

Conclusion

In the above you will have noticed the same problems occurring again and again. All these scenarios reflect a poor understanding of the basics of measurement theory, together with a willingness to rationalize a metric’s invalidity because of the ease with which it can be collected.

Essentially, a valid unit of measurement is a way of consistently dividing some real world quantity into a linear scale. In other words, X is a valid unit of measurement if X is half as much of something real as 2X is, one third as much of something real as 3X, and so on. For this to be true, all instances of X must be the same. For example, the “meter” is a valid unit of measurement because 2 meters is twice the linear distance of 1 meter, and all instances of the “meter” are the same. The “1 meter” that exists between the 0 and “1 meter” marks on your tape measure is the same quantity of something real as the “1 meter” between the “4 meters” and “5 meters” marks. Compare this to an invalid metric like a “task.” A task doesn’t divide any real world quantity into equal portions. In particular, it doesn’t divide effort or work into equal portions, because different tasks might require different amounts of work to complete. So “2 tasks” is not twice “1 task” in any meaningful sense. Put more simply, when comparing tasks, you’re not comparing like with like.

The attraction to metrics, even false ones, perhaps stems from the false sense of control they offer. Once we pin a number on something, we feel that we know something about it, that we can manipulate it mathematically, and that we can make comparisons with it. But these statements are only true for valid metrics. For false metrics like bugs, tasks, function points, pages, lines of code, iterations etc., we create only the illusion of knowledge. The illusion may be comforting, particularly to those of an analytical bent, but it is also an invitation to misinterpretation and false conclusions.

We might try and rationalize these invalid metrics, figuring that they may not be perfect, but they are “close enough” to still have some significance. But really this is just wishful thinking. You might think, “our tasks may not be exactly the same, but they’re close enough in scope that ‘tasks completed’ still means something.” Really? What evidence do you have that these tasks are of approximately equal scope? If you’re honest with yourself, you’ll find you’ve got nothing more than gut feel to justify that statement. Yet the very reason we use metrics is to obtain greater surety than that provided by gut feel. So we see we are really just trying to convince ourselves that our own guesswork can be somehow made better by hiding it behind a number – borrowing the credibility often associated with quantification.

Metrics are a tool easily abused. A common cause of mismeasurement is their punitive application with the intent of motivating higher productivity. In their zeal to find some way to meet a deadline, managers sometimes sacrifice reason for expediency, hoping that some hastily contrived metric can be used to convince someone that they need to be working harder. Of course, such tactics frequently backfire, resulting only in developers feeling resentful of such numeric bullying.

Meeting Driven Development 8

The software development arena is the land of the perpetual “me too.” Populated by an eager community of “joiners,” every band wagon that comes along is soon laden down by a collection of hype merchants who, recognizing the next big thing when they see it, are keen to milk it for all it is worth. Extreme Programming – that marketing campaign in search of a product – was a particularly fruitful source of commercial spin-offs. When Extreme Testing, Extreme Database Design, Extreme Debugging and Extreme Project Management had run their course; when XP’s agile prequel had fostered a small industry based on old saws spruced up with a few neologisms; those looking to make a name for themselves turned to another member of the XP franchise – Test Driven Development – for entrepreneurial inspiration.

TDD: The Progenitor Of MDD

If you have not read Kent Beck’s insufferable tome “Test Driven Development,”9 let me spare you the time and insult by presenting the expurgated version here:

Hello boys and girls. Once upon a time there was a thing called Test Driven Development – it looked for all the world like an impoverished rendering of Design by Contract10 only much cooler.

The ditto brigade latched onto TDD and got to work. We soon had, sprouting like weeds from between the pavement stones, “Blah Driven Development”, for all conceivable values of Blah. It became de rigueur to have something driven by something else. Not since Djikstra’s “Goto Statement Considered Harmful” had there been such a rash of imitation.

The appeal of such development models is in the simplistic and unrealistic view that a complex activity can be reduced to consideration of, or focus upon, a single factor. But software development is an inherently multivariate process requiring intelligent compromise between competing forces. Unfortunately, such a view is hard to sell.

The fantasy is more appealing … focus on blah, make it the basis of your development effort, and the rest will fall into place as a natural consequence. If you can convince yourself that blah is analogous to a set of requirements or an abstract model then you can also dispense with the unpleasantness of requirements elicitation and design. With sufficiently zealous adherence to BlahDD, combined with a healthy dose of metaphor and supposition, the formerly complex and uncertain undertaking of developing a piece of software turns into the routine application of a silver bullet. Or so some would have you believe.

Such “one stop” philosophies are a recipe for disappointment, but will no doubt continue to sell well, for the same reasons that “get rich quick” and “lose weight fast” schemes do – the promise of an easy fix.

To show how it’s done and perhaps make an obtuse point or two, let’s look at the latest blah to exhibit in the software development road show – Meeting Driven Development.

An Introduction To MDD

MDD is more than an approach to software development, it is a cultural force. If you’re lucky, you are already working in an environment conducive to the meeting mindset. In some corporate cultures meetings are so endemic that they have become an integral part of the corporate identity. For example, an IBM insider tells me that most staff consider IBM to stand for “I’ve Been to Meetings”.

If your corporate culture is not so amenable to MDD, do not despair. You can surreptitiously introduce it into your project without much effort and when others see how successful you have been, it will quickly spread through the rest of your organization like a virus.

I suggest you begin by creating a localized “meeting zone” in your project area. Put a table and some chairs right in the middle of your project’s work area, so that project staff need only turn their chairs around and wheel them a short distance in order to assume the meeting position. You will enjoy the disgruntled mutterings of nearby programmers as they struggle to concentrate amidst the noise such meetings create.

The only practical skill MDD entails is the ability to recognize and achieve meeting mode. Meeting mode is the colloquial name for what is more properly known as corporate catatonia – the mental state achieved by those meeting attendees who cannot or will not participate, instead turning their attention inward. MDD veterans describe the state as being peaceful, meditative and excruciatingly dull. Some claim to have undergone “Out of Body Corporate” experiences while in deep states of meeting mode, during which they separate from their physical bodies, leave the meeting room and go on annual leave.

External indications that an MDD practitioner is in meeting mode include:

  • Vacant staring into the middle distance.
  • Methodical doodling upon note paper.
  • Slowing or cessation of respiration.
  • Extended periods of silence.

Types Of Meetings

In MDD, we encourage the use of meetings at every opportunity and for every purpose. Our motto is “Every Meeting Is a Good Meeting”. While you can hold a meeting for almost any purpose that comes to mind, there are certain types of meetings that tend to feature commonly in software development environments. It is important that you develop some facility with each of them.

Type #1: The Morning Stand-Up Meeting

You should begin the day with a team meeting, and in this respect MDD is in agreement with XP’s practice of holding daily “stand-up” meetings. Like many meetings that are driven by the calendar rather than by a need, your morning meeting will probably devolve into a pointless ritual that serves only to give the organizer a sense of control and influence. For those desperately trying to fulfill a management or leadership role, but lacking the basic proclivities that such roles demand, these ritualistic meetings can also help sustain their delusions of competence, as holding and attending meetings seems like a very managerial thing to do.

Type #2: The Requirements Meeting

A typical requirements meeting involves some technical staff and stakeholders sitting down to discuss the functional requirements for a unit of work. If there are any questions concerning requirements previously elicited, they are tabled here. It is a chance for potential users to lobby technical staff and their managers for the inclusion of their favorite features. However, developers and domain specialists speak different languages, have different priorities and widely disparate agendas. The developers want to cut scope down to the minimum that will be functionally adequate so they will have some chance of meeting the schedules imposed upon them; potential users want an application that will make their working lives as easy as possible.

The tension between these two forces inevitably brings an adversarial dynamic to requirements meetings that can be very entertaining. Domain experts can take the opportunity to express their resentment at the developer’s intrusion into their domain and to laugh at the folly of the developer’s attempts to capture the expertise and judgment acquired in a lifetime’s professional endeavor in a few minutes of discussion. In turn, developers can mock the stakeholders for their lack of technical knowledge, their inability to express their know-how in a succinct and consistent manner, and to proclaim requests for even simple functionality as being impossible to implement for technical reasons that would take too long to go into.

Type #3: The Technical Meeting

MDD prescribes that all technical problems be solved “by committee”. The basic method is:

  1. Select a group of techies having maximum variation in technical opinion and preferences.
  2. Put said techies together in a meeting room.
  3. Direct them to reach consensus on the “best” solution to the technical problem.
  4. Observe resultant fireworks and carnage.

MDD practitioners are not afraid to thrash out all technical issues amongst themselves, comparing the merits of varying approaches in an unstructured session of verbal sparring. As with many meeting-based outcomes, the determining factor is the relative rhetorical skill or obstinacy of the protagonists. Victory goes to whoever can best “ad lib” an argument to support their proposition, rather than whoever actually proposes the best solution.

Of course, there may not even be a “best” solution to the problem. It’s likely there will only be a set of alternatives having different strengths and weakness. You’ll find that if you let the fighting go on for long enough, eventually a compromise emerges that nobody is happy with, but which they will settle for simply for the sake of having the issue done with and getting out of the tense meeting room. This is how MDD forces issues to resolution – by escalating tension until it becomes unbearable.

From a technical lead’s perspective, the MDD approach to design is also an excellent way to disguise your own incompetence. If you’re in over your head in some technical arena, delegating all decisions to a meeting enables you to hide your lack of understanding and appear egalitarian at the same time. When the resulting design is implemented and found to be inadequate, the blame is spread amongst all the meeting participants rather than being focused upon yourself. It’s a win-win situation for you.

The real magic of meetings is that they are like mini-corporations. Just as shareholders enjoy limited liability for the failure and misdeeds of the corporation, meeting participants enjoy a limited liability for the mistaken outcomes of the meeting. The meeting becomes an artificial entity unto itself; an additional, synthetic developer who is always willing to take the blame when something goes wrong.

Type#4: The Progress Meeting

Progress meetings are at once the most uneventful and easiest to institute type of meeting. Their ostensible purpose is for team members to gather together and somehow collectively “update” their mutual awareness of the state of the project. Their real purposes are both symbolic and exculpatory. They provide an opportunity for the meeting organizer to give themselves the impression of active involvement with a project (even though they may see little of the team or its work at any other time), and also provide a way for the “hands off” manager to find out what is going on with their own project.

The most ineffective types of progress meetings are structured like this:

  1. A chairman, usually the person who convened the meeting, reads through the action items from the previous progress meeting.
  2. The assignee of each action item offers some excuse as to why they haven’t attended to it, and then makes some vague resolution to do it before the next progress meeting.
  3. The chairman reads out any new agenda items.
  4. Each new agenda item is turned into a new action item and assigned to one of the meeting attendants, who promptly forgets about it.
  5. The meeting is dismissed and the chairman writes up the minutes of the meeting and distributes them to the participants, who ignore them.

For most of the meeting then, there is only oneway communication from a speaker to a group of disinterested listeners. The same effect could be achieved through judicious use of a text-to-speech engine and Valium.

But there is great power hidden behind this apparently meaningless ritual. The chairman, in later distributing the minutes of the meeting, is in a position to engage in some historical revisionism. The minutes are supposed to detail the activities of the meeting and the decisions reached. But the one writing the minutes can generally write anything that they want, safe in the knowledge that hardly anyone will actually bother to read them. So if a decision doesn’t go your way in the meeting, just change the way it is recorded in the minutes. You can even introduce items that were never discussed in the meeting, together with your preferred outcomes, safe in the knowledge that any participant who reads such an item but can’t remember it from the meeting will probably conclude that they must have fallen asleep or been otherwise distracted during that part of the proceedings. Their unwillingness to admit their inattention means that your fabricated version of events will go unchallenged. The minutes are also invaluable for assigning blame when trouble occurs, as they can be used to substantiate claims that a particular resolution was arrived at with the agreement of all parties present (remembering that many will choose not to say anything at these meetings, lest they end up with work assigned to them, But their silence will forever condemn them to having offered implicit support for any decision you chose to put into the minutes).

Should the more rational members of the gathering ever object that these progress meetings seem pointless, you can always justify them by pointing out that they are an opportunity for communication to occur, and that communication is good. The complainant will be hard pressed to argue that communication is bad, and your point is won.

Type #5: Review Meetings

Technical artifacts should always be reviewed by a group, for the practice offers numerous advantages … to the reviewers, not the author of the work being reviewed. Reviews are a good opportunity to gang up on your enemies and humiliate them in front of an audience. Developers have a notoriously strong ego investment in their work, so tearing apart the finely tuned code they have been poring over for weeks is sure to provoke an interesting reaction. This is the principle goal of group code reviews. The reviewers function like a self-appointed council of inquisitors looking for evidence of witchcraft in the accused. And like a witchcraft trial, incriminating evidence can always be found, as few developers can write code or produce a design that cannot be criticized in some way for something. Review meetings also allow individuals to find fault with impunity, as any degree of pettiness or vindictiveness they might exhibit can be excused as a diligent attempt to make constructive criticism.

Once you can conduct all of the above types of meetings, and enter meeting mode at will, you may consider yourself a competent MDD practitioner.

Conclusion

So that’s a brief overview of the magic that is Meeting Driven Development. This approach to software development has been around since the beginning of corporate activity in the programming arena. In many corporations, the developmental norm is indistinguishable from MDD. Meetings are so much a part of the corporate culture it would not occur to anyone to take any other approach.

You will find that many programmers are afraid of meetings, having come to view them as pointless, “busy work” activities. This is simply because they have not yet learnt to appreciate that futility is actually a strength of meetings, not a weakness. The ability to convincingly create the illusion of coordinated effort and activity is invaluable in many situations.

Meetings are not a knee-jerk reaction to problem solving as some suggest, but a vehicle for creating a synthetic corporate entity – a virtual member of the development team – that can adopt the responsibility for the participant’s poor decision making and manifest inabilities. Only when they have abandoned their reflexive animosity towards meetings and recognized them for the ritual scapegoat that they are, can developers really appreciate the benefits of MDD.

  1. First published 12 Jul 2003 at http://www.hacknot.info/hacknot/action/showEntry?eid=7 ↩

  2. First published 11 Jun 2006 at http://www.hacknot.info/hacknot/action/showEntry?eid=87 ↩

  3. cited in Becoming A Technical Leader, G. M. Weinberg, Dorset Hourse, 1986 ↩

  4. Facts and Fallacies of Software Engineering, Robert L. Glass, Addison-Wesley, 2003 ↩

  5. First published 29 Mar 2005 at http://www.hacknot.info/hacknot/action/showEntry?eid=73 ↩

  6. First published 6 Aug 2006 at http://www.hacknot.info/hacknot/action/showEntry?eid=88 ↩

  7. See Function Points: Numerology for Software Developers ↩

  8. First published 30 Mar 2006 at http://www.hacknot.info/hacknot/action/showEntry?eid=84 ↩

  9. Test Driven Development, Kent Beck, Addison Wesley, 2003 ↩

  10. Object Oriented Software Construction, 2nd Ed., Ch 11, Bertrand Meyer, Prentice Hall, 1997 ↩