Measuring Progress    [ business/ ]

Background

I am about to take on the leadership of a new, still-in-formation developer team, on a project - the first of several - of critical importance to the client. This means that everything is up for negotiation: team structure, development methodology, coding styles, frameworks to be used,... everything!

Initially my role was confined to that of Consulting Architect, but, by force of circumstance, has evolved to Architect and Team Leader Pro Tem for a few months while the client gets their dev team properly resourced and settled-in. Naturally I'm trying to help that along as best I can.

Methodology

The client initially planned to use a BDUF (Big Design Up Front), waterfall approach to the project. The requirement is extremely well-known and quantified, in a very well understood business domain.

I have never believed in my tummy that BDUF is in any sense realistically or practically achievable, though, even long before the Agile Movement tore the idea to shreds. It is impossible to foresee every detailed design element, no matter how hard you work at it. On the other hand, some Agile proponents seem to say that no up-front design is necessary... Perhaps my hearing is playing tricks with me. I cannot agree with them, either.

So call me a proponent of SDUF: Some Design Up Front.

And on the Process front, I don't think there's a lot to argue about when we contrast a waterfall/sequential process with an agile/incremental process. For me the critical difference lies in how we report and feed-back progress and how frequently we do this. And what we do about the feedback we receive - how flexibly we accommodate direction changes from customers, business sponsors, unit-tests,... to change the still-in-the-pipeline development and requirements without completely trashing the budget and time-to-market constraints. An also-essential aspect of agile development is "to reflect on what has gone before, and to adjust what we do to make things better." [Ron Jeffries]

Waterfall possibly still does have a place in some circumstances. I can't honestly say that I've ever actually been party to such circumstances, though I've certainly been on projects where some of our business partners thought they needed hard, contractual milestones with no going back. (In reality we always "went back" anyway, when necessary, after some amount of renegotiation.)

Metrics

A very greenfield situation, this, which some people would immediately call a "wonderful opportunity", but which I very much see as a "two-edged weapon"...

The question that has been most on my mind is, "What should we measure?"

I am a very firm believer in the old saw, "Tell me how you Measure me, and I'll tell you how I Behave."

Measure a sales-person by the number of sales, and you'll get a high order volume of the easiest-to-sell products, regardless of whether they represent the best margins or quality-of-business for the company. Measure the same sales-person by margin-value of product, and you'd best hope that your high-margin products are ones that lots of people want to buy. Measure them by the number of sales calls they make and you'll have lots of calls that don't result in sales.

Here is where I believe that some Scrum proponents are going wrong... We take Features and break them up into Tasks - the developers' unit-of-work. And they measure Task completions using a burn-down chart of Tasks completed versus time. This can easily result in a situation where many Tasks are being completed, but not so many Features. A situation where Features reach an 80%-complete state, and then get stuck, for any of a variety of reasons, all of which amount to "Nobody wants to complete those Tasks" because they're boring,... or they're "just" test Tasks,... or they're difficult (because not well understood), or...

The solution is really simple. Just measure Feature completion instead of Task completion. Then the team only gets rewarded when Features or User Stories get completed. We only get beer and Pizza when the Business gets value.

But is this enough? Can we go further? Is there a way to tie developer reward directly to delivered Business Value?

In the situation I'm headed into, Business Value should be pretty easy to quantify: The product to be built is one that will directly generate revenue for the company, so we can very easily quantify how much Business Value the software is generating. (Successful completion of the product will also deliver a huge  strategic Business Value by enabling new revenue streams, but that's also quite easy to quantify, and, indeed, is the prime reason the client is taking on this quite substantial investment in the first place...)

Are there ways to close the loop? To feed-back to the dev team on how much business-value their efforts are generating without making money too much of an up-front issue? Then, too, I have a reservation: Developers can have notoriously short memories, and the sort of value we're talking about here is only delivered on longer time-scales... Maybe it's good to have both long-time-loop feedbacks as long as we also have the short-timespan feedback in place as well... Waterfall's failures are largely a result of too little feedback taking too much time for us to correct project course when we need to.

My instinct is that moving towards a continuous deployment process (the step beyond continuous integration) might help to shorten this feedback loop, which is completely the point of "agile" thinking, but I'm still not really clear on how we might implement it.

Changes. Already!    [ business/ ]

Some date changes to the course schedule, plus I've added some Johannesburg-based courses.
The whole course catalogue has also been revamped for easier reading.

New Courses Scheduled    [ business/ ]

Courses newly scheduled:


Please contact me directly if you're interested. Places are limited, especially for the Design Patterns course.

More to come soon... if you're interested, I suggest that you keep track of my course schedule page feed (the feed-link is near the top-right), or course-schedule calendar in your feed-reader. (You are using a feed-reader, aren't you?)

Sun and Oracle    [ business/ ]

