Exacerbating this issue is the fact that these granola eating companies were not the ones generating the standard methodologies. The methodologies were, and still are in too many cases, created by the large systems integrator companies that populate the DC metro region: beltway bandits. They have the contracts that establish and revise the methodologies (EA) that agencies should use; changing this dynamic to de-emphasize documentation and focus on working software has been root-canal slow.
Here is my golden rule on this issue. If documentation doesn’t add value to what you are actually doing, then don’t fricking do it. You need to get enough documentation to be able to maintain the application if you get a new developer. Think of documentation as an insurance policy that you use when you switch horses. My rule was that if you do development, you don’t do maintenance and vice versa. Thus if I have Company A do the development and Company B do the maintenance after it goes to the production environment, Company B will be pushing you to push on Company A for the things that are important in getting a complete understanding.
Also, the documentation from the developer should be considered as DRAFT until you get to final pre-deployment testing. Prior to that point, it can be less than pristine, and I won’t care. So they can update it willy nilly and I will not ding them on it being bad.
Customer collaboration over contract negotiation
There was a school of thought, and I was just as guilty of this as anyone else, that said that people who write code, developers, can’t or shouldn’t interface with the business or mission people. The idea was that there is a group of people between the business or mission people and the developers, and these people translate the business processes into the language that developers can then build and code.
To be fair, this happened because both sides were wrong. The developer community didn’t help themselves in the dot-com days with the Birkenstocks, Grateful Dead T-shirts, Mountain Dew and poor hygiene. The business and mission side didn’t help themselves by thinking that an application can be designed by sitting in for portions of four one-hour sessions. As a result, the developer community had to learn some decorum and the business people had to learn to make an actual commitment of time.
That is what the agile manifesto group was reacting to, though they were probably wearing Birkenstocks when they got home from Utah. That a group of people would try to translate for one side and the other was and continues to be a problem. We lose too much in the translation. We don’t need to award a contract to bring in a bunch of consultants and analysts to tell us what the business processes are. The people who know the business process are the people who are running the business. Instead of bringing in some outsiders to learn the business, let’s prioritize this work so that some of the business people work directly with the developers to help them understand the business.
Karl Marx (yes, the communist) wrote about the alienation of the worker from the final product. His example was that the guy who only installs crankshafts into engines all day doesn’t get to appreciate the final product of the fully functional car. He isn’t invested in the final product because he only sees his little compartmentalized piece of it. By inserting layers between the business owner and the finished system, we are creating that type of alienation in which the business people who have commissioned the work don’t appreciate the trade-offs and considerations that the developers had to wrestle with, and the developers don’t appreciate the overall intent from the business team. As a result, neither group feels an ownership stake in the final product. Additionally, neither can be held accountable for that product either.
Hopefully Dante has a portion of hell set aside for whoever thought that having a team of people translate between the two groups was a good idea. I’m thinking that spending infinity with diarrhea is about right.
The solution we are aiming for is to bring the development team and the business or mission team together so that the former can hear it from the horse’s mouth, ask questions, and probe. And that is what customer collaboration really means.
