Review the Reviewer

I have always believed that reviews are essential & a waste of time. That's theory & practice competing in reality.

Without reviews, the wheels fall off very quickly - the fear of failure is as likely a driver to success as any other, & being reviewed is one way to instil such a fear. It doesn't matter if we're talking about code reviews or performance reviews, the fact that, at some point, there will be a review is usually enough to cover the period of non-review with a mild sheen of paranoia sufficient to keep the wheels well greased.

That's the theory.

In practice, reviews are badly done by people who don't want to do them, don't understand why they need to be done, & see the 'chore' of the job as the worst kind of punishment known to developer-hood. Again, it doesn't matter if you're reviewing a peer or junior's performance, or looking over their shoulder at the code. Adding a similar driver of being reviewed on how well you review, or how well you perform your job of reviewing, may get back some of that paranoia, but only if the actions taken on those who fail to live up to their responsibilities does not reward them.

The worst reviewers need more practice, not to be let off the hook. They need to be reviewed more closely while reviewing. They need to be embarrassed into being better at it, or taking it more seriously. If this doesn't happen, then the review is definitely a waste of time - not just for the person being reviewed & the reviewer, but also the administrator who correlates this effectively irrelevant data point with the past & future.

Without a review process that reflects on itself, understands its limitations, & works towards fixing itself to gain relevance to all involved & the environment in which they live, the anarchy of not knowing is detrimental to the business.

As each layer of review is added, we climb the CMM staircase towards looking deep into our own navels, admittedly, but that way we see ourselves reflected most accurately in the dim light of dawning awareness.

If we never review, we never discover what we're doing wrong or could do better, we never change, we never progress, we never get job satisfaction. But then, if we don't review, maybe we'll never notice.

Tweet

I've been concentrating on requirements gathering, & discovering that developers generally know nothing about this phase of the project, & are a very poor substitute for a real business analyst or product specialist. In the process, I've looked at software for tracking as well as document templates to ensure that those making the request know just how tricky it all is & how much work is involved - management or sales-folk.

If you don't have the requirement 'right' - by that, I mean enough information to know that you've understood the person making the request as far as possible - then you can't in all good conscience start work on designing a solution. That time would not only be wasted, but give the false impression that things were progressing in the project when it hadn't even started.

Then I read about the infamous No-Brown-M&Ms requirement, http://www.snopes.com/music/artists/vanhalen.asp, & it got me thinking - I should do that. I should ensure that requirements, if they are complex enough to allow, hold an Easter egg, or some such nugget of ludicrousness as a marker to indicate that the document/requirement is actually being read & understood. How else do you achieve this without a canary clause? (For the too-modern, this refers to taking a canary into a coal mine because it will die from the effects of leaking gas far quicker than a human.)

So, paint me yellow & listen to my song.

Seeking Nirvana

I often wonder if Buddhists really would appreciate Nirvana. The end goal, the attainment, is not the point, but its seeking is. The path to heaven is the guiding principle for living this life. Ignoring this life & assuming that heaven awaits goes against everything every religion is based on. No religion I've heard of says "be a vegetable, & good things will come". If you know of one, I'm in the market.

The same goes for software development (not the smoothest segue-way, but there you go). Most software products seek perfection, intending to get to that perfect state where there is no maintenance for the developers, & no cost to sales (that is, the hypothetical product cash cow). This is not realistic. It happens in some products, which then fade away & die over time. Reality is the constant striving, whether we're talking about the product that could reach a wider market if it had one more feature, or the software release that has only one bug in the issue tracker. In either case, the current state should be celebrated. It's a wonderful thing to be able to say that you've nearly reached an ideal. It's unrealistic, & can be deflating, to say that you have reached it. What next?

Product development should live in the now - what has been achieved, & what is being achieved, is measurable. It makes us want to improve the product & ourselves. It gives us something to do, a place to be, people to see, a sense of achievement, & all of those things that define why we're in the industry. We get a buzz from doing. Whether you're an engineer or a salesperson, once you've built or sold, you go back & do it again. If you learn nothing from the process, you get bored & give up.
I am now suggesting that you take delight from every imperfection as well as each partial success - they are the same thing. Both mean that you need to strive more, work harder (or smarter), aim high, dream. Maybe the next release will ship without issues; maybe the next product will be the killer app; maybe the next sale will be the one that propels the company into higher profits.
Maybe, just maybe, we might reach Nirvana, someday.

