No BDUF != NoDUF

Continuing with the theme of architecture in an agile organization, one of the most abused principles in agile software development is that of avoiding Big Design Up Front (BDUF).

No BDUF does not mean NoDUF!

NoBDUF != NoDUF

I submit that every single one of us is guilty of designing a solution to a problem before the person is finished describing what the problem is! Anybody with a modicum of imagination does design up front (DUF). In my experience, the amount of ceremony required for DUF is directly proportional to the cost-to-fix/cost-of-failure. This is pretty obvious in the construction of physical objects, and the debt is tangible. I don't think it's unreasonable to apply the same rule of thumb to software or virtual objects.

Architecture In An Agile Organization

Last night, my colleague Chris Sterling gave a presentation about Architecture In An Agile Organization. He raised several points I want to develop over the next few posts.

One of the most abused principles in agile software development is that of avoiding Big Design Up Front (BDUF). No BDUF does not mean NoDUF!

Architects are usually quite pre-occupied with ensuring that architectural guidelines and requirements are adhered to during development yet, always struggle to justify them. What does the customer think non-functional requirements mean? No, it's not just semantics.

Architecture is not all about technology. I'm going to start calling this the Paint Yourself Into The Corner pattern. You read it here, first.

Requirements are not specifications. Seriously, there is a difference!

Re-cycle the box

I was in a meeting with a client a while back along with several other consultants from different companies. Once again, the client was having a problem with their databases (of course!). They had several of each: SQL Server, DB2 and Oracle.

I'm rapidly forming the opinion that any consultant who concentrates on Oracle is nothing more than a corporate shill for Oracle. It seems that almost every solution they have to a database problem is to add another database, thereby increasing license fees for the client. Is there some grand, kick-back scheme or something that Oracle consultants get looped into? At least the people representing IBM and Microsoft product lines suggested investigating other solutions ranging from ETL software to messaging to web services. The Oracle guys went right for the throat and declared that yet another intermediate "consolidation" database instance was the answer. What a crock.

I looked across the table at the CIO and said, "If you are truly serious about solving your integration problem, get rid of one of your database platforms. Let them all know that the two who work together best get to stay." I also reminded him that the company owned all the tools they needed to solve the problem so, capital costs should be 0. I'm not sure if he is going to follow that strategy over the long term but, I certainly know that my suggestion kick-started some very, very creative and resourceful thinking amongst the other 3 groups of consultants!