Community Blogs

In church last week we were talking about evolution when the term "Irreducible Complexity" came up.  For those who aren't familiar with the concept irreducible complexity is a term coined by Michael Behe to illustrate that complex system could not have evolved and therefore must have been created intelligently.  Behe defines irreducible complexity as: A single system which is composed of several interacting parts that contribute to the basic function, and where the removal of any one of the parts causes the system to effectively cease functioning. ( Darwin's Black Box p39 in the 2006 edition) In his book Behe uses a mousetrap to illustrate an irreducible complex system.  "If any one of the components of...

A little earlier today I found myself explaining Aggregate Roots and Anemic Domain Models to a couple of developers hre, and I wished I had my copy of Domain Driven Design to hand to show them what I was explaining ... then I remembered that InfoQ published an *excellent* online book called " Domain Driven Design Quickly " - free to download, or you can buy the printed version. This book is a perfect introduction to DDD, and as it is free, you cannot really beat if for value for money! From the introduction: The most complicated aspect of large software projects is not the implementation, it is the real world domain that the software serves. Domain Driven Design is a vision and approach for dealing with highly complex domains that...

Some software approaches run in cycles Gather requirements (sometimes) Write Code Test code (sometimes) Get the requirements wrong and the requirements change midway through writing the code and your writing more code or changing code and the time scale goes up (yes even if the deadline is unmoveable the coders still have to work more hours). Worse yet they change at the testing level and it means more code and yet more testing. Expensive and time consuming when you could use all that to deliver sooner and more to your customer. Let’s say the cycle takes 6 weeks, 2 weeks in each stage. On week 3 the customer asks you where you are and you either make them wait 2 weeks more or give them an incomplete version. They then ask for this, that and...

Martin Woodward has a great article on software estimation, why it is hard and what Agile brings to the table . The approach I have seen the most in the past is the grand old FITA analysis (Finger in The Air) estimate. Get it right and your on time, get it wrong all hell breaks loose (most of which cost money e.g the cost of late delivery, the cost of extra development etc). If the coders finish early then chances are Parkinsons law applies and still costs you. Projects even fail completely or the customer walks away never to be seen again, software estimation should be science and not an art, but that's what it is. If you have not read the Agile Planning and Estimation book then you should, much of what I am going to talk about here is...

We've rolled out Kanban at my company Xclaim Software. Prior to this we were following a more-or-less XP process evolved and tweaked over some two years. Even though our team has been doing the Agile thing with good results, there are times that the process seems a little opaque and wasteful. I've noticed that it's hard to surface where we're encountering bottlenecks or impediments. Planning and maintaining a large inventory of backlog creates waste; planning can take several hours for large batches of new stories and, while I think there's good value in preparing a as-full-as-possible backlog at the beginning of a project, I see very little value in maintaining a backlog over three months at a maximum. There's simply...

Cory has a great post titled: Scrum-ban | Lean Software Engineering. In it he describes how a team can take advantage of kanban within a Scrum environment. While I am sure that there will be those who insist that Scrum doesn't need to be improved, there are those of us who learned Scrum, practiced Scrum and are aware of it's limitations and want our teams to get even better. Personally I like kanban for the context I work in . When I explain how we develop software I always try to make sure the other person is aware of the context I made my decisions in and how in other contexts I would not make the same decision. For instance we do not estimate each individual story (although for a short period we did 30 second estimating ). We have...

Here's a conversation I just had with another developer who is struggling to get his team to adopt some agile practices: developer : if you were starting from scratch, which would you think is more important to setup first? CI or a unit testing process? me : unit testing developer : wow developer :  ok me : why is that surprising? developer : i look at the mess i'm in everyday and i'd think getting a good build system in place would be first... me : I think unit testing provides more value in that it allows you to add features knowing you haven't broken other features developer : testing above a development process? me : yes me : testing provides more customer value Let me be clear in stating that I think both are great...

A long while ago I got a licence for NDepend ... I had used it previously but only on the trial version, where it had proved very useful in giving me a some pretty graphs that made sense to managment when my words did not. I haven't actually got around to using it until this morning, when I thought I would run it over our current project to see where we were at. There isn't a hell of a lot of code in the project, so I wasn't expecting too many surprises - and largely I didn't receive many. I was pleased to see our assembly dependencies were the right way around, and very pleased to see they were very near the centre line on the "Abstractness vs Instability" chart. The only very mild surprise was to see this flagged...

When I first graduated from college I worked on embedded systems where the process was a formal, military grade process.  When developing software I typically thought about what document I had to write next and what document(s) I may be missing.  In general, the MIL standards turned me off a bit to process, and for awhile left me thinking that process is an obstruction to true development.  As a 21 year old, you think code = development.  That was/is an immature point of view, but it was not a viewpoint that I was easily dissuaded from.  Further it's a point of view that many out there still hold dear, and not all who hold that view are recent college graduates. Recently a small group of us decided to give Scrum...

Brad Wilson mentioned on the TDD mailing list that the waste and inefficiency within the software industry was akin to the house building industry. I'm sure in some respects he is right, but in a more fundamental way I disagree. An average layman off the street hiring a builder can ask them to build a wall. The average layman can see if the wall isn't straight, the average layman can see when bricks are not aligned, they can see when a house is built to a high quality finish, where attention has been paid to detail. They may not be able to see if the builder has been deceitful by using substandard materials or hiding shortcuts, but a few hundred pounds to a surveyor will tell them all they need to know. Even the most technical of software...