The short version? A fucking disaster for everybody except Oracle and Sun's execs and (maybe) shareholders. i.e. The Kakistocracy wins and the rest of us get shafted. (As usual.)

I think Oracle are getting an absolute bargain. $7.4 billion is chump-change for the IP they're acquiring. The question is, Which pieces are they going to keep, and which are toast? Some of this is blatantly obvious, other bits are pure crystal-ball-gazing on my part.

Java: the no-brainer. Oracle are heavily invested in Java for the Enterprise stack. Bad news for open-source Java? Maybe! Or maybe not... it all depends on whether Oracle were backing Apache simply as a tactic against Sun in the JCP. I've heard a number comments along the lines of "it's GPL -- the boat has sailed". They're forgetting that the owner of the IP can do as they please, including closing the source completely in the next release. (Not that I think it very likely; just a possibility.) Yes, an open-source community might be able to follow, but I'm betting that there would be compatibility problems.

MySQL: Toast. (Personally I never bought the logic behind Sun acquiring MySQL, and then they went and mishandled the whole thing badly.)

Glassfish: More toast. What will this be... Oracles fourth appserver? I lose count.

Netbeans: A cold shaft of ice pierces my gut. I love Netbeans. I just don't much like its competitor (just a personal preference; don't read too much into it!) But I fear that this might be the end of the road for NB... OTOH it can -- unlike so many of Sun's other open-source projects -- probably survive, nay flourish, as a standalone open-source IDE. After all, that where it came from in the first place.

OpenOffice.org: Makes perfect sense for Oracle. I bet on them keeping this one going. In fact, this might be the Secret Weapon Acquisition... the knife with which Oracle goes seriously for Microsoft's jugular in the Enterprise space, together with Solaris and the Sun hardware.

Solaris: I'm betting it stays. Oracle's strategy has been (to the limited extent I bother to keep track) to lock up the mission-critical, "hard-to-do" stuff in the Enterprise space. And there's still a whole lot of stuff that Solaris does way better than Linux.

VirtualBox: also plays well into the Enterprise/datacentre "integrated offering" strategy.

JavaFX: not one I'm capable of guessing about... any offers?

And the Sun hardware: makes pretty good sense for Oracle, in my limited understanding.


On a more personal note, much closer to home: How likely is it that Oracle will retain Sun's training programs for Java? Methinks it unlikely, since they already have their own training programs. What does that mean for the first Sun-authorised Java trainer in Africa?

Not good news at all, I'll bet!

All-in-all I think the acquisition is terrible news for Sun people, and probably not good news for their customers, either. I am finding it hard to see it in a good light for Java, either, and, having (literally) bet the farm on Java for the past 13 years, find the prospects quite discouraging. And for open-source in general it's a disaster. Despite the Slashdot whiners, Sun has sunk an incredible amount of money and effort into open-source projects, and I simply don't believe that Oracle has the same largeness of vision.


Oh well. Shit happens. I suppose its still a step better than Sun going under completely... Best I get a move-on with further developing my own training material and courseware.

Damager or Manager?    [ business/ ]

Since Open Letters to Management seem so flavour du jour, I thought I'd save the following fine rant from oblivion. Names and project details changed to protect the guilty, of course.

[DumbTribe] is a small startup in the mobile space. They have started seeing some good traction for their product, but are completely chaotic in their "management" of the company. The company is 100% reliant on IT, yet, whilst they're willing to spend an ordleplex of money on fancy new offices, they're astoundingly short of cash when it comes to things like buying another server to act as failover for their single server. Said server is the sole source of income for the business.

What [ManagerX] calls a "blogger tool" is really a form of Content Management system that ends up providing (among other things) Atom and RSS feeds...

[ManagerX] wrote:

> This has certainly taken longer than we initially thought it would. I
> think it was over a few of months back that we were expecting a
> finished blogger tool.

You seem to have forgotten that there were other tasks that YOU prioritised ahead of the "blog" tool -- development of the feed aggregator and the [BigClient] pilot, not to mention system administration tasks more numerous than I can recall, design and coding assistance to my colleague, installation and maintenance of essential technical infrastructure indispensable to organised development (some of which runs on my own servers, at no additional charge to [DumbTribe], simply because that was the fastest way to get the tools in place.) I regret that I am unable to work on more than one thing at a time, but these are rather complex systems dealing with some very erratic, "dirty" data coming-in, and, like most men, I don't multitask well.