Product Sense & Dollars

Product Sense is that elusive ownership of product development whereby the dev team not only know what they're doing, they understand it, & they can articulate it. That's heady stuff. More than that, they can tell the story in their own words, not just parrot what the marketing or product person has defined as the 'only way' to represent the product or the company.
Stories are important for agile, mostly because things can change, so the story has to change little by little - not be replaced by a new story. There are interpretations, like any good folk tale, nuances, expressions, that all come together to make a long-lasting piece of culture that is acceptable to all levels of society, if you don't mind my metaphor running away a little there. What marketing sells must reflect what product intended & what the devs are creating. The only way that can happen is if everyone understands the story & can retell it without having to use a dictionary to determine the meaning of a specific word out of context. The story should not be in French if the audience only speaks English. Admittedly, you sometimes have to use bad English as the lowest common denominator, but you have to use a language that everyone gets.

If the team - & now we can talk about the wider team that includes the non-technical - speaks one language, then they can tell that story to others not involved in writing the story. They can all evangelise, they can share in enhancing the story & making it better. This sounds a little Celtic, but if everyone knows the story by heart, then you don't need to resort to writing down as much. If everyone can tell the story, knows the story well enough, then you begin to live & breathe it without thinking about it, without having to go back & check with someone else that you've got the plot right.
This, of course, all saves time & effort. It saves the project from going back to rewrite the story as often, because you tend to get more of the intent early on, even if you don't get all the details. You can even learn to draw more out of the story teller to fill the gaps of what makes a good story. If everyone is used to listening to stories & then retelling them, then they'll know how good each story is, & how easy it will be for them to tell that story, & they will make damn sure that they get the full story as soon as possible.
Nobody wants to waste their time hearing that someone has a story about a walrus, & then a week later being told that it smokes cigars & eats oysters, then a week later that he has a friend who's a carpenter, & then you eventually get to the point of there being a white rabbit & a little blonde girl - but much, much too late.

Tell the story early & often. Rehearse it, find the holes in the plot, listen to others telling the same story. Develop a story culture. Develop a team culture. Develop product sense. Save dollars.

Manifestopheles

Although having a team manifesto is a wonderful thing, it is essentially completely useless if your team happens to be one of the following:

• Too pig-headed to agree to one
• Too individual to follow one
• Too sheepish to need one to bring them into line

I love the basic elements referred to in
http://bobtuse.blogspot.com/2009/05/team-manifesto-craftsmanship-behavior.html
being,

• define (internal) quality
• define behaviour
• define process/procedures
  

If you can't do this, you can't be a team. If you need to do this, then you don't yet have a team. If you have a team working to this, then you don't need a manifesto. The important aspect, though, is the basic need for the team to want, or else see its own need for, such a manifesto. Without that, team-ness is effectively directing drones in concert, simply a manifest of resources & activities.

I would sell my soul for the belief that my team could benefit from having a manifesto.

Only Five Types of Documentation?

Somebody, who, if they are a developer by nature, hasn't done any software engineering theory for quite some time, recently pointed out an article on the five types of software documentation, being
Requirements
Architecture & Design
Technical
User
Marketing

I thought about this for a few seconds, with the usual "But what about ...?" question dangling from my lips. Then I realised the problem - there are possibly five different skill sets in the five types of documentation listed, being
Business Analyst
Software or System Architect, Project Manager, Team Manager
Software Developer, Tester
Technical Writer
Marketer

These people do sometimes talk to each other, but there is no direct link, and very few tools for conveying one set of documents to the next recipient in the chain - because it is a chain! These documents are distinct elements in different parts of the product development life cycle (nothing to do with software). They are produced by different people in different places. They are an outcome of (any) product development. They are not the end goal. In fact, many products are developed without several of these types of documentation (to their detriment, I must say).

