The suggested answer to the mentioned logging problem is to log asynchronously (which is a very good one, let's be clear on that). That's fine, but by the time you do design your way out for all functional and non-functional aspects of even a medium sized system, chances are you'll have bled the customer dry thanks to futureproofing and still they won't have what they need today. Assuming of course that your guesses worked out to be right.
This can be true, and in my experience it often is. Heck, I've been guilty of it. So I understand the problem.
But in between these two extremes is a middle ground of designing for flexibility. Building an async log for its own sake may well have been overkill for the immediate requirements, but the decoupling of log producer from log consumer, and use of a flexible transport, means that a wide variety of unseen futures are made simpler.
So my admittedly narrow reading of Glenn's entry is that he has a narrow reading of what XP is offering. ... there's a whole school of thought within XP of programming towards patterns (known solutions), that has not been mentioned or critiqued here.
That's fair. Certainly my comments were a narrow treatment. I too think there is a fair amount to learn from XP, and some XP thought applied with discretion very much helps some projects. It is just that I cringe when I read "develop the minimum" regurgitated without the surrounding thought, as I happened to do yesterday morning. The logging example was straight from that source. But perhaps I was guilty of the opposite sin. Mea culpa.
No comments:
Post a Comment