what the force of many cannot
|
|
|
|
Your skill will accomplish what the force of many cannot |
|
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
I've never managed more than a couple of people as programmers nor more than half a dozen on any sort of project except over a very short term. However, I've often wondered if the US medical training model would work well with programmers. I understand the basics of this method are similar in much of the world, too. That makes sense, because parts of it come from as long ago as Roman times. Most of those reading probably have an idea how this works, but allow me to recap it anyway for clarity and comparison.
First, you have students, who spend all their time in lectures and practical labs. Then students spend some time shadowing doctors. Then, you have interns. These are called such because it seems they are interred in the hospital -- they almost never leave. Interns do a rotation with every medical team in the hospital before they decide which specialty they want. Then, they become residents. This places a small group of resident physicians under a mentor or two within a particular medical field. A breakdown of orthopedic surgery, internal medicine, emergency medicine/trauma, anesthesia, infectious diseases, diagnostic medicine, critical care, reconstructive surgery, cardiology/vascular medicine and dermatology (possibly with others like psychiatry or obstetrics/gynecology) seems fairly typical. Only after working a short time with all of these does an intern get to become a resident in one of them. Then, after residency, some become attending physicians, some go elsewhere like small clinics, and some go on to a sub-specialty that may require even more school and training. I know most programmers don't start with three to four years of programming school, an internship, and then a residency on top of their undergraduate degree. However, would it really hurt a company to have a programmer complete an assignment in every type of programming the company does before going into just one team? If I have a regular need for UI programming, mathematical programming, business rules programming, accounting programming, scripting/macro engine implementation, automated unit tests, automated scaffold tests of the whole system, template systems, build systems, and configuration handling, I think maybe I'd like every new programmer to have worked with each part of that. Maybe they only need to write a subroutine or refactor a handful of them in each area, but as a pair programmer with a strong mentor. Then, they can have a mentor on the team which they eventually join. When a problem crosses team lines, perhaps an open and frank consultation from a member of the other team or a temporary joint subteam could look at the problem rather than shooting memos back and forth. The best practices from one medical field often get boiled down into bits comprehensible by doctors with the same basic skills but in a different field of medicine. That way, a doctor can go to a conference or a lecture and get a better idea of how to refer a case. Updating the fringes of one's knowledge with the capabilities the other teams offer make one better able to work with that other team rather than duplicating effort (and often in a less effective way). There's no reason not to have workshops once in a while (internally or externally taught) that keep your programmers on top of what their peers can do, even if it doesn't teach everyone how to do it themselves. Lots of issues are going to cross team boundaries. Even if you have a team per product or per project instead of teams for different types of tasks within your library of functions, there's room for cross-transfer of ideas. However, I have always had the notion that most of a programming shop's work should be creating and maintaining the libraries that will be plugged together to make applications. That way, you can have your teams of specialized types of programming, and you can have a small team that ties every application together based on its unique needs with some help from the maintainers of each subsystem. Medicine is a much more poorly defined problem space than software design. We don't know all the specs for the human body yet. We don't know all the effects of the inputs from the environment, and they seem to be different for different people. Yet medicine works well enough to trust our lives to it. With specialized teams, training rotations, referrals, and consultations, much of the creep of features across boundaries is eliminated. Sometimes you'll find a general practitioner who is slower to consult with another doctor or to refer a patient, but the general rule is to stick to your specialty. Either you manage the patient's whole care, or you work especially deep in one area. If we can trust such a clear separation of systems with one small overall management team for each patient, then perhaps it would work in the better-defined problem space of software design. Each system within an application could be maintained by deeply trained specialists, and the application-specific code that ties it all together could be managed by a small team for that application. As an added bonus, the tools maintained by the deep specialists can be reusable across applications in software (which is much more difficult across patients). The rotating training schedule, the mentoring of residents within their specialty, and the continuing cross-training of basic concepts among the different fields are keys to separation of concerns in modern medical practice. As programmers, software designers, project manager, engineers, etc. we often continue to complain about a lack of modularity in an application. Often we hear others insisting this is because a top-down designer didn't make the breaks between modules in a well-considered way. It is my contention that the problem is having an application designed from scratch from the top-down in the first place. Very few new inventions have off-the-shelf parts, but then very few well-trodden product areas have products designed from scratch. Ford doesn't design a new engine for every car model. They design a handful of engine sizes, and pick which ones are options for a particular model. Every few years there's a new standard for graphics card interfaces to the motherboard in a PC, but you seldom see a workstation with completely custom graphics infrastructure designed into it outside especially customized markets. Having building blocks one can plug together off the shelf in an intelligent way is a big time-saver. It also allows those blocks to be improved across several applications at once. Having a team dedicated to maintaining and improving each kind of building block just makes sense. Having a smaller team in charge of plugging those together and putting some custom stuff on top make sense, too. Any changes or improvements needed by one application might make sense to add to a particular subsystem, and all the better if it can be made an update across the reusable library. Communication of some sort among the various teams is one of the biggest hurdles, then, because the delineation of the design is based on the lines along which you very carefully considered breaking your personnel into teams. If you're designing a stable of applications that have similar needs, then it'd be crazy to not at least consider dedicating a portion of your development staff to the common infrastructure. Once you've done that, make sure the application team, the subsystem teams, and the quality control people are all talking with one another rather than just to one another. Constant collaboration across the boundaries is, after all, how your doctor would do it. In reply to Re: Best practices, revisited
by mr_mischief
|
|