Kent Beck on incremental degradation (“defactoring”) as a design tool

Thanks to @AdamWhittingham for pointing out a great post from Kent Beck in which he suggests an “if you can’t make it better, make it worse” approach to incremental development. This is a habit that has been a part of my development process for a long while, and I have needed to explain it to …

Continue reading ‘Kent Beck on incremental degradation (“defactoring”) as a design tool’ »

REST and versioning, a more concrete example.

There’s an interesting discussion going on at The Wisdom of Ganesh in which Ganesh Prasad and “Integral ):( Reporting” (presumably the “JJ Dubray” mentioned in the article) are trying to work out some issues around versioning, REST and SOAP. This post is also referenced and commented on at infoQ. In the 14th comment to the …

Continue reading ‘REST and versioning, a more concrete example.’ »

Distributed Source Control as a tool for Set-Based Design

I’m currently spending a fair amount of time on evaluating distributed version control systems (DVCS) such as git, bazaar and mercurial. Some things which were easy using a centralized version control system such as subversion or cvs seem more complicated, but I am now starting to find ways of using DVCS to do things which …

Continue reading ‘Distributed Source Control as a tool for Set-Based Design’ »

What Is a Service?

Sometimes in software development it seems that everything is turning into a “service”. For diagram-loving architects, decribing everything in terms of services is a great way to avoid getting involved in fiddly implementation detail. The trouble with this approach is that hiding everything behind services can lead to thoroughly de-optimised systems. Greater hardware needs, greater …

Continue reading ‘What Is a Service?’ »

YAGNI: Some thoughts

YAGNI – it’s a neat term for a valuable technique. Ignoring an unknown future to concentrate on a known present. That does not mean that it’s application is obvious, though. I often find myself in “discussions” with architects and designers who recoil at the idea of building something specific to one customer or situation, when …

Continue reading ‘YAGNI: Some thoughts’ »

A structured way to work with user stories

For someone steeped in the traditional idea of requirements and features, working with agile user stories is often hard to handle. I have invested a lot of time over recent months attempting to build a good understanding of what a user story is, and how it differs from a feature, a change or a requirement. …

Continue reading ‘A structured way to work with user stories’ »