Back in ancient times (1968), Datamation published an interesting article by Mel Conway that made the following observation: “The structure of a system tends to mirror the structure of the group producing it.”
Now known as “Conway’s Law,” this seemingly simple sentence has a lot of ramifications, especially in a company that’s trying to move to Java and OO Design from a procedural environment (and most C++ shops are procedural — simply writing a program in C++ doesn’t make it OO). If the system’s structure mirrors that of the group, and if you radically change the structure of your systems, then you’ll expect the structure of the group to change as well. Changing the structure of a company in order to provide support for OO is a big deal.
For example, almost all OO methodologies nowadays are based on formal use-case analysis. (A use case, or XP “story card,” is some task performed by the user that will have a useful outcome — logging on is not a use case because there’s no useful outcome; balancing my checkbook is a use case.) The first step in this process is typically a formal “problem statement” that describes the problem the user is trying to solve. Both of these documents are best generated by the part of the company that has closest contact to the actual user community (marketing, not sales), working full time with at least one or two engineers. If you really intend to use OO at the programming level, you have to retrain your marketing department to produce the sorts of documents that the programmers actually need. Traditional “requirements” documents, or lists of new features, are simply not useful to an OO designer.
Another example: most workable OO processes require a tight relationship between testing and coding. Both activities happen within a single development group, ideally with a one-to-one tester-to-programmer ratio. Moreover, the testers have to be skilled programmers. (In many organizations, programmers bounce back and forth between the “tester” role and the “programmer” roll.) If your company has a giant QA department, a change is required. The director of QA isn’t going to be very happy when told that 90 percent of the department is going to be dispersed amongst the development teams, though.
Finally, there’s programmer resistance (which is really why I’m talking about this subject at all — I just experienced this resistance big time while trying to teach a design class in house). Somebody who’s been doing procedural programming for fifteen years, and is comfortable in the procedural rut, won’t be rooting for big changes. It’s both too scary and too leveling. The former guru is now learning a new process from scratch, without regard to the pecking order. What if it turns out that he or she isn’t any good at it?
The first two examples require strong executive-level support. Otherwise the support organizations needed to bring out the full promise of OO and Java simply won’t exist. I’ll even go out on a limb and say that the company who doesn’t have a strong, committed CTO or VPE, who works as a peer with the CEO and VP of Marketing, hasn’t a chance of making the change successfully.
The programmer-resistance problem is tougher still, since there are always reasonable-seeming arguments to resist the change. For example, the million-lines-of-legacy-code excuse: “We have a million lines of legacy spaghetti code into which we have to integrate new features. The task of adding OO is simply impossible; we’d have to refactor the whole program.” Not stated is the fact that if you have a million lines of spaghetti code, you’re already in deep trouble, and the odds of keeping that system going without enormous unnecessary expense are effectively zero. Also not stated is that the same refactoring that you’d use to restructure the spaghetti code into a decent procedural program can also be used to restructure it into a decent OO program.
But don’t despair. If the executives are all for it (or don’t even know that OO is a possibility, but could be convinced to do a small pilot project), and the bad middle managers are resisting OO (I guarantee no good manager is going to reject out of hand any technique that actually improves productivity), then you, the lowly grunt programmer, have power. Send email around the bad guys, straight to the CEO if necessary, through an anonymizer. Just send it. If you need a design room where there are 400 square feet of whiteboard that won’t be erased for months on end, and you can’t permanently co-opt a conference room, get a power screwdriver and get rid of some cubes (they come apart in about five minutes). Sign petitions, rouse the rabble, pass the hat to hire a consultant to come in and talk to your CEO for a day. Workers of the world unite! All right, I’m getting a bit carried away, but you get the idea. The programmers at the bottom can effect change if they put some energy into the process.
Java is a good language, but you can’t program Java effectively without OO, and you can’t do OO without making some significant changes. It’s just that simple.
Allen Holub
Senior Editor