It seems like large companies believe doers don't matter anymore. A developer is a developer, a QA is a QA, hire them by the masses! Any warm body will do! How did it get to this point? More importantly, how do we get out? How do we reinstate development to its proper level of importance; to the level of craftsman?
It's really interesting when you talk to people doing traditional enterprise software development. Many developed software in smaller companies, startups, or even on their own previously. If you ask them to rewind and think about how they operated in that environment you find that they embodied many characteristics of an agile developer or agile team. Collocation, constant communication, collaboration, small chunks, frequent releases, customer focus, getting the job done with great engagement and satisfaction. Fast forward to today. Now they're entirely enterprisified. Lots of documentation to make up for the lack of communication and collaboration, doing an unfulfilling, small slice of the delivery pie, unsure who the customer is and not really understanding how they intend to use the system, and unable to step in when gaps arise because role boundaries are cemented into the culture. Generally these people say that they were far more effective in their former role. Why? They were smaller. They were focused on the product and the customer, not the process and their role.
Successful small teams start with talented contributors. Inevitably, greed or business need or both prevail. Must get more done. Realistically, if the talented group is humming along, the only way to get more done is to add people to the effort. That all seems fair to me. What usually happens at this point though is that a bunch of sub-par people are added to the effort. That's the worst thing for the team for multiple reasons.
1) Initial ramp-up for new people is costly. Add talented people, not sub-par people. Talented individuals will ramp up faster.
2) As Fred Brooks talks about in The Mythical Man Month, increasing people on an effort increases the amount of communication required by the team. But wait Jason, you just said adding people to the effort was fair? Absolutely. Add talented people, not sub-par people. In my experience, adding talented individuals to a project only marginally increases timeline due to communication, much less so than adding mediocre folk. This is really the same point as #1, but directed more at the ongoing cost of communication rather than the upfront (ramp up) cost.
3) A diminishing talent pool begets quality policing. Policing is ugly for obvious reasons.
The diminishing talent pool is the issue I really want to highlight. As this scenario plays out, the talented folks become "leaders" of sorts where they begin to focus less on implementation and more on leading, managing and overall design. The thinking here is that having a top tier person design the system and set standards will result in a great and healthy system regardless of who does the development. Managers in organizations think this works because, as Uncle Bob wrote in The Clean Coder, "they don't see the God-awful code."
The fact is, developers have both immediate and long-lasting impacts that make the role absolutely vital, arguably the most vital. The code is what users interact with and experience. Not the system design, underlying components, and certainly not a backend DB. Users interact with apps written by developers. Therefore, developers have an immediate impact in the form of product quality. They introduce, reduce, and prevent defects in the product. Devs also have a more indirect and long term impact on users in the form of a product's changeability, testability, automation, and technologies that make up the product. The code that David the Developer's writes today determines releasability tomorrow. The code that he writes today determines how hard it is to change tomorrow. And the code that he writes today determines the customer's product quality experience tomorrow (or even today if you really rock!). How many sub-par David's can you and your customers afford on your team?
1) Initial ramp-up for new people is costly. Add talented people, not sub-par people. Talented individuals will ramp up faster.
2) As Fred Brooks talks about in The Mythical Man Month, increasing people on an effort increases the amount of communication required by the team. But wait Jason, you just said adding people to the effort was fair? Absolutely. Add talented people, not sub-par people. In my experience, adding talented individuals to a project only marginally increases timeline due to communication, much less so than adding mediocre folk. This is really the same point as #1, but directed more at the ongoing cost of communication rather than the upfront (ramp up) cost.
3) A diminishing talent pool begets quality policing. Policing is ugly for obvious reasons.
The diminishing talent pool is the issue I really want to highlight. As this scenario plays out, the talented folks become "leaders" of sorts where they begin to focus less on implementation and more on leading, managing and overall design. The thinking here is that having a top tier person design the system and set standards will result in a great and healthy system regardless of who does the development. Managers in organizations think this works because, as Uncle Bob wrote in The Clean Coder, "they don't see the God-awful code."
The fact is, developers have both immediate and long-lasting impacts that make the role absolutely vital, arguably the most vital. The code is what users interact with and experience. Not the system design, underlying components, and certainly not a backend DB. Users interact with apps written by developers. Therefore, developers have an immediate impact in the form of product quality. They introduce, reduce, and prevent defects in the product. Devs also have a more indirect and long term impact on users in the form of a product's changeability, testability, automation, and technologies that make up the product. The code that David the Developer's writes today determines releasability tomorrow. The code that he writes today determines how hard it is to change tomorrow. And the code that he writes today determines the customer's product quality experience tomorrow (or even today if you really rock!). How many sub-par David's can you and your customers afford on your team?
No comments:
Post a Comment