> It is of zero use in it's present state(just like the blogger tool you
> created was in it’s 'unskinned' state(to me the level of things that
> fell under 'skinning' was surprising.

First: I warned right from the start that installation of the necessary software was the quick and easy part, but that changing templates -- "skinning" as you call it -- would take at least several days for someone expert in the templating system. I also made it clear that such templating was NOT in my sphere of competence. Evidently nobody was listening to the bits they didn't want to hear.

Second: I will not take responsibility for your inability to produce a coherent specification for the tool. Lack of any technical specification underlies the several misdirections and false starts. A powerpoint does not BEGIN to form a clear technical specification.

Example: I, at one stage, asked you how many "blogs" it is necessary for the system to support. At that time I had in mind to use a particular piece of software as the foundation infrastructure. Your answer to my question was "thousands!" which answer had a significant impact on my technical decision-making, since the tentatively-chosen solution is unsuited to such large volumes. I certainly made it clear that I was unfamiliar with the more suitable tool, and, indeed, the "skinning" -- the writing of custom templates -- turned out to be more problematic than I anticipated. I made a poor guess in the face of inadequate information, a misleading business requirement and insufficient time to evaluate alternative technical solutions.

In the long run it turned out that a "blog" system is just what [DumbTribe] does NOT need. What IS needed is an article/story management system for providing Atom/RSS feed output. This is in the final stages of development.

You seem to have forgotten that using a blog-system was initially mooted merely as a temporary stopgap solution to provide a mechanism for getting article content into feeds; it was never intended to be the "real" solution. What I have been developing is such solution. Assuming you don't sabotage delivery with yet another interruption.

I would have been finished 10 days ago had [my colleague] had enough spare hours to assist me on areas where I do not have the deep knowledge of data structures and code she already has in place, and if the "specification" had not been changed on a number of occasions. Unfortunately other more pressing issues have had to take precedence on her time, with resulting delays on the "blog" project. Furthermore the assistance I have (gladly) given [said colleague] on other projects has also had the effect of taking several days from "blog" development.

> I am sure you understand what this looks like from our end. It just
> feels like you can’t give us what we need.

Yes, I am pretty sure I DO understand. It seems to me that you think one of two things; either:

1. That I am incompetent to produce working software, or

2. That I am dishonest and lie to you about my activities.

I am neither, and find either accusation hurtful, denigrating, and completely unprofessional. Software development, unlike so many other jobs, does not allow one to delude oneself about the limits of ones knowledge or abilities, so the charge of incompetence is easier for me to dismiss when I consider its source; I know exactly how good I am.

Clearly you have absolutely no clue how software development works, nor what is a "normal" pace of production for software systems. The fact that your most-recent experience of software development is exemplified by [colleague], who is prepared, for reasons I cannot comprehend, to endanger her health and wellbeing by working outrageous hours in order to meet ridiculous, unrealistic and arbitrary deadlines does not alter the truth of what I am saying. Nor is it my place to attempt to teach you how software development works; for that sort of work I charge considerably more than you pay me.

The fact that you have badly under-resourced this area of the business is hardly my fault.

> I am so frustrated and feel if I have to explain what we need again I
> will go mad.

Unfortunately software is all about the detail. If you do not tell a developer all the detail that they need, they will guess, and likely guess wrong.

Therefore, where details are lacking I will ask again and again and again. I have on occasion asked users to describe their requirement from beginning to end as many as 8 times in a single day in order to be sure I understood the requirement. Then I asked them a couple more times the next day. I am deeply sorry if my need to know what you want in full detail drives you mad -- I certainly do not wish to cause such mental anguish.

> Please can you confirm that you understand and accept all the
> functionality that we need

No. I do not believe I understand what you need, particularly as you keep changing the requirements. I am not a mind-reader, and you have not produced a comprehensive technical specification.

Example: Your comment on Monday, "Make sure we can direct the 'see original story' link to a site of our choosing (e.g. [ClientA] sites or [ClientB] sites)" This directly CONTRADICTS the requirement laid out in your powerpoint that NO such link be present. What am I supposed to do with that? I can put such a link in (though linking to what, I have no idea, nor do you say -- another missing detail) or I can leave it out (as is done at present.) I am happy to do either, or to make any changes you require, since I understand that business requirements can and do change from time to time. However, changing what is already implemented does unfortunately take some time and cannot simply be done with a wave of a magic wand.

Example: The original requirement was for articles to have a single image attached. Then an image or a URL. Then multiple images or URLS. Then it became "unusable unless we can upload video". Then we didn't need video any longer. Then we were back to one image/URL. Currently I am informed that multiple images/URLS are a non-negotiable requirement. Every time a change such as this is introduced it costs me hours or days in the attempt to comply.

And you wonder why there have been delays.

My current aim is to get the system in place with the capability to upload ONE image or attach ONE URL, either of which shall appear at the tail-end of the feed content (another detail not specified.) It is my belief that it is better to get SOMETHING up and running, even though we all agree that it is NOT the end-product desired. Then we evolve it to the state we desire. After all, that is why it is called "soft"-ware.

> and let me know what *date* we can expect a working tool to start
> testing.

In the absence of a full, clear, comprehensive specification, no such estimate can be made by anybody. In effect you are waving your hands about, saying "build me a Tudor-style house over there" and then demanding that I tell you how long it is going to take without giving me the plans for the house, specifying the building materials, size of the house, number of bedrooms, etc. When you supply me with a proper User Requirement Specification -- for which I will gladly supply a Word template outlining all the necessary information it should contain -- I may consider beginning to make estimates.

> I don’t think it is unreasonable for me to ask you to commit to a
> deadline, the brief is surely clear now after all these emails back
> and forth and the very easily accessed example of blogger.com which I
> asked you to use as a starting point.

On the contrary I think it thoroughly unreasonable to make such demands. The "brief" (whatever THAT is) is non-existent. To point to blogger.com and claim that that is what you want is ridiculous, since blogger.com is totally unsuited to your needs. If it were suitable there would have been no need to build anything else and we would not be having this conversation.

I will remind you that I am contracted to deliver 40 to 80 hours per MONTH of work -- not per week. This was deliberately and clearly negotiated up front. Consequently I do not work full 8-hour days on [DumbTribe] activities, which, too has its effect on delivery schedules. The fact that I consistently seem to end up working more than the agreed number of hours per month seems to be taken for granted, or alternatively is regarded by you as an attempt to rip you off. On the contrary, it is a good-faith attempt to come some way further than I strictly, am contractually obliged, in an attempt to help [DumbTribe] meet its goals.

A lack of planning on your part does not constitute a crisis on my part.

In the extremely unlikely event that I elect to extend/renew my contract, should [DumbTribe] wish to do so, please be assured that I will require a considerable tightening-up of the conditions relating to all of these issues.

Reprise    [ business/ ]

My week for being haunted by old ghosts.

A bit more than a week, actually... It all started last Thursday with a call from a lady working with a lot of organisations that support HIV counselling, treatment and management. A lot of organisations. She had tripped (how?) across a product/project that a few of us put together some years ago that we called Projectory. Projectory is a collaboration and communication platform, specifically aimed at software-development organisations and teams. Think of CollabNet. But better, of course! ;-) Certainly quite different in some key ways! Except we never got the business off the ground, mostly through an unlucky turn of events that resulted in us losing key sales people at a most critical time.

