My favourite idea from Extreme Programming is that you should not run your imagination wild and try to conjure future requirements from a chrystal ball. Instead, you should design and write something lightweight that works for current requirements and refactor it later, if needed.
Why have I grown fond of this philosophy? Wouldn’t it be easier to implement those future features if they have already been taken into account? Maybe, in theory. But along the way, I have seen enough really bad code (oops, some of it written by me) that tries to fulfill some needs that were imagined to be worthy one day. Of course, requirements changed as they always do (unless you work in some dreamy place with thick forests and a nice waterfalls), and the feature was never fully implemented. Often, the feature had never even made it into the requirements list.
As the application doesn’t really support the anticipated feature, it is confusing to read and hard to understand such code. Since the feature was not needed at the time, the feature was not thoroughly tested, so there are inevitably some bugs that might even hinder useful parts of the code. And since some later changes have not taken into account the fancy feature-ought-to-be, the code has become stale so awfully that it would be much easier to design the feature from scratch anyway.
Of course, as any useful idea, this practice has its limitations. For an intended public API, you’ll want to get as much of naming, structure and scope nailed down as possible before considering the work done. Any reorganizing you’d want to introduce after publication would break applications that have already been written against your API. That would eat up your API’s trust quota quite fast. You’ll need at least three applications experimentally using your API before you can consider it generic enough for wider use.
Entry Filed under: Handling Uncertainty
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Sep | ||||||
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | |||||
6 Comments Add your own
1. Sigmar | October 9th, 2006 at 14:58
I think that the motivation for this article here came from Villu and ME
, because I am one of these guys who like to make something for everything. And Villu is also making suggestions to make something for everything. Ok, I understand this what Imre tries to tell here. So, programmer should just understand, what is he(or she) doing at the moment: just adding or improving functionality or developing a framework or building an architecture:), and if he doesnt really understand it, then it’s boss’s job to point on it:)
2. Manuel Chromatic Mayflower | October 9th, 2006 at 15:29
Well, why don’t you just label the public API as “provisional” and let your customers decide whether they want to depend on it today or not? If your heavily data-centric application can’t bear a public API after two-three years of development, you’re misguided anyways.
3. Imre Lumiste | October 9th, 2006 at 16:51
Sigmar:
this article was not meant to be anything personal, although yes, it has been inspired by some recent conversations.
Manuel:
any development decision should be justified by some business need. Our customers have the option to vote for having a public API by requesting for it. For some reason, they haven’t done it. Perhaps it’s because they have their own software to deliver. Or perhaps they trust us to deliver working solutions. As long as they don’t give us any requirements, how would we know what they need?
Designing, implementing, documenting, testing and maintaining a public API is a tremendous effort that requires development resources on expense of all the other features that our customers actually want.
So far, we have provided most API features that have been asked for; there are a couple of requests waiting in line exactly because there are other features that seem to be even more useful for our users.
4. Karel Kravik | October 9th, 2006 at 19:00
I’ve long ago trying to say (see the previous posts): “every feature you have means some other feature left out”.
5. Manuel Chromatic Mayflower | October 16th, 2006 at 13:32
Public API cannot be regarded as “any other feature”. It’s the backbone of your app and thus will always have at least one paying and highly participant customer - you yourself.
6. Imre Lumiste | October 16th, 2006 at 14:42
Why should the internal backbone be public? The difference between public and private interface is huge in terms of flexibility, cost and need for documentation. Thus, making the API public still counts as a feature to me.
Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
Trackback this post | Subscribe to the comments via RSS Feed