Without requirements, a product has no meaning. It's just a thing that is waiting for its application, a useless mass. The old "If you build it, they will come" is meaningless, because they may not be able to find you. Kids who develop war games in their spare time believe that there is a requirement for badly-conceived games, and that gets them well onto the wrong path.

Without architecture & design, a product has greater potential for failure, both in terms of the project being over-budget & late, and the product itself being faulty. Without a plan for how to build the product, the effectiveness of anything built is purely coincidental.
In a professional product development environment, this area is big. It starts with functional requirements, product architecture roadmaps, product roadmaps, project management, and budgeting, and goes on to high level solution design, low level design, software design (in this case), development guidelines, processes, test plans, ... The list goes on. This is planning. It's what people do badly in product development. It takes many people with different skills.

Without technical documentation, a product is almost useless, and can quickly be forgotten. There is no potential for maintenance if all of the design decisions are in the head of one person, or else they live their lives vicariously through the extended utility of their one product. If anything goes wrong, there's no easy way to determine how to fix it, why things were developed the way they were, etc.
I'll also throw testing into this basket - test implementation & results, without whom we have nothing worth releasing into the wide world.

User documentation means that someone can figure out how to use the product. Without it, no-one will. Without being able to understand the documentation, no-one will use the product. And yet, we continue to leave this up to the product developers to create. This step requires professionals.
Without users, there is no need for support, or for issue resolution libraries.

Similarly, marketing documents should not be created by product people or over-zealous executives who think they know better, but by professionals who know how to portray products in the market place. It's not a matter of portraying the product so much as creating the portrayal. Without marketing, a product will never be 'discovered'.

I won't quote the article, because it was so generic that it's hardly worth blowing out of the water. If it was written from a software developer's perspective, then it failed to understand the small part that a developer plays. If it was written from any other perspective, then it failed to understand the small part that a developer plays.
Let's rephrase the five levels of product development:
Need Discovery
Planning
Implementation
Maintenance & Support
Marketing & Sales

Document that.

Step Away from the Keyboard!

I cannot stress enough the importance of not writing code. Relatively speaking, writing the code is a very small part of implementing a solution to any problem, whether it's new product, adding functionality, or debugging.

