Last updated: 2010-02-08T11:43:28Z
I am part of a team at ThoughtWorks helping out organizing the very first RubyConf in India. I’m very excited about this. So if you have the possibility to come to Bangalore, the event will be March 20 and 21. We already have some solid speakers lined up. Chad Fowler will keynote, and so will I, and we have a number of other people coming in. A few of my colleagues from ThoughtWorks, such as Sarah Taraporewalla, Sidu Ponnappa and Aman King. Other speakers include Hemant Kumar, Pradeep Elankumaran, Arun Gupta and others. Finally, Nick Sieger will also come to Bangalore for this event! So as you can see, this is gearing up to be a great event! Hope to see you there.
Last updated: 2010-02-06T17:34:00Z
The family medical issue has been resolved happily, so I’m free to go back on the road. We’ve thus rescheduled the events I was supposed to do last month in Texas. On February 23rd I’ll be speaking at DFW Scrum in Dallas. On February 25th ThoughtWorks is organizing a technology forum in Austin. As is usual for me, I haven’t planned exactly what I’ll talk about yet, but it’ll revolve around my usual topics of software design and agile methods.
Sriram http://www.blogger.com/profile/01237485664035584743 noreply@blogger.com :
When Agile Estimation becomes pointless
Last updated: 2010-02-05T03:24:16Z
If a team has to deliver a certain amount of functionality by a certain date, then the act of estimation becomes an act of commitment. The team has essentially committed to cost, schedule, quality and scope. There are no levers left. In such a situation, velocity becomes a target rather than just a measurement. Targeting velocity makes points based estimation a charade. The team is better off estimating in real days in this case. It helps the cause of commitment. Points based estimation is useful when you agree to the following: Plan the story list for a release with only about 70% must-have functionality and the rest as negotiable. This implies it is potentially okay to release (go into production) with just that 70% functionality. By definition, estimates are approximations. Software estimates are more so. It is counterproductive to insist that your IT vendor/team deliver x points of functionality by date y. Scope negotiation does not mean x remains x. Yes, sometimes only the contents of x need change. At other times, x may become x ± delta. This is not a rip-off. It doesn't make business sense for your IT vendor to rip you off because you won't give repeat business if you are ripped off. Without repeat business, your IT vendor is likely to become uncompetitive because the cost of new business development is very high. "Embrace change" is a two way street. IT delivery team should embrace changes to requirements and priorities. Clients should also embrace changes to scope when delivery work proceeds at a different pace than originally expected.blog home page
Last updated: 2010-02-04T20:42:00Z
Here's a common misconception about agile methods. It centers on the way user stories are created and flow through the development activity. The misconception is that the product owner (or business analysts) creates user stories and then put them in front of developers to implement. The notion is that this is a flow from product owner to development, with the product owner responsible for determining what needs to be done and the developers how to do it.A justification for this approach is that this separates the responsibilities along the lines of competence. The product owner knows the business, what the software is for, and thus what needs to be done. The developers know technology and know how to do things, so they can figure out how to realize the demands of the product owner.This notion of product owners coming up with DecreedStories is a profound misunderstanding of the way agile development should work. When we were brainstorming names at Snowbird, I remember Kent suggesting "conversational". This emphasized the fact that the heart of our thinking was of an on-going conversation between customers and developers about how a development project should proceed.In terms of coming up with stories, what this means is that they are always something to be refined through conversation - and that developers should play an active role in helping that definition.spotting inconsistencies and gaps between the storiesusing technical knowledge to come up with new stories that seem to fit the product owner's visionseeing alternative stories that would be cheaper to build given the technological landscapesplit stories to make them easier to plan or implementThis is the Negotiable principle in Bill Wake's INVEST test for stories. Any member of an agile team can create stories and suggest modifications. It may be that just a few members of a team gravitate to writing most of the stories. That's up to the team's self-organization as to how they want that to happen. But everyone should be engaged in coming up and refining stories. (This involvement is in addition to the develpers' responsibility to estimate stories.)The product owner does have a special responsibility. In the end the product owner is the final decider on stories, particularly their prioritization. This reflects the fact that the product owner should be the best person to judge that slippery attribute of business value. But having a final decision maker should never stop others from participating, and should not lead people astray into a decreed model of stories.
Last updated: 2010-02-02T10:42:25Z
On February 11th I’ll be presenting Hydras and Hypermedia at London Geek Night.
Do you know what your enterprise apps get up to in their time off? Fighting fantasy, pick-your-path, hypermedia-driven, RESTful Web application adventures – of course.
In this speculative dungeon delve I’ll show how we can use hypermedia-driven Web applications to model rich workflows. We’ll tackle the many-headed Hydra of HATEOAS, the “Hypermedia as the Engine of Application State” monster; level up through the Web services maturity heuristic; and meet the dwarves with grudges. On the way, we’ll learn how to model business processes as domain application protocols, implement them in terms of resource lifecycles, and advertise them using HTTP idioms, media types and link relation values.
- Event
- London Geek Night
- Description
- Hydras and Hypermedia
- Date
- 11th February
- Time
- 7 pm – 10 pm
- Location
-
ThoughtWorks UK Office Berkshire House 168-173 High Holborn London WC1V 7AA
Last updated: 2010-01-29T07:51:39Z
A collection of my favourite bits from Leading Lean Software Development: Results Are not the Point:"It is the overhead incurred to enable auditability that induces the waste, not the standards themselves.""Randomly giving patients medication until they get better would not even be considered. And yet, we randomly give our work processes medicine, adding on more and more 'best practices,' until the processes seem to get better.""A jishuken is a training exercise, not a problem solving exercise.""Which would you rather have, headcount constraints or big layoffs?""The advantage which a commander thinks he can attain through continued personal intervention is largely illusory. By engaging in it he assumes a task that really belongs to others, whose effectiveness he thus destroys. He also multiplies his own tasks to a point where he can longer fulfill the whole of them." (Helmuth Von Moltke)"When opinions are asked, the tradition in the military is to let the junior person (rank in this case) speak first." (Tom Stephen)"A budget will either prove roughly right, and then it will be trite, or it will be disastrously wrong, in which it will be dangerous. My conclusion is thus: Scrap it!" (Jan Wallander)"Management that is destructively critical when mistakes are made kills initiative." (William McKnight)
Last updated: 2010-01-29T03:27:14Z
In my previous
post, I mentioned how authors of small but useful open source projects often struggle for compensation. Using a FOSS/commercial license is one option but it could go either way. They wouldn't really have to resort to compulsory payment if donations were forthcoming from users/organizations who commercially benefit from it. Therein lies the tragedy of 'Commons based Peer Production'. Only a tiny minority donate. This is detrimental to the growth of all forms of free digitial distribution (indy music, books, software etc). It also makes for an unhealthy society. Big leap? Bear with me.
The bulk of financial transactions in G20 economies happen between:
- Corporations (B2B)
- Corporation and citizen (retail - citizens pays corporation, wages - corporation pays citizen)
- Corporation and state (taxes - corporation pays state, state funded projects - state pays corporation)
- Citizen and state (taxes - citizen pays state, pension/welfare - state pays citizen)
But what about transactions between citizens? When this goes towards zero, we get a unhealthy society. Centralized services, mostly helpless consumers (citizens). Donating money to the creators of 'digital stuff' that we enjoy is a great way of changing the status quo. The internet has provided a great platform for disintermediation but it will only work if we choose to participate in the process.
We could also try to build momentum within our organizations towards this. Companies that commercially benefit (however indirectly) from free software could set aside some money annually for donations. The beneficiaries could be decided by a poll within the company. After all, this is also part of CSR. Plus it will make for good PR copy.
Last updated: 2010-01-25T18:25:05Z
I guess we all know the difference between free as in speech (freedom) and free as in lunch (gratis). All open source software confer certain freedoms of use, modification and redistribution. None of them are required to be made available to users at zero cost. Yet, I don't know of a single significant project that is open source and fully paid, i.e. no version available at zero cost. Reasons typically offered are:
- It is the freemium business model - Give away the basic software and charge for enhanced functionality or support.
- It is not enforceable - Users will simply build the software from the source code and there is no way you can get them to pay.
I suspect payment is very enforcable against commercial enterprises. Just add a line to your EULA saying "It is illegal to use this software for commercial purposes without paying for it". Most companies would pay a small fee (say $50 for a full version but without support) for a useful piece of software. Either that or their lawyers would blacklist the software. At least you wouldn't have legions of freeloaders just using the software without contributing anything (money, bug reports/fixes, documentation) back. The argument that even freeloaders help spread the word to someone who might eventually buy something is a trifle bleak. Of course, all power to you if are doing this altruistically or if you are happy with the other rewards (fun, learning, reputation).
Giving software away at zero cost means you have to depend on services for income. You either offer your services as an employee (day job) or as support (adding value to what is given away). Either way, it is a model of pricing input instead of output. Scales only with people. Or you have to fall into a category where you can be adopted by a big foundation like Eclipse or Apache or Mozilla. Good luck with that.
Last updated: 2010-01-25T12:04:05Z
Agile software development is inherently democratic. Choice over Prescription could be included in the Agile manifesto. We give the customer the choice, the choice to decide what is most important to them, what will deliver the greatest value and build that first. We do not prescribe that they must build a complex framework first- the software will evolve, You ain’t gonna need it (Yagni) until you need it.
The problem with this democracy, with this unleashed choice is that, if you don’t have the right mix of stakeholders, the (agile project) customer doesn’t always know what is best. They are not always the best people to choose.
There is a difference between domain knowledge and what I’ll call ‘experience’ knowledge. A banker may know the banking domain inside and out, they can tell you the difference between all the different types of balance and how (and where) they are calculated; closing balance, running balance, etc. But unless they have done any research with customers, unless they have ‘experience knowledge’, when it comes to a question such as which balance to provide as an SMS alert, their ‘domain’ knowledge is as good as your common-sense.
Imagine software were a supermarket store. IT are responsible for the construction of the store, the basic layout, the signage, the checkout, the peripherals. The business are responsible for what goes into the store, the merchanising, the planogram. The business imperative is to fill the shelves and shift the product. They want to spend their money to this goal, anything that does not directly support this will be of lower priority. That is their domain and they will prioritise that over anything else. If they could fill the store with nothing but shelves they’d probably be happy.
Now imagine visiting the store. There’s no carpark, there are no shopping trolleys, there’s no emergency exits. There’s no ramp for disabled customers. The shelves rise to eight foot high (with no steps to reach the heights), the aisles are difficult to negotiate because of promotional displays between the shelves. The business is happy, but what about the customer?
In the agile world, nobody is going to pay attention to this stuff unless it is prioritised. “Sorry, we didn’t build any shopping trolleys because you prioritised building more shelf space over them”.
This sort of thing happens all the time; functional domain requirements trump experience requirements. Why? Because no-one brings experience knowledge into prioritization and planning sessions.
When stating their choice, your stakeholder wears a commercial hat, they are thinking about their targets and those are based upon shifting product. They are living in thier operational business domain. But cold commercials are not what shifts product. It is the experience that does. Now go back to the democracy of choice on an agile project. Who is the ‘business’ specifiying requirements? Is it a balanced team? Is their an experience champion with an equal voice? Is the voice of the customer recgognised? If not, isn’t about time you got an customer experience champion onto the team.
Last updated: 2010-01-25T11:08:47Z
We often cry ourselves hoarse trying to justify non-waterfall methods of software development saying that software is fundamentally different from manufacturing or civil construction. There is substance to this. Code is design. Compilation (build) is zero cost for all practical purposes. If we agree that compilation is the equivalent of a manufacturing assembly line or brick-laying, then the economics of software development are very different indeed. The economics of software make it particularly vulnerable to the ill-effects ot the current patent regime.
I used to find it surprising when highly credible
people said there was nothing fundamentally different about software patents - "If you're against software patents, you're against patents in general." Until I realized that software patents aren't inherently evil - the devil, as usual, lurks in the details.
Patents exist to balance competing objectives:
- Encourage innovation
- Give innovators a chance to profit from their success
- Improve the body of knowledge in the public domain (eventually)
In practice, the second objective is generally met by conferring a twenty year period of exclusive usage rights. Thus, patents are economic devices. Won't the efficacy of an economic device depend on the underlying economics of the industry it is meant for? Do all industries require twenty years to recoup investment and monetize an innovation? It certainly is ridiculous for software. Technology cycles keep getting shorter - twenty years is several generations in most industries today. A two year patent might be more reasonable for software. Of course, that still leaves jokes like the one-click-checkout patent untouched.
When patents were first conceived, they were meant for flesh and blood patent holders, not for mere legal persons (Corporations). Corporations gained personhood much later. However, the majority of patents today are held by corporations rather than individuals. This has lead to barely legal behaviors that end up stifling innovation in the industry as a whole.
What's really needed is a nimble international body that can tweak the terms of patenting for different industries. But then, international co-operation is hard to come by even for life threatening issues such as climate change. No wonder people push for elimination of software patents instead of push for a better patent regime.
