Just Add Ingredients & Stir

This is how to make money in IT:

• envy others who have made money
• find some investment
• make promises
• hire some cheap developers
• tell them to build a product that is going to make money
• provide them with 'sufficient' capital expenditure
• base software decisions on open source options
• claim that you don't want to build a Rolls Royce solution
• demand harvesting of low-hanging fruit
• wonder why it's taking so long
• sit back & reap the rewards

If any of this sounds familiar, then you definitely work in IT. If this sequence has ever actually worked for you, then please send me an email, because I'd like to be one of those investors.

Reality is harsh, even in IT. People make a lot of money out of having brilliant ideas & the drive to put them out there & make them work. You cannot capture the market from your armchair, any more than you can develop good product without investing in what makes good product - people (product people, development people, marketing people, etc) & infrastructure (support, teamwork, process, leadership). There are no easy solutions, otherwise everyone would be able to just do it, which means that no-one would stand out, which means that no-one would be able to have any real success.

When packet cake mixes were first introduced, they were literally "add water & stir". These didn't sell. No-one wanted to move from fully-home-made to "do no real baking process" - the producer failed to understand the market, no matter how excellent the product was. The solution was a marketing one - ensure that the end user has to add an egg. This added complexity in the process made the production cheaper & made the end-user happier. The product sold like ... hot cakes.

Success in IT is the same - the product needs to be not just an excellent collection of ingredients, but a solution to an end-user problem that the end-user appreciates & can understand as fulfilling their needs. Anything less will sit on the shelf & grow mould.

A complete solution takes time to 'build' - as software, as an idea, as a product, as a solution (& these are distinct phases). There are no short-cuts. There is no easy way.

The newest buzz is "lean" - lean start-ups, lean development, etc. This means no wastage. Every CEO rubs their hands & says "That's what we want!" & cuts budgets or expectations. Lean actually means investing in the right things so that we don't waste time & resources on the wrong things. Process is essential when they support the development of product. People - the right people - are essential to produce good product. Wastage occurs when hiring 'anyone' is deemed sufficient, or else trying to hire "the right person"; when processes are imposed because they're "best of breed", or when no process is followed & people go around in circles doing the wrong thing for too long without realising, because they're too busy looking busy to notice what they're too busy doing.

Waste occurs when the only outlet for frustration is a blog that no-one reads.

Stories Before Bedtime

I find myself, yet again, forgetting my own advice & doing things in a manner that will give me unending nightmares in the long run.
Agile methodologies always talk in terms of stories. This works for software development when you incorporate non-technical people into a project. You allow them to answer the question "What is it meant to do?" - whether that's a single feature or the whole product - & their answer drives how it does it, how the deliverable is tested, & how success is measured (acceptance criteria).

Why do we forget these things as we go deeper into the development cycle?

Stories are good, in general, for all phases of the product life cycle, & indeed for all phases of business around product. If you can't clearly & succinctly state what the end goal is, or what the deliverable looks like, then failure is the most likely outcome.
That's reality.

Stories start with the big picture, but getting down to the nitty gritty, every component, every package, every class needs its own story. I get a little frustrated that I can't 'document' a package within the code, but that's why we have things like documentation in the first place.
Pictures are meaningless unless they have some words around them that say why things are represented as having certain relationships. Generating pictures from the code doesn't give you anything beyond what's in the code. If the code doesn't have a story in itself, then there is no story 'created' by generating pictures.

Each class should explain succinctly, then with more detail, what the purpose of that class is. That's why we have headers - not just for copyright or company policy - but to tell people what's going on. Tell your peers. Tell your audience - which is anyone who opens that class file.
Similarly, each method needs to have it explained clearly what the purpose is. It's not just the public methods, because that's all that the default javadoc setting generates - it's for every schmuck who follows you. It's for you in six months time when the droob you'd handed the code over to leaves the company suddenly.

Explain what the purpose is. Explain what the outcomes are. If you're not writing tests until afterwards (heaven forbid), then those tests will be meaningless unless they correlate with what the methods do, & therefore what needs to be tested.
Everything needs to be explained as if to newbie. Assume nothing. Start with the simplest possible statement & elaborate. Make references to other classes, packages, components, products - anything that might give the reader a clue as to what your thinking was when you used a HashMap instead of a TreeMap even if you know that the key is Comparable. There could be a valid reason, & it could be one of those things on which the operation of key features depends. If you don't tell the story, then no-one will know.

