Aehso’s Output

Working Backwards.

Not as crazy as it sounds, but when you are designing something new, you sometimes can do worse than start by working backwards. Werner Vogels recently wrote how Amazon use this process to help their small teams produce services that customers (internal or external) want:

The product definition process works backwards in the following way: we start by writing the documents we’ll need at launch (the press release and the faq) and then work towards documents that are closer to the implementation.

The Working Backwards product definition process is all about is fleshing out the concept and achieving clarity of thought about what we will ultimately go off and build.

Given the recent bounce back in Amazon’s commercial performance and the quality of their Amazon Web Services suite, working backwards is clearly, err, working well for them.

Update: The AWS blog has announced the beta release of yet another monster web service, the Amazon Flexible Payment Service (FPS).

Some software project signs to watch for.

Dare Obasanjo has a Top Ten Signs Your Software Project is Doomed post in which he references some other great posts about The Schedule Chicken Game, Second System Syndrome and others pertinent issues.

Curiously, the word requirements doesn’t appear once in his list yet poorly defined requirements must be the most common reason why software projects fail. If you don’t have good requirements you can’t even get as far as most of these issues, or even use simple techniques like MoSCoW to avoid them.

On a related note, good to see How Projects Really Work continues to evolve, now at v2.0.

What’s 3.2billion, along the long road of many acquisitions?

Is 3.2 billion silly money for a technology that really just enables online demos??? It doesn’t even do cool YouTube web 2.0 demos. What the???

All I know is, every time I have had to do a WebEx in the past I’ve have always had to resort back to IE7 (from Firefox 2). It sucks, but someone payed $3.2billion for a browser dependent presentation platform? HOLY CRAP!

Mobile network operator focus group last night.

So I was invited to a focus group hosted by one of the Irish mobile network operators last night - I’m not sure if it’s cool to name the host company so I’ll err on the side of caution for the mo. It turned out they are preparing some new products (hint - might explain why I was invited) and they wanted some feedback on some proposed new price plans to con(vince) users to sign up. Hi again if you were one of the folks behind the one way mirror!

Interesting things, focus groups, I guess they are a reflection of how profitable and mature an industry is. I can see there is a lot to be said for getting face-to-face with your customer as long as the sample rate is high enough to get reasonably balanced feedback.

The software industry, in general, just does not do enough of this type of thing, even though we all know that accurately gauging requirements on an ongoing basis is so crucial to the success of processes like Scrum…

JSR-271 Early Draft reviews

The java modularity train-wreck-to-be is still ploughing full steam ahead.  The recent publication of the JSR-277 Early Draft has resulted in a some very sharp criticism.  Lots of posts aggregated in this great post but Patrick Beno’s review is one of the most comprehensive I’ve read. 

InfoQ have just gone and stoked the flames further with post where their questions (solicited from the community) met with laughable responses from the JSR-271/JSR-294 spec leads.  Honestly, the companies and individuals represented on the ECs for this JSR should be asking themselves some hard questions about whether they want to continue to associate themselves with this mess.

Exemplary tools and extensible frameworks, the ying and yang of Eclipse.org.

A while back I wrote that perhaps more needs to be done to coordinate the efforts of the various top level projects and the conversation seems to be evolving. Some of the subsequent discussion raised an interesting question - what is the relative importance of producing exemplary tools versus extensible frameworks? The difficulty, it seems, is in striking a balance in developing both.

A quick search (in the Eclipse Bylaws and Development Process) produces the definition of exemplary tools. It is worth reproducing here:

Eclipse Platform tools are exemplary in that they verify the utility of the Eclipse frameworks, illustrate the appropriate use of those frameworks, and support the development and maintenance of the Eclipse Platform itself.

To verify and illustrate the appropriate use of frameworks.

Ed thinks the tools are the basis of the Eclipse phenomenon and I fully agree that JDT was the primary driver for the phenomenal rate of adoption of the Eclipse platform. JDT served as the exemplary tool for Platform and subsequently, under the guises of Eclipse.org, it is evolving as both a best of breed tool in its own right and also as a domain specific framework for reuse by other Java centric projects. The JDT exemplary tools alone are not enough to facilitate the requirements of these downstream ‘consumer’ projects.

(It is also worth remembering that the bulk of the Platform and JDT/Team was created by one organization - IBM’s OTI Labs.  Eclipse.org is a very different organization - an open meritocracy, backed by many commercial interests running many top level projects that are tackling more varied and diverse problem domains.)

Then there are the two other types of consumers that Eclipse.org also services:

• Adapters. These comanies consume projects developed under the auspices of Eclipse.org and
  build derived tools outside of the Eclipse.org umbrella. Adapters consume extension points and also some exemplary tools (e.g. the WSDL editor in WTP). But for the most part adapters are building on Eclipse because of the powerfully integrated frameworks it supplies.
• Users. Those millions of downloads don’t come from nowhere! Users are interested only in taking the output of one or more Eclipse.org projects (or derived products) and consuming them as-is. For example a user might choose to use WTP instead of a commercial Eclipse based IDE like Rational Application Developer or one might choose to use TPTP instead of Rational Functional Tester. These users are mostly interested in free tools - derived commercial tools usually provide more function but at a price.