The first step is always understanding the problem. In the case of new work, that means understanding the requirement, and understanding the person who proposed the new functionality, the client, or other recipient of the finished product. If you don't do that, then there's no point going into ecstasies of UML in describing a solution. It's wasted effort.
Good requirements lead to test first development, which means writing (which may look like coding, but really isn't) good tests to fail, and getting those right such that they cover the solution space.
Then you can think about designing the code solution that will satisfy those requirements and fit into the overall architecture, following design rules, coding standards, etc. This must be documented. If you can't write about it, then it's not worth implementing. Just the act of writing, or discussing it with someone else, usually opens up new vistas of thinking about the problem.
Now you can code it (and improve the tests).
Testing of that solution has to take some time, too - and it's not a hit-and-miss process of running the debugger to step through each line, make changes, start again. Each time something goes wrong, go back & work out where it went wrong - in the design of the solution, the overall architecture, the understanding of the requirements, ...

Maintenance is the same, except that you have a different start point - the problem is that a requirement is not being fulfilled; tests are not correct (they hadn't found the problem). Therefore, the code is wrong.
Caught you! The code isn't wrong yet. The requirements were not understood, the architecture was inappropriate, the design was incorrect, the documentation is not sufficient. The implementation is again a minor detail.

I'm sure I mentioned coding in there somewhere. It was a small thing. Anyone can code, with the right training. It takes experience, skill, & intelligence to produce solutions to problems.
Software developers - the craftsmen, the artists, the engineers of the industry, happen to be able to code. It is not necessarily their job.
Developers should be able to ask questions, discuss, argue (in the Greek sense, not street sense), draw, write (whole sentences & paragraphs), think, and love their work.
Anything less is a drone.

Scribo Ergo Sum

Unfortunately, this doesn't really have the same dual meaning as in English. "I write" can imply both the written word (or typed), & the process of developing software (which some developers never use anything but the keyboard for - a mouse being a mere distraction).
But this is not related to what I'm here to discuss, except obliquely.

Developers develop software. They tend to believe that that is their raison d'être (Latin, & now French - how posh!). This has something to do with the fact that, "The moving finger writes, and having writ ..." (Arabic, no less - albeit translated) gives ownership of the creation to the fingers. Fundamentally, if you didn't write it, you don't own it. This gives rise to the old NDH label (not developed here) to indicate something to be spat upon as unworthy of gracing a developer's concerns just because they didn't write it.

This is all, of course, a load of cobblers.

Developers who do no more than write software are process workers. They are told how to put things together, are provided with the materials, & never have to think for themselves. Such drones are useless. They no more own their output than a factory worker owns the fluffy toy for which they sewed on an arm, or a labourer owns a bridge on which they rivetted.
The ownership of the toy goes to the designer. The owner of the bridge is the architect or engineer who conceived or oversaw it. The owner of software is not the one with the fast fingers, but the one who understood the customer requirements & drew the pictures & wrote the specs that described the solution. Everyone else is merely a contributor.

This leads me to latter phases of software development. All developers hate maintenance, mostly because it is soul destroying to see a piece of software that was once designed & developed well for one purpose be systematically 'improved' for new customers (bespoke work) or mangled for new industry requirements (bloatware). Good developers know that this is bad. However, maintenance is an essential part of the life cycle of software, & cannot, in itself, be considered beneath the concern of the professional.
What is missing is a sense of ownership. How can you own the product being shipped if it has had a history of owners who have developed little add-ons to someone else's design from the mists of time?

Own the problem. Own the solution. Own your work. Be proud of what you can achieve, given the trying circumstances. Make your work important. It's all up to the developer.
Sure, this may also be a part of the project management process, ensuring that there is something worth owning, & that the developer is not treated like a drone fulfilling a silly requirement in a mindless manner.
Engage. Be engaged.

Peter FitzSimons tells a story that I believe he attributes to Alan Jones about the difference between making a contribution & making a commitment. If you're having bacon & eggs for breakfast, the chicken has made a contribution; the pig has made a commitment.

Own the solution, regardless of who writes the code.

Magicians of Code

In general, software developers are expected to be magicians - miracle workers, at the least. I say this with the expectation of being shot down with a spray of non-technical folks' spleen. But with a revelatory zeal I will explain myself further.
I will always contend that developing software, as a profession, is artistic, in that developers create their solutions to real-world problems using techniques learned and passed on by masters, tried experimentally in many projects, improved on, and occasionally discarded as no longer effective. This is not science, in its strictest sense, fundamentally because there is no absolute, no truth sought. This is art.
However, like the great art of old, and unlike amateur art, developers' creativity is usually hampered by their patrons - the exigencies of the business environment, such as time & resources. This should come as no surprise.
Therefore, a developer is expected to create beauty out of something that is generally not sufficient, and is often ugly. They are expected to do it devoid of inspiration or the vagaries of muses. They are given a fixed canvas, limited assistants, and often even only a small palette, and are expected to create a masterpiece every time.
Heaven forbid that someone should point out that art just doesn't work like that!
Then there's the argument that usually comes from frustrated project managers with no background or experience in the arts, that a bridge can be built precisely with known materials, planned to the micron, etc. How often have I told such a project manager to go build a bridge & get over it?
Software developers don't build bridges. Bridges don't solve business problems.

I used to have one such project manager - an inherently stupid & lazy man, but that's just my opinion. I tried to explain to him that what we did wasn't work with steel girders, but it was like rearranging the atoms to invent a new kind of steel each time. He didn't get it. After this, I put a sign on my cubicle which read "Alchemical wizardry applied within". He never asked for an explanation.

And still, each time a project fails - either in being late, over budget, or not fulfilling all of its requirements - it must be the fault of the developer who must be inherently ineffective (or incompetent) if they can't deliver the promised project. Obviously. Writing software is so beneath project managers that they could not stoop to do it. Well, there are those who once wrote a pascal program, and that was a snap. It added two numbers & got the right answer. That could be done in less than a day ...
There is no answer. There is no question. There is only life & its experiences. And there is death.
A project begins. We use what we have learned; we learn more; we help others to learn from us. A project ends. Whether we have led a good project or not is not judged by our success, but by the weight of our souls against a feather on the scales of fate.