in Search

Do you Twitter? Follow us @devlicious

Casey Charlton - Insane World

Hang the code, and hang the rules. They're more like guidelines anyway

How to Make Late Software, Even Later

I'll start by quoting Brooks Law, as no doubt you expect me to:

Brooks's law is a principle in software development which says that "adding manpower to a late software project makes it later". It was coined by Fred Brooks in his 1975 book The Mythical Man-Month

The truth of this is blatantly obvious to anyone who has ever been involved in a project that was slipping its schedule. It is so blatantly obvious that The Mythical Man-Month is almost legendary in development circles largely due to that one brilliant observation.

Segmentation

The often suggested way to avoid Brook's Law biting your backside when you are faced with a project that is rapidly disappearing into the future is around segmentation, breaking your project into manageable chunks that can be developed in isolation. Teams can then take these chunks and develop while a core team is repsonsible for integration of their work. As Wikipedia correctly points out, when the segmentation is done poorly this can actually increase the time to deliver the project even more than just filling a single room with more developers - preventing developers on separate teams interacting easily, when they are actually working on common code is a near catastrophic mistake.

And now to my real point, correct segmentation can only work when there is a clear and clean architecture underlying the system upon which new developers and teams can easily add new functionality in complete and total isolation from each other, whilst still maintaining the integrity of the system.

One Common Vision

The architecture or framework is important in any project, it provides the one common point of reference that all developers have, a project can succeed or fail based solely on getting this part of the project right. Without this in place, all development work on the project is in real danger of producing an inconsistent and incohherent system, that at best will meet the majority of the business requirements but be totally unmaintainable over a period of time - a greenfield legacy system.

In a large project with multiple developers, and potentially multiple teams, the architecture is critical to the project success. Without this common vision teams will start going off at tangents, will duplicate work, and will spend more time trying to get their code to work nicely with their colleague's code than they ever will providing real business functionality.

And then Brook's Law not only hits you up the backside, it reverses back over you a few times just to be sure you are really suffering. Project managers, in a way that only project managers could do, ask for more developers to help integrate the code, and your descent into hell has begun.

Conclusion

So, if you do nothing else right on a project, get the fundamental architecture and framework right, early. Get a walking skeleton of all critical functionality running early against this architecture to prove it is right, and then ask the business to validate it. You will be amazed how much easier this will make things in the long run.

Published May 08 2008, 08:39 AM by Casey Charlton

Filed under: Practices and Principles, Rants, Architecture

Comments

Dew Drop - May 8, 2008 | Alvin Ashcraft's Morning Dew said:

Pingback from Dew Drop - May 8, 2008 | Alvin Ashcraft's Morning Dew

# May 8, 2008 9:15 AM

Neil Weber said:

In my experience, projects using an Agile methodology have a very poor architecture and no architectural vision. And definitely no framework because "you are not going to need it." Combining my experience and your post on the importance of architecture, we would come to the conclusion that Agile should not be used in a project. Your thoughts?

# May 8, 2008 12:11 PM

Casey said:

I would suggest that your experience is of places claiming to be Agile, but not understanding what it means, let alone having good experience with an Agile methodology.

Agile methodologies do not state no up front design, they specify as much as is required, and that varies by project.

And an architecture or framework is the perfect candidate to be developed in an Agile fashion, as it is the part of the application that is most critical, and the part with the most unanswered questions.

# May 8, 2008 12:37 PM

jdn said:

Yeah, but that's the common argument. If an Agile project doesn't succeed, then it means you didn't do it right.

Well, if most 'Agile' projects fail, then it doesn't really matter if it was 'really' Agile or not.

Yegge had this pegged exactly.

# May 8, 2008 1:31 PM

Casey Charlton said:

Do most Agile projects fail? Most waterfall projects do for sure ... most chaotic hack and slash ones do too ... any evidence on the Agile front?

Out of at least 7 clients I have worked for who claim to be doing Agile, only 1 was doing anything close to properly following a methodology (XP in their case), the others were really just hacking and calling it Agile to please the management.

My current client has a number of projects, and the only ones that have succeeded are Agile, true Agile (XP again). The projects not under Agile are in a state of distress.

# May 8, 2008 1:58 PM

jdn said:

If a methodology is such that only 1 out of 7 clients claiming to use it aren't actually using it, then that says something about the methodology.

And, there's the whole issue of Confirmation Bias.

# May 8, 2008 2:39 PM

Neil Weber said:

I gotta agree with jdn. If an Agile project fails, then the Agile community disowns it. That's a great way to jiggle the statistics.

It is true that we didn't follow everything described in the Extreme Programming book. For both Agile projects I worked on, we couldn't. On neither project was there a clear design vision and we didn't have somebody representing the business on hand at all times to answer questions. Even when they were available, they couldn't answer our questions. Maybe somebody would say that we shouldn't have been using Agile given the limitations. If so then very few projects I've ever worked on would be eligible for the Agile methodologies. The drum banging from the Agile community certainly doesn't help in deciding when to use Agile and when not -- it's always "use Agile, use Agile, use Agile."

In any case, you didn't address my original question. Have you worked on successful Agile projects that have had good architectures? If so, how much up front design was performed? When does an Agile process become a plain ol' iterative development process circa '95?

# May 8, 2008 3:03 PM

Casey Charlton said:

The projects you described really shouldn;t have been done as Agile ... no business owner to deal with on a daily basis is a guaranteed way tostuff up any Agile methodology. I must have spoken to a business person at least 10 different times today alone ... that person *is* your project. Without them you are open to going off on flights of fancy, and digging yourself into deep deep holes.

Insist to the business they give you either a full and detailed set of requirements (in which case they get what they asked for), or a business representative with a good proportion of their time allocated to the project. Failing one of those two, refuse to start the project, or start it with a massive highlighted risk to the management that the project may fail due to insufficient requirements and lack of business involvement.

>>>vIn any case, you didn't address my original question. Have you worked on successful Agile projects that have had good architectures? If so, how much up front design was performed? When does an Agile process become a plain ol' iterative development process circa '95?<<<

I have worked on successful Agile projects, have worked on unsuccessful (every type) projects... and the first and foremost thing I do on any project is make sure the architecture and framework is right. Business functionality comes afterwards.

The other way around is a recipe for disaster, Agile or not.

# May 8, 2008 3:17 PM

Casey Charlton - Insane World said:

Prompted partially by some comments yesterday on my post on How to Make Late Software, Even Later , and

# May 9, 2008 3:30 AM

Grimbeorn said:

I have to comment on the point of teams claiming to use Agile processes but not really doing it. In my experience, this doesn't say nearly as much about the process as it does about management.

I have worked for numerous places where management has said, "You must use XYZ technology/methodology/(insert the latest buzword here), without any idea what it is or its potential drawbacks, and no real support to make it happen. Then it's up to the underlings who have been given this mandate to figure out how to do it on their own because they've been "told to.". Usually, since none of them are familiar with it, they do something that kind of looks like what management asked for and then tells them, "Yes, we're now doing XYZ," just to keep them of their backs.

# May 9, 2008 10:56 AM