tag:blogger.com,1999:blog-77521382011-04-22T01:19:42.452+01:00Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.comBlogger161100tag:blogger.com,1999:blog-7752138.post-49106681052257633222008-06-22T06:03:00.003+01:002008-06-22T07:29:29.372+01:00

My last 5 or 6 Agile projects have involved non-trivial architectures.  By this I mean that they've been more than a browser, application server, and a database.  While I would urge all people with architectural responsibility to avoid complexity, sometimes it's not feasible to simplify the architecture prior to first release. For the record, there are several reasons why complex architectures

Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.com1tag:blogger.com,1999:blog-7752138.post-59132008855424113212008-04-27T09:40:00.002+01:002008-04-27T10:30:09.553+01:00

In an agile/lean software development team, discussion is invited, but coordinated.  I've noticed that people who are passionate about technology or process often feel friction if they don't get a good hearing for their idea.  Equally, the technical/process leadership have to help everyone on a team achieve consistency.  Regardless, there should be no "status quo"...I've been playing around with

Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.com0tag:blogger.com,1999:blog-7752138.post-72727640109433729662007-05-21T23:37:00.000+01:002007-05-22T00:02:54.661+01:00

A few bits of language related to enterprise deployment - someone send me some references, there are probably other, better, names for this:The differences between "green/blue" and "silver/gold" are subtle, and should probably be generalised. Green-blue domainsCompletely parallel, independent, and symmetric hardware instances at all tiers of an application, only one of which is live at any time.

Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.com0tag:blogger.com,1999:blog-7752138.post-33231398034385004762007-02-27T22:58:00.000Z2007-02-28T07:09:03.601Z

Having spent some actual time on a Java based multi-threaded project, I want to reflect.My reflection is: Don't ever use Java's concurrency libraries in an agile project. At a high level this is for several reasons:People find multi-threading difficult to understand. If you have a learn a bunch of things on a project, things like this generate fear, and push it into the little group of "people

Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.com8tag:blogger.com,1999:blog-7752138.post-7009141234980614242007-02-14T09:20:00.000Z2007-02-14T11:30:57.987Z

Thanks to Jeremy Ruston for this - it started as a drunken conversation about 4 years ago, developed through a couple of years of casual use in a professional environment, and now I use it for a variety of reasons:* Explaining why product companies are bad for business users with specific requirements* Understanding emotional commitment to technology within IT departments* Structuring code-base

Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.com0tag:blogger.com,1999:blog-7752138.post-1149553186443189922006-06-06T00:33:00.000+01:002006-06-17T21:16:25.016+01:00

There a moment on a good project team where everything clicks. All the egos are in harmony, no-one's being polite anymore, and you can just feel the team purr. As a team lead, there are few ways of achieving vicarious satisfaction than helping a team sustain a productive pace.This happened a month or so go on my previous project - and it kept on getting better. Something special happened, and I'm

Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.com0tag:blogger.com,1999:blog-7752138.post-1149369309239395512006-06-03T21:31:00.000+01:002006-06-13T14:00:37.900+01:00

Here I am now, coming to the end of a phase of am agile project. The following conversation occurs:"Dude", (for it was he), "How does this software work?"."Well...", and then we stand in a room talking until their brains bleed, and farting until everyone has left the room.Agile documentation is light on the ground. We leave tests and a build server, and all sorts of other goodies around to help

Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.com0tag:blogger.com,1999:blog-7752138.post-1142599099213161442006-03-17T12:12:00.000Z2006-04-30T00:16:36.520+01:00

We're been going through the review process here recently. It's been my first time as a reviewer rather than reviewee, so was wondering how to approach it. With my reviewee's permission, I tried running it like a personal retrospective, with the following results.Apparatus (Are you liking this GCSE approach to science?) All the review feedback from colleagues, sponsors, and reports for the

Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.com0tag:blogger.com,1999:blog-7752138.post-1119344128095315132005-06-21T09:34:00.000+01:002005-06-21T09:55:28.103+01:00