Stories should give you peace of mind. They should help you to sleep at night, knowing that you've done the best job that you can. Stories should come first, but they need to be in place before you can say that you've finished a project & you can put the whole deliverable to bed.

Failure Driven Development

I'm back in the dev chair at the moment - as opposed the chair that directs devs. Time & again, I reminded of how test-driven development is a wonderful philosophy becaue of what it gives you in terms of direction & scope, & also the artefacts left behind in terms of regression testing. I could not sing the praises enough, & have tried in vain to get devs to comprehend the sheer delight of discovering that example code, proven software, & a general plan are just 'there' for everyone if you do things the right way. Obviously, you have to embrace the vision, because simply following the formula is not enough - you gain no insight, you gain no value.

The reason why test driven development should work for a conscientious dev is that a test is written to fail, & it is the challenge set for the dev to make it not fail. Devs like challenges - I know I do. Failure is not a bad thing. We have to learn from our mistakes, & extreme programming, where test first is a pillar, says that courage is needed to accept 'mistakes', share them, deal with them, & move on.

If a failing test is a 'mistake' - the software doesn't do what is needed, even if it is a new requirement - then you definitely need to discuss it, not bury it. You need to communicate as a team why the software doesn't already fulfill that requirement, & how it will be changed to do so. This makes perfect sense. This is the design phase of any new work. It is the same when the software 'should' have been able to perform the function, but somehow doesn't - a bug. There is no difference in the approach in those two cases. Neither should be hidden, both should be discussed before attempting the corrective work.

If we think calmly about the design phase in this way, then the next stage is thinking calmly about the coding phase in the same way. When approaching the problem of "I need to add this new piece of functionality", most devs follow the white rabbit down the hole with a series of speculative phrases like "to do that, then this needs to happen, which means ..." until they disappear up their own cavity.

Pretty soon, you've got half the code in transit trying to make it all work up & down the line of changes. If, instead, you take a failure-driven approach to development, then the first thing you do is the new function's interface - the requirement is to display a widget, so I'll assume it's there & just display it. To display a widget, I call on the widget's display method, because that's how widgets work. Oh. No widget, no display method. My current UI doesn't work, but it would if I had a widget with a display method.

Stop right there. Make the UI call the widget's display method. It will work once the widget has been developed - even in stub. For that matter, it will work right now with a mock object. You can test the UI. That's just like test-driven development. You can complete the UI as you define the widget. When the UI 'works', you move on to the widget.

Learn to love your IDE. I've been a big fan of Eclipse for years & feel sorry about the demise of NetBeans (sorry, been too long since I used IntelliJ). The important thing is that these IDEs are getting powerful enough to help you develop code (not software) because the people who develop the IDE are the same kind of people who use them.

If you sit at your UI class & type in "widget.display()", then the IDE will tell you that the class doesn't exist - & will help you create it - & that the method doesn't exist - & will help you add it - without leaving the UI class unnecessarily. Those compile failures are beautiful things that allow you to code up quickly. Don't be afraid of creating compile errors just to see where things go wrong. Don't try to keep all of the impacts of your changes in your head. Don't start at the lowest level & forget how the UI was going to use the widget in the first place.

Embrace change. Be driven by 'failure' to complete the functionality intended, not just write the code you expect to write. Test. Test first. Love the tests. Make them fail, so that they become better & more useful.
Never comment out a test. Never make test code that only checked what you were developing at one point in time - either that code is useful enough to be a part of regression, or else it should never have been written because it wasted time best spent writing a real test.

Failure is good. It makes us grow & be better at what we do. It helps us to learn. It also makes it easier next time to avoid the same pitfalls. Recognise the signs of impending failure & either deal with them directly (mitigate), or take the hit & deal with the failure afterwards. In the end, it doesn't matter, as long as you don't bury failures.

If this post has missed its mark, then I will have learned more than if I had never written it.

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.