Today I had a new coworker tell me that I really couldn’t comment on his method of organizing source code because I hadn’t used it. It was guaranteed to produce the fantastic results he was talking about if only we’d just adopt it for all projects going forward. (He didn’t find it odd that even though this system was apparently very intuitive everyone kept asking the same questions over and over). But he’s missing the point completely. The problems on the particular project I’m working on are about the requirements.
I’ve been a software professional for 15 years now. In that time I’ve seen a lot of things and have tried a lot of things. I’ve been part of the newest fads in software development usually to see all of them fail. Why? Because the most important part of the equation is the customer knowing what they want and being able to communicate that in the form of requirements and in all but one case they haven’t been able to do that.
The most successful projects I’ve ever been involved with were *gasp* based on the waterfall method of software development. Well wait…how can that be? Doesn’t a project have to be “agile” to be successful? Of course that’s tongue-in-cheek but based on what I’ve read projects can’t be successful using that methodology. But they were and why were they? It had nothing to do with the methodology at all, it was all about having good requirements. We came up with good requirements by spending a hell of a lot of time with the clients. First finding out what they needed. Then spending even more time working with screen mock-ups in the meetings. Then finally showing a real prototype to make sure we were all on the same page. We then threw that prototype out and started coding. (We also had a designated note-taker so we could keep a record of what was agreed to).
I have not had the pleasure of using that system since (this was 1996-98). Since then any project I’ve been involved with has had problems because of lack of good requirements and requirements gathering. That stuff takes a lot of time. It takes interaction between the software people and the clients. There has to be a record of what was agreed to and people can’t just keep changing their mind as the winds change direction. It has absolutely nothing to do with the rest of the development methodolgy.
Getting back to my new coworker… While his code organizing ideas have some merit the organization of our codebase isn’t the problem. Someone can learn what goes where very quickly. On a larger scale code organization still isn’t the problem. The problem, once again, is requirements. We just aren’t getting good requirements and nobody is writing anything down to the point we can come to agreement on things. Changing the organization of the code isn’t going to fix that problem. He even insists that it can help but I don’t see quite how organizing code around business concerns is going to make people come to a consensus on exactly what is supposed to be built. Until that happens everything else is almost a moot point.