The danger, in terms of under-investment in framework integration, is faced by the downstream projects, adapters and users. As they consume more top level Eclipse.org projects into a single product they might find themselves inheriting frameworks and/or tools that either do not integrate at all or worse duplicate core functionality. In this case, all the exemplary tooling in the world won’t compensate for the inability to get disparate frameworks from different projects to play well together.

So we can hope this will never happen but with the Eclipse.org project count expanding the risks are escalating and as Murphy’s Law states, “If anything can go wrong, it will”. A neutral Eclipse.org mediation facility may be the only way to ensure that top level projects - that are managed by different concerns that compete on a commercial level - produce frameworks that meet the high standard set by the original Platform/JDT contributions and integrate in a consistent fashion into a larger Eclipse “Platform” (hmm, is there a better term for that?)

On Eclipse.org project interaction (again).

Mike Milinkovich and Gunnar Wagenknecht picked up on my earlier post about Eclipse.org project disarray. It’s great to see the issue being discussed openly so I thought I’d clarify where I’m coming from (before someone jumps on me from a height).

On the topic of inter-project interactions, to me there are four main types of interaction

• pushing functionality down (”top down”) proposals
• promoting framework reuse by downstream projects (”bottom up” interaction).
• peer project driven cooperation (usually via refactoring to a common upstream project) as Doug describes.
• project “splitting” interactions, where a project splits to decouple unrelated components.

The comments on Mike’s blog have good examples of each and I suspect there are many, many more that might potentially make sense but have never even been broached publicly. I’ve witnessed obvious integration points being missed possibly out of ignorance - these top level projects are big, it’s hard to know them all inside out So, lots of interaction types.

To the external observer, the process for these interactions is to wait for one conscientious party to instigate ad-hoc discussions, perhaps on a PMC and/or a committer level (often facilitated by Bugzilla). We all know approach does work well for micro issues, years of practice in the OSS community proves that. It sometimes even works well for macro level issues where the parties know each other well and have a shared interest in cooperating.

But Eclipse.org is fostering frameworks that not only build on a common base platform (and sometimes shared sub-frameworks), it is publishing multi-tiered frameworks that commonly have interdependencies on each other. This is a more complex problem space to manage than, say, Apache Commons, or even Apache HTTPD. (That said, I do agree with John A’s comment that perhaps platform can be broken up a bit more - splitting Equinox was great, treating RCP as a separate top level project (away from IDE) might also make sense).

Macro level integration issues like proposing change of ownership of extensions or evaluating the risk of introducing dependencies on extensions developed elsewhere are sometimes contentious and they do not always progress via the above process. Sometimes they don’t progress at all and that in itself isn’t necessarily a problem, until the project hits 1.0. Then it has an API set to maintain that doesn’t fit with other Eclipse.org frameworks. The requirement to support 1.0 APIs is where the problem really starts hits home - before then projects are in their “honeymoon period” and I’m not sure the cost is fully evaluated by the younger projects. I think this is perhaps where the foundation (and Planning/Architecture Councils?) can perhaps facilitate a little more. Not necessarily driving or forcing these types of interactions, but mediating them, from the “bigger picture” perspective.

This point should be taken in the context of the recent explosion in growth of Eclipse.org, both in terms of new members and top level projects. It is a growing pain that the foundation needs to look at. As I mention above, the problem space that Eclipse.org is trying to govern is a little more complex than that of most OSS communities. Perhaps projects need to be monitored just a little in order to end up with a truely consistent framework.

Joel Spolsky on Development Abstraction (and Dolly Parton)

Joel Spolsky has produced yet another excellent essay, this time on Development Abstraction. The analogy between software developers cutting code and artists recording songs is a compelling one and I think it clearly illustrates what is missing in most software development organizations:

Nobody expects Dolly Parton to know how to plug in a microphone. There’s an incredible infrastructure of managers, musicians, recording technicians, record companies, roadies, hairdressers, and publicists behind her who exist to create the abstraction that when she sings, that’s all it takes for millions of people to hear her song. All the support staff and management that make Dolly Parton possible can do their jobs best by providing the most perfect abstraction: the most perfect illusion that Dolly sings for us. It is her song.

When you’re listening to her on your iPod, there’s a huge infrastructure that makes that possible, but the very best thing that infrastructure can do is disappear completely. Provide a leakproof abstraction that Dolly Parton is singing, privately, to us.

Without the invisible infrastructure the artist won’t succeed and I fully agree that the same applies in a development group. There is no point in having an orchestra and a conductor if they have instruments that don’t work and recitals are performed on the side of the road.

From a team process point of view these views dovetail nicely with the emerging development processes like Scrum. We recently adapted Scrum in Cape Clear (with a little help from exoftware) and the new process, with a little role changing, already seems to be having a major impact on development organization productivity.

(Spolsky is definately on a run with his use of prominent female figures in his analogies - his keynote presentation at EclipseCon 2006 a few weeks back was attention grabbing, hilarious and food for thought…)

Waterfall 2006 - nervous laughter abounds.

One of the more popular spoof software development websites doing the rounds these days is Waterfall 2006 and it is quite funny in that viral kind of way.

What makes the site even funnier is actually watching real sofware engineers and managers nervously laugh about it’s content. It reminds me of The Office for some reason…