…or at least talk. I’m appearing at the Epicenter conference in Dublin next week. I’ve got two sessions lined up:
This intriguing article from Monica Harrington caught me by surprise for two reasons:
Estimation: “
“
(From the genius that is xkcd.com.)
I was talking with my friend Clarke Ching today about Kanban and pull systems in general. I came up with a metaphor that we both liked and thought I would share it.
Problem : Imagine you want to get a ball of string ( your features ) through to the other side of a funnel ( your development team ).
Traditional methods involved pushing REALLY, REALLY HARD until it goes through.
Agile and other iterative methods realise that trying to force a whole ball of string through a funnel at once is madness, so they chop the string up into smaller pieces which are easier to push through.
Pull systems, such as Kanban, change the dynamic, rather than pushing the string through, they feed the tip of the string through and then pull it as fast as they can.
Which of these is best?
Well, traditional methods often cheat by mashing some subset of the string through and declaring victory. Or by making the team ( the funnel ) enormous so that you can fit a fairly large ball of string through the hole without effort. Or by minimising the features so that they’re dealing with a tiny ball of string. Or some combination of the above. I’m not sure this is ever a good idea.
Agile works pretty well, but the chopping takes effort ( iteration planning ) and consumes time. But it does break down into nice, neat iterations which provide clear points for releases, milestones, measurement and feedback.
Kanban works pretty well too, it might be slightly more efficient than an iterative Agile approach, but the milestone and release points need to be superimposed onto it since there are no natural break points.
Lean and ToC have their place here too - tools, techniques and strategies to make the hole in the funnel wider and to make sure that the string that gets through is the right string, used as efficiently as possible. Stretching the funnel as far as possible, just as I have stretched this metaphor.
I was reading through the principles page on the Agile Manifesto site today and I realised that I’ve never really been very good at one of the items.
The best architectures, requirements, and designs emerge from self-organizing teams.
I’ve managed a lot of teams, and for the most part, I’ve been deemed pretty successful. My management style was always to try to blend in with the team, to be one of them, to get people to move forwards by setting an example or by encouraging them. I never introduce or describe anyone as working for me, I always say I’m working with them or we’re on the same team. Of course, there are management activities that need to be performed (reviews, promotions, demotions, bonus awards etc), and I’m happy doing those things. I’ve never felt that knowing people, or treating them as the equals (which, of course, they are) hampered me in any way. The more closely you work with someone, the more of the real them you see. You get a better idea of their potential, their skills, their interests, ways in which they could contribute more to the organisation.
I’m actually lying when I say I’ve never introduced anyone who worked for me as a subordinate. My friend and mentor, Gerry Martin, who was instrumental in my decision to return to college and retrain in software, eventually came to work for me. Every time I got to introduce him as my minion, I got a kick out of it. But, hey, if you can’t poke fun at your best-friend, who can you poke fun at. (Sorry Gerry, you know I love you.)
My attempt at egalitarian leadership didn’t always work out as I intended. One of the things I didn’t consider, is that because I could ignore differences in organisational authority, it didn’t mean that others felt the same. This led to one incident where I upset someone through an ill-considered joke that left them feeling angry, impotent and embarrassed.
I feel that, for the most part, the people on my teams were given authority and autonomy, everyone was given the opportunity to contribute as much as they wanted or were able to. There was opportunity for decision making, direction setting, personal contribution, group collaboration and individual growth. But, were my teams self-organising? Not really. I was always there trying to guide people in the direction I felt we should be moving. Not by edict, decree or demand, but by persuasion, example and leadership. But, in the end, however gently the boss tries to guide you, you’re still aware that he’s the boss and his opinion carries more weight than merit alone. It wasn’t a democracy or a meritocracy: even if everyone disagreed with me silently or publicly, it wouldn’t have led to my replacement.
Is this a problem? Perhaps. I’m not sure what the alternative is. I firmly believe, that leadership is vital to the success of any organisation. By leadership, I don’t just mean “somebody has to be in charge”, I mean that someone has to accept responsibility and authority in equal measure and then use that authority judiciously, sparingly and only for the good of the organisation and all of its stakeholders.
Is a truly self-organising team possible in a commercial organisation?
I’ve been reading W.E. Pete Peterson’s excellent book Almost Perfect (available to read on line here) and he has some interesting things to say about his attempts to add copy protection to WordPerfect. At the time he was running WordPerfect Corporation and was one of only three shareholders, so his perspective isn’t an academic one:
“It was simply not fair to make the honest, paying customers put up with an inconvenience that had been made necessary by the dishonest ones. In the end, what was good for the legal customers was also good for our bottom line.”
The book has been a most entertaining and educational read. It’s great to read the story of an ethical, decent man who built by success without sacrificing his principles. Particularly heartening from a technologists perspective is that he attributes the companies early success to the quality of their engineering staff and their ability to hang on to smart individuals and focussed teams.
Sadly the book has been out of print for a very long time, but second hand copies are available on Amazon, that’s where I picked up my copy.
After watching Dan Roam’s presentation, I decided to see what else looked good from Mix09. The day 1 keynote from Bill Buxton - available right now on the front page of the site gave me an insight into the mind of a designer that I didn’t have before.
Bill talks extensively about the history of industrial design and its rise during the great depression and that we can take the opportunities of the current financial crisis and use them to make usability design a priority.
I’m not sure if his logic, that crisis periods are inherently periods where design can prosper, is well founded but .. let’s hope it is. When you’re stuck in a financial hole, digging may not help but just sitting there doing nothing certainly won’t work. If innovative design and engineering can give us hope - let’s get to it.
Some of the ideas that Bill pushed strongly on were the notions that design has to be fast, has to be iterative and that only trying one approach to solving a problem leads to sub-optimal solutions. I’ve tried the first two of those ideas in development and they work like a charm. I wonder what it would be like to try to get several different solutions to the same problem in parallel? Perhaps that’s really what’s going on in the Java web framework world, or the .NET DI container world. Perhaps, rather than being frustrated by the problem of trying to learn and decide amongst multiple choices we should rejoice that we have options; we should be pleased that we get to choose the design that we believe in most.
The other big take-away that I got from Bill’s presentation was that in selling something you shouldn’t try to sell the item itself. You should sell the experience of using/owning the item. I can see this as a useful tool when trying to build software and also to make engineering decisions. Build software that will lead to a positive user experience and you’ll be a success. When considering two engineering alternatives, ask people to imagine the experience of living with that decision. Ask the technologist to put on his negative/remember-all-the-times-things-didn’t-work-the-way-they-should hat on and ask him to imagine what life would be like.
I’ve said it before, and I’l say it again. I love watching smart, passionate individuals talking passionately about their passions.
Mixing it up in Vegas: In this engrossing and entertaining presentation Dan Roam talks about his theories on sketches and how they unlock creativity and help communication and consensus gathering amongst groups.
I really enjoyed it, I’ll certainly try some of these ideas out, and I will probably buy the book. All those positives aside, three things do bother me about his presentation.
1. He starts off by saying that you don’t have to be able to draw at all to use his methods. That his ideas revolve around using simple shapes to communicate. Then he uses slide after slide filled with drawings that, whilst simple, are of a much higher standard than I could ever produce. (Yes I am that artistically challenged.) If simple diagrams are what you need to communicate .. why doesn’t he use any?
2. I’m willing to accept that using drawings as a means of communication engages parts of our brains that would otherwise lie dormant. What are the trade-offs? What are we sacrificing? Trading in my ability to logically critique something for my ability to create new ideas is something I’d want to do sometimes. When is it good, when is it not? Give me the down as well as the up.
3. I became suspicious when the Dan claimed that we can use pictures to solve any problem. That’s obviously nonsense. At best we might be able to describe any problem using pictures. Describing and solving are two different things. Don’t believe me? OK, well, all of my grandparents are dead. I love them, even those I never met. I’d like them back. Please provide me with the drawing that solves that problem.
Before I go any farther, I’d like to be clear that I’m a Black Pen Guy, When I talk, I like to stand in front of a white-board and scribble. I love to throw a marker to people and say, “show me what you mean”. Giving me a tool to make me better at design, communication and problem analysis is wonderful. That’s all you need to do to sell it to me.
Anyway, rants aside, this is a really interesting presentation with oodles of interesting ideas and anecdotes.
(Via Clarke Ching.)
I like the teams I run to use pair programming, because the end product is better. I’ve also heard lots of people say that they don’t want to do it.
I have a theory that pair programming is the brussels sprout of the technology world. Lots of people don’t eat them because, not because they think they’re bad for you, but just because they don’t like them
I have no children. When I do, they’ll eat brussels sprouts. I won’t do it because I want them to be sad, or to make those little sicky faces that children pull when they put something unfamiliar in their mouth. I’ll do it because I want them to be healthy, productive and to live a long time.
When I go to work I like to wear a suit. I also like to wear a tie. I like to wear thick, starched, stiff collared shirts with thick double cuffs. I like hard soled, thick leather shoes. I like to be aware of how I’m dressed, without being uncomfortable.
Why? It’s my war paint. In the same way that a Native American or a Massai tribesman or an ancient Celtic warrior put on face paint as a symbol that they were no longer at rest, they were now at war, and wholly committed to the task at hand. That’s how I want to feel when I go to work. I’m there, I want to get a job done. I’m committed. I’m not in the same frame of mind as when I’m at home with my wife watching TV.
Is it really necessary? Yes, for me it is. I like to make friends with the people I work with, the people I work for and the people that work for me. But friendship holds a trap. I’m not at work just to hang out and shoot-the-breeze. I’m there to create, to achieve and to add value. My war paint keeps me focussed.
I’ve been working on my CV recently and finding it hard to quantify what I do and am. I’ve worked in almost every capacity in technology:
And a whole bunch of other roles that don’t even have good names. I’ve loved every one of these roles, I’m fascinated with every aspect of technology. Beyond that, I like to flatter myself that I’ve acquitted myself well in all of these roles. I love technology, I love managing people. I love guiding and participation of the creation of something out of nothing. Well, nothing more than sweat, tears, inspiration and a compiler.
I’ve always loved the idea of being a polymath, a renaissance man - but sadly my interests have always been restricted to one field. Luckily it is a pretty big field and there are few people that have become masters of it all. I’m not there. Not even close. But I’d like to be.
Everyone needs a goal in life. “Be the best you can be at the thing you love” works for me.
Here’s a rule of thumb I like to use.
Q. How do you know when a document is too long to be useful?
A. Print it out and try to slip it under the door of the person you wrote it for. If it doesn’t fit … it’s too big.
As a an addendum to my test; whilst you’re at the door, open it, go inside, and say hello. Nine times out of ten, that’ll do more good than the document.
In a post entitled, simply, Software, Rafael de F. Ferreira juxtaposes quotes from James Bach, Erik Meijer and an Alan Kay/Phil Windley amalgam to put together an intriguing argument that quality software doesn’t exist, people no longer care that quality software doesn’t exist, computing is in its infancy and we don’t know much yet, but we’re also not really learning so things aren’t getting better.
I’m not sure I buy it. In fact I’m sure it is bunk. I’ve said for a long time that The Software Crisis doesn’t exist. As an industry we create more, better software cheaper than ever before. WTF is the crisis?
Can we do better? Yes.
So why do people talk about a crisis? Because programming attracts smart, dedicated, attention-to-detail-oriented, meticulous, perfectionists who’re never going to be happy. People who’re always going to want to do better. For many people - including me - software is my art, my hobby, my career, my passion. I want it to be great. I won’t accept second best. I won’t accept shoddy or badly done or half-hearted. I want to build the best .. whatever the hell it is I’m working on.
Equally, I won’t accept people telling me what a bad job the software industry does any more. We don’t do a bad job, we do the best job of writing software that anyone ever has in the history of the world. Possibly the universe.
Can we do better? Yes. Can you beat me with the crisis stick? No, sir, you may not.
My good friend, Clarke Ching, today proposed that we reach out to universities and colleges to help them teach students the things we’d like them to know when they graduate. I’ve done some of this in the past working with universities and colleges in the US and the UK, it was very rewarding. I’d love to do more.
I’m writing this post because a lot of my friends are dyed-in-the-wool Java and Ruby developers who believe that nothing good ever came out of Redmond. I’d like them to think again.
Over the last few weeks I’ve been listening to podcasts that have come out of the .NET community: Elegant Code’s Code Cast, Scott Hanselman’s Hanselminutes and Herding Code and overall my reaction has been, “Wow, the Microsoft/.NET community is really starting to get to grips with Lean and Agile”. This wasn’t the case the last time I worked intensively with .NET about three years ago, back then it seemed that MS and .NET developers were living in the dark ages.
Listening to people working from within Microsoft talking about using Scrum and XP and Lean and how it is making their development better is heart-warming to someone who’s been pushing this message for the last ten years.
That Microsoft are dogfooding their own applications, and changing them to make them work better in support of Agile methods is fantastic news. Microsoft can do a lot of good if they support these ideas openly, and that seems to be their intention.
Microsoft isn’t just making strides in the process department though, the advances they’ve made in the CLR and the languages that run on it are really starting to pay dividends. As this post from Matthew Podwysocki shows, the generative effects of advancing the language and the platform.
That the .NET platform has been pulling ahead of Java in the feature department for a while now hasn’t been a secret. But now, for the first time, I’m starting to see people using these features and talking about these features to solve significant problems rather than brandishing them as ‘the new hotness’.
If only it wasn’t tied to Windows, I’d buy some.
Bob Martin has a presentation he gave at a JAOO conference up on InfoQ. The title of the presentation is Craftsmanship and Ethics, which is somewhat misleading since the presentation is basically on Software Craftsmanship prefixed with “we should be craftsmen, craftsmen should have ethics, it’d be unethical not to”. I was a little disappointed by that - I was interested in his thoughts on ethics and how they relate to the development.
Overall it is an entertaining presentation that will leave the Agile and SC groups nodding and leave those with a different mind-set shaking their heads as normal. I enjoy watching passionate people talking passionately about their passions… so this was fun; but I don’t think it changed any minds or taught anybody anything they didn’t know.
I’m assuming that the crowd at a JAOO event is composed of experienced professionals who care about and investigate their industry. To effect change it isn’t enough to speak passionately. It isn’t enough to tell experienced professionals what you think or feel - they have their own thoughts and feelings and there’s no reason they should supplant their own with yours. People need compelling reasons to change, they need people to provide compelling solutions to immediate problems, they need to believe that by changing they are shedding risk rather than increasing their risk profile. Passion isn’t enough.
Uncle Bob, and the other leading figures in our profession have the opportunity to speak directly to thousands, indeed millions of developers each year, and I don’t think that what they’re doing is working. The Tony Robbins style pitch is enough to get people fired up at the conference, it doesn’t carry enough momentum to provide a solid take-home.
I’m reminded of Geoffrey Moore’s Crossing The Chasm: Agile, Lean, Craftsmanship, all these ideas have been sold to the innovators and perhaps even the early adopters, we need to cross the chasm to get to the next group of technologists - the early majority. Even this isn’t enough, though. We haven’t got the message through to project mangers, business analysts or customers, let alone C*O types. We can present compelling cases when we talk to people one-to-one, but the ideas haven’t taken root in these communities; in Chasm terms we still don’t have a hook in the innovators there.
If we advanced the management and technology communities in parallel we’d have a much better chance of improving the way software development is done.
How do we do it? Well, first off, I think we need to stop talking about quality, top talking about Agile and Lean and Craftsmanship and start talking about value. Value is what everyone wants. Developers want to create value, managers want value created, customers want to buy valuable software.
I firmly believe quality leads to value, but telling people they should want quality leads nowhere. Tell someone they want value and they retort, “Of course I do, how do I get it?”. NOW you can say, “Well, every industry in the world has come to accept that building in quality leads to higher value.” At this point, I’ve never heard anyone say, “Hmm, that sounds hokey. Go build me some shit. I’m sure that my best path to value is by heading through latrine-town.”
When technologists, managers and customers talk about value, they may not all understand it in the same terms. At least not at first. But until they agree on what value is, there’s no way to build successful products or relationships.
The idea that people might not have the same understanding of value is something that many technologists don’t get right off the bat. To explain it, I need to take back something I said a few lines ago. I don’t believe that quality always leads to value. This also brings me back to Uncle Bob’s talk.
I have worked in environments where financial opportunities would arise out of nowhere, last for a few days or a couple of weeks and disappear. In these cases, the opportunity to make millions of dollars a day can exist if you can(in abstract terms) get information in, process it and send it back out within a specified time period. Oh, and the countdown on how long you can do this for has already started. Every moment between now and shipping costs a non-trivial sum of money. In these cases, value comes from shipping. The software might have problems - if it crashes every fifteen minutes night and day, that’s OK .. we’ll run ten copies on ten machines and have ten interns sit and watch them clicking the icon every time it falls over. The software doesn’t have passwords or security, that’s OK we can hire a rent-a-cop with a gun to keep people away from the computers.
Overall, doing this makes money. Sure, over the first few days the team try to improve the quality so that half the interns can go home - but the software is going in the bin in a week .. improvements beyond basic stability are a drain on assets nothing more.
I’ve heard developers shout about this being a terrible, shoddy way to do software and insult the developers who build it. I may even have been one of them. That’s because I wasn’t thinking about generating value with my software, I was only thinking about software for the sake of software.
Now I think about value, I can understand why people build software like that. I can also understand that we can get that software out of the door faster by looking at what we build in each case and trying to pull together some pieces that they can glue together the next time an opportunity arises. Pieces that’ll let us be EVEN faster to market next time. That’s value.
My point, value isn’t a universal truth. Value is relative to the situation. If everyone talks about value at the start, and forms a common understanding we can fit everything else into the framework this gives us.
Uncle Bob, luminaries of the development world, talk about value. Please.
This morning I opened up a copy of Dave Hitz ‘How To Castrate A Bull’ and I’ve been totally blown away. I read it cover-to-cover without standing up. This was unfortunate because I was in the bath. I filled the tub over and over with hot water until I was done because I couldn’t bear to stop to dry myself until I had got to the end.
Dave (someone else I’m on first name terms with by dint of having read his writings) tells of his experiences as a founder of NetApp. The book is filled with amusing stories and side-bars, coupled with sage and hard-won advice, recounting of failures and successes with equal honesty, passing on of lessons learned from others and a thousand tiny observations each a gem in of itself.
I only wish Dave had a second, parallel company at the same time so he’d have a sequel.
Last week I said that I’m using the time I have free to catch up on my reading - getting to all those books I’ve been meaning to get through.
First on my list was Eli Goldratt’s latest book The Choice. It’d been a while since I read his other works, so I decided to re-read them first. In the last few days I’ve re-read The Goal, Necessary But Not Sufficient, Critical Chain and It’s Not Luck. Every time I read these books, I get something new out of them. If you’ve not read Goldratt’s work, I heartily recommend it.
I said that I was re-reading Goldratt’s earlier works in preparation for reading his latest book. I haven’t got to that yet, that’s next on my list. I got distracted when a friend tried to explain something to me by referencing Seth Godin’s Purple Cow theory and, since I haven’t read the book, I didn’t know what he was talking about. So I read ordered a copy from Amazon and read that last-night and this morning.
This is the first book I’ve read that just focusses on the ‘getting the message out’ end of marketing. I’m surprised that I got as much out of it as I did. In retrospect, this is a field I should have spent more time reading about. I need to work to fill in my knowledge here. Anyone with pointers towards the ‘right’ reading material feel free to drop me a line.
For the last couple of days, I’ve been chewing over an experience I had about a decade ago. I’m trying to understand the underlying thought processes that led a problem.
About a decade ago, I worked for a project manager that I’ll call Mr D. He was (and probably still is) intelligent, wise, kind and dedicated. A genuinely decent human being. I learned a great deal by working under him.
I worked for Mr D at a company that was having some problems, Mr D was brought in to try to fix things. One of the problems we had was a slavish dedication to a development process that didn’t work. Mr D saw this, and took my recommendation to bring in an Agile coach and migrate from RUP with all the trimmings to XP. We worked through this process change and things picked up, they got a lot better in fact. But not better enough.
At the time, I was too inexperienced to see all the other mistakes we were making as an organisation. In the end, it didn’t really matter what we did, by the time we started making changes the project was years behind schedule and the writing was on the wall.
Here’s the incident that has bothered me for the last decade.
Our team was following a classic XP process, we were pair-programming most of the time and we decided right at the start to estimate in ‘pair-hours’ rather than in hours to keep things simple. Our velocity fluctuated wildly over the first few iterations and eventually settled to a consistent level. Our estimation unit was hours - that was what we started with, but over time we had come to think of them as arbitrary units, we could have changed the name to ‘arbitrary work units’ but it didn’t seem important. Everyone was working hard all day, distractions had been minimised and people were feeling good about our progress. We knew we could be better, we knew we could improve and we were. Every week were getting a little better.
Mr D, who I realise in retrospect must have been protecting our team from tremendous outside pressure, came in one day and announced that he was changing things again. It was his call, I don’t have a problem with that. It is his reasoning that bothers me. He had totalled up the estimates of work accomplished for the last few weeks, totalled up the available man hours and calculated that we were only fifty percent efficient. He wasn’t even complaining about the pair-programming, he was calculating things in pair-hours rather than hours. When people tried to point out the basis for our estimates wasn’t hours, he became enraged.
In summary:
He knew the basis for our estimates wasn’t hours.
He worked in the same room as everyone else, so he could see with his own eyes that people were working hard all day every day.
But still he came to the conclusion that an efficiency calculation he’d used in the past was telling him something was wrong and that he had to make a change.
Why, despite the evidence of his own eyes, did he come to this conclusion? He didn’t need an excuse to make a change, it was his house and his rules. It don’t even think that he was trying to justify his decision to the team: nobody agreed that his justification made sense, but he kept insisting that we were, at best, only fifty percent efficient.
Was it pressure and panic that made him turn to something he knew, even if he knew it didn’t make sense?
Was it a rejection of the methods we were using, trying to turn the team towards a structure he knew and had more faith in?
Did he really believe that we were only fifty-percent efficient?
I wish I knew.
Over the years, there have been many times that people have made decisions I didn’t agree with, but at least I understood their reasoning. In this case, I don’t disagree with the decisions Mr D made, I just wish I could understand his reasoning. Deep down, the fact that I don’t understand scares me. How can I stop this happening again, if I don’t understand what happened the first time?
If your users can’t find the feature it might as well not exist: “The lesson here is that having a feature isn’t enough, making sure your users can easily find and use the feature is just as important. In addition, sometimes the best thing to do for your product isn’t to add new features but to make sure the existing features are giving users the best experience.”
(Via Dare Obasanjo aka Carnage4Life.)
Dare brings up a good point, if users can’t find a feature .. it might as well not exist. There are a number of related issues here, too. How many features is too many? Is there a critical mass of features, beyond which the utility of an application actually goes down whenever you add a feature?
A lot of people conflate utility and feature set. And they’re definitely not the same thing. A swiss army knife has a lot of features, and some very sharp blades, but they’re difficult to hold because of all the tools so they’re not comfortable to use. Indeed, the more tools you add to them, the harder they are to hold.
Dare also talks about the constant mass of new feature requests the Microsoft Office team get. I’m not a power user of Office by any means, but I don’t remember the last feature that was added that made a difference to me. Are MS sacrificing the utility of Office by adding more and more features? Has the experience of the average user actually gone down over time? I don’t know the answer to any of these questions.
The situation, does remind me of Goldratt’s book Necessary But Not Sufficient, where he describes a company that are swamped with feature requests from users, feature requests that come in faster and faster over time. His suggestion is that people are asking for new features for two reasons:
1. The product is not addressing people’s core problems. The users don’t really understand why they’re not satisfied so they ask for more and more features which seem like they might help .. but never do.
2. The producers of the product don’t work with the users to get them to change, they constantly change the product to suit every individual customer adding more and more ways to do everything until you have such a mass of features that you’ve lost any sense of consistency or cohesion.
I’m not advocating feature minimalism: I still don’t understand why I can’t have a right mouse button or a delete key on my Mac. But I do thing that software engineers consider the benefit of features rather than considering the total cost of ownership of them. When considering the value of a feature, particularly in shrink-wrap software, you need to remember that it’s very hard to take a feature out, so you need to be sure that you want to carry this feature forever.
Features have value. Not having features can have value too. Developers don’t get a buzz out of not implementing a feature though ..
Who’s Your Coding Buddy?: “I am continually amazed how much better my code becomes after I’ve had a peer look at it. I don’t mean a formal review in a meeting room, or making my code open to anonymous public scrutiny on the internet, or some kind of onerous pair programming regime. Just one brief attempt at explaining and showing my code to a fellow programmer — that’s usually all it takes.”
(Via Jeff Atwood’s Coding Horror.)
Jeff Atwood makes me laugh. He makes a valid point - he finds having someone else look at his code valuable, he feels it makes his code better. Something I think we’d all agree is true. He even pulls out statistical evidence for the efficacy of code reviews, which would add support to a well reasoned argument.
Of course, Jeff can’t leave it there, he has to back-track on his own point. Code reviews make your code better but heaven forbid the idea that a group of technologists should agree to do something that makes your code better. He rails against formal reviews and pair programming, instead he suggests ‘just have a buddy look at it’.
I really don’t understand the man, what grudge does he have against the idea, that people can agree to do things that make sense? And beyond that, if people can’t agree to do the right thing, shouldn’t their manager insist? I can’t think of any other industry where leading members of the community would speak out in favour of people NOT doing the things THEY think are right? Would Jeff approve of the idea of a leading surgeon calling for his comrades to give up on M&M reviews and just ask a buddy why their patient died?
Teaching CCPM in an Academic Setting: “I had a kind of slap-in-the-face moment some months ago regarding ‘on time,’ namely the difference between on time as a measurement and on time as an objective. “
(Via Robert C. Newbold’s Billion Dollar Blog.)
I think Mr Newbold has an interesting point here. People find it hard to distinguish between a measurement and an objective. When I first read his comments it took me several seconds to figure out why I would be measuring something if that wasn’t what I wanted.
In the case of software features, I want them completed as soon as possible; but I can’t measure ASAP, so I’ll probably measure what I can - compliance with a plan. It is important for everyone involved, project managers, developers etc. to understand that the plan isn’t what we want. What we want is as much value as possible, delivered soon as possible. In fact the plan is, in real terms, often a listing of the worst case scenario that we can tolerate. Working to the plan in this case is a terrible idea.
Recent Comments