I've started reading Hagakure, penned by Yamamoto Tsunetomo in the late 17th Century. These quotes strike me as being appropriate to my current situation, and to consultancy in general. It should be interesting to compare consultancy (particularly with Agile) with the Way of the Samurai - albeit from a time when warrior samurai are long since gone. Anyway, here's the first: To give a person

Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.com4tag:blogger.com,1999:blog-7752138.post-1101470449602733172004-11-26T11:33:00.000Z2004-11-26T16:56:34.656Z

My current fascination with support (and incorporating Agile approaches into support processes), suddenly chimed with the MPS system (from JetBrains) that Martin Fowler was talking about. The basic unit of business value is the Story. Stories are written for all functionality, but they can also be used for issue reporting. The process by which a defect is reported can often be poorly

Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.com1tag:blogger.com,1999:blog-7752138.post-1101393467155050482004-11-25T14:25:00.000Z2005-09-08T10:37:13.816+01:00

Nouns...A military operation (often involving new supplies of men and materiel) to strengthen a military force or aid in the performance of its mission (Example: "They called for artillery support")The act of bearing the weight of or strengthening (Example: "He leaned against the wall for support")Aiding the cause or policy or interests of (Example: "The president no longer had the support of his

Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.com5tag:blogger.com,1999:blog-7752138.post-1092317782522377632004-08-12T14:03:00.000+01:002004-11-26T17:19:26.706Z

Object orientation has been a fantastic tool for developers over the past 20 years. While it is not the only paradigm that helps create quality software, it is extremely good at managing complexity. The fundamental part of object orientation is to stop thinking about procedures (e.g. transformation of data), and instead think about discrete objects that send and receieve messages to and from

Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.com0tag:blogger.com,1999:blog-7752138.post-1090879439623443012004-07-26T22:30:00.000+01:002004-07-26T23:09:56.240+01:00

Clustering is remarkably, almost trivially, easy. There is a current Linux distro called ClusterKnoppix that combines Knoppix and OpenMosix.  Knoppix is what is known as single system image distribution:  a whole operating system that runs from CD, and uses a RamDisk as a read/write file system.  OpenMosix is a load balancing extension to the Linux kernel and provides a transparent mechanism for

Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.com0tag:blogger.com,1999:blog-7752138.post-1090876333183321712004-07-26T21:57:00.000+01:002004-07-26T22:26:56.793+01:00

My current project has an agile mind-set, but a slow development process. The overhead of picking up a CR, checking out, testing, checking-in, integrating, and deploying build is currently getting up towards the 3 hour mark. This is a fixed overhead associated with any development work, not including the actual engineering effort of implementing a change request. This overhead can be divided

Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.com0tag:blogger.com,1999:blog-7752138.post-1090869856763034862004-07-26T20:21:00.000+01:002004-07-26T21:55:10.230+01:00

Last night, I tried to explain to L (an architect) what this "Chaos Theory" thang is.  She's doing a thesis on the "Tectonics of Smoke", and has been asked to actually try and understand the physics/maths behind how smoke behaves.  Not a particularly easy subject... Still, she pulled out an old book of mine: Chaos by James Gleick.  God knows what I'd have done with out it, if only for the

Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.com0tag:blogger.com,1999:blog-7752138.post-1090858947193043952004-07-26T13:18:00.000+01:002004-07-26T21:54:42.976+01:00

This blog will contain random thoughts on things of a generally geeky nature - pseudo science, software development, technology, and maybe a few kittens. This morning there was a discussion on the radio of the rivalry between Newton and Leibniz over calculus.  Newton discovered it first, but kept it to himself.  Leibniz discovered it later, and had a much more effective notation.  They warred

Nick Drewhttp://www.blogger.com/profile/05637923998145449126noreply@blogger.com0