My caller was wondering whether the Projectory platform could be adapted to help them to communicate, collaborate and coordinate better with a couple of hundred other organisations. Well, we've set up a meeting for next week, and we'll see... What a blast from the past, though! I had all-but-forgotten about Projectory... Thankfully I have the code archived away somewhere safe.

And then it happened again. A call from an ex-colleague a couple of days ago: Could we put together a rough estimate and proposal for a social-networking platform for World Cup 2010. In case you're living in a cave (or the USA where "football" means something completely weird) South Africa will be hosting the 2010 Soccer World Cup, and, for South Africans, it is a very big deal. This is, after all, the second biggest sport event in the world after the Olympics. (China get the hell out of Tibet!) The weird bit is that what's being asked for is very, very close to the project we called Flightwish -- a social-networking platform centred around group travel opportunities and concepts. We failed to get funding for Flightwish, though we tried hard. Normally I would favour a small-start, organic-growth, little-or-no-funding startup model, but that path is clearly a very poor fit for a Grow-Big-Fast webalicious venture. Since then, a few others have started playing in that space, but I have yet to see any of them put together the exact combination of ingredients we planned. Would we have done better? Who knows?

But now we may just get a chance to try it again.

Key takeaways:

Guy Kawasaki Finally Catching-up with Me?    [ business/ ]

In Is Advertising Dead?” Guy Kawasaki finally reaches the place I was at in "Why Advertising is Broken", posted back in July.

Welcome, Guy!  Its going to be very interesting to see how this story plays out.


Technorati Tags: , , , ,

Old New Venture    [ business/ ]

Sometimes you just plain run out of energy.

That's what happened to us last year.  Bruised and sore from the sheer amount of energy we put into Flightwish, only to be repeatedly turned down, we gave up.  I even contemplated selling our domain names – a nice block of four closely-related names – on eBay.

But, as renewal date for the domains approaches, we have decided to give it a go once more.  After all, before we got involved with business plans, venture capital companies, bullshit artists, prototypes and minds-games, the idea really was cool, and targets a real need.  After all, the concept originated with my Dad -- a total non-techie, which gives it a lot more credibility than most of the web startups out there.

So we've started kicking the tyres again, and lo and behold! The fun is creeping back into it!  We've no idea whether we can make any money out of this, now or ever.  We don't care, right now.  We have a cool idea for a web community that we want to put together with some help from our friends, and we're going to have some fun doing it for as long as we can keep the lights on.  Drop me a line if you're at all interested...

We've put up a fun front-page so far, where we can drop a few hints as we work on the software.

Technorati Tags: , ,