Archive for July, 2006
Quality (and the cutting of it) is something I’ve been thinking about a lot recently after transferring from a mature project onto a new one, with time pressures and little infrastructure to allow fast delivery of quality code.
At Agile 2006, Ken Schwaber talks about not allowing it to be sacrificed, emphasis mine.
At Agile2006, Co-founder of the Scrum methodology Ken Schwaber made a passionate case for maintaining software quality. Drawing examples of teams sacrificing testing, refactoring and other practices in order to meet deadlines, Ken argued that as professionals we should not accept business requests to sacrifice quality in order to meet timelines, and if quality does need to be sacrificed such a decision should be made by executive management and reflected in the financial statements of the company.
Ken’s message: Not compromising on quality is not only your professional obligation but it is also important for your own joy of work and is critical for the company.
There’s practically a holy consensus right now that the war in the North is a just war and that morality is on our side. The bitter truth must be said: this holy consensus is based on short-range selective memory, an introverted worldview, and double standards.
This war is not a just war. Israel is using excessive force without distinguishing between civilian population and enemy, whose sole purpose is extortion. That is not to say that morality and justice are on Hezbollah’s side. Most certainly not. But the fact that Hezbollah “started it” when it kidnapped soldiers from across an international border does not even begin to tilt the scales of justice toward our side.
Source: Morality is not on our side
In the current issue of Methods and Tools, an online magazine on software engineering related topics, Ian Evans of British Telecom reflects on how re-orienting a large IT organisation from a well-established waterfall-based delivery approach to a truly agile delivery style takes patience, time, and a lot of commitment.
In BT, where the initial steps towards enterprise agile delivery were taken in late 2004, there has been a noticeable and decisive shift away from waterfall-based thinking. It has also transformed, quite radically, the traditional function of the IT department as a supplier of IT services to one where IT is now seen as integral to all major business initiatives.
Evans reports that, above all else, it has created an attitude, bordering on obsession, of delivering real value to the business through IT.
Most likely you have been directed to this document because you have attempted to e-mail me a document in Microsoft Word format. I would like to explain to you why I am probably not able to access this document, why you should reconsider sending Word documents to people, and what better alternatives are available for document exchange over the Internet.
My reaction to that, as usual, was that a refactoring preserves behavior you care about. Then I thought, well, you should have a test for behavior you care about. (“If it’s not tested, it doesn’t work.”) That, then, is my new definition of refactoring: A refactoring is a test-preserving transformation.
A couple of good posts floating around about agile development practices. Starting with Programming as Typing, Product-Development Practices That Work: How Internet Companies Build Software, Characterizing people as non-linear, first-order components in software development. All in all nicely summarised in Measuring Practices!
I plan to have a lot more to say on this over the coming weeks, but a few links will do to start me off on a new blog, not a very auspicious way to start.
- Don’t test the methods of your classes
- Contract-Driven Development
- Contractual Test-Driven Development (DBC with TDD)
- Test-Driven Development vs Design By Contract and the follow-up More on TDD vs Design By Contract
- Test Driven Design vs. Design by ContractÃ¢â€žÂ¢
I will soon be moving my blog from it’s current location to a new one hosted from my main website. Stay tuned for more!