WOAD Roundtable on development issues. It's a small group - only 7 of us here. We started a discussion about the rationales for moving a typical Fortune 500 shop from a set of "stovepipe", unconnected applications to some unified architecture based on (whatever). It's done a lot; it fails most of the time. Here's why:
- political issues surrounding the movement of developers from the tools they know and like (whatever they are) to the "new standard" - this is akin to the issues that surround the well documented CRM failures - the political issues dwarf everything else
- "Doing it on the cheap" - not getting experts and/or training (or getting the wrong experts - big consulting companies with an army of ill trained people, for instance)
However, we hardly stayed focused on this - the discussion ranged all over the place. The conversation ranged over to modeling and code - round tripping - do models, help - can a model be language independent? IMHO, models end up being language dependent - because the design choices you make will depend on the implementation environment you'll live in.
Interesting - one guy has the same issue trying too move from VB to C# that I see in moving people to Smalltalk - management always asks "but how will we maintain it if you leave?" They also seem to believe that large numbers of cheap developers are better than small numbers of good ones. Which is why many outsourcing projects will fail, IMHO...
What about electronic notes - tablets, etc - as opposed to paper notes? I personally prefer paper, a lot. Some think it's a paradigm shift we need - I think people just prefer something they can easiily mark up anywhere they are - i.e., paper. It also makes a difference what the task is - some are far more optimal with paper (ad hoc notes at a meeting, for instance) - others need somethinig that can be archived and passed around more (the person taking minutes at the meeting). Neither is better...
Code inspections - how deep do you go, what do you and don't you inspect? Hand too much over, and you get people mindlessly checking off. Actually, how much value do these kinds of things have? Do such inspections pay off, or is pair programming and TDD going to give you a better bang for the buck? Code inspections to fix consistency issues in code? To my mind, if you have that problem, you have other issues that need addressing. If you have a team so large that you need inspections to enforce consistency, then you have a larger problem.
Re pairing - the idea of pasturing out slower developers and leaving the 'top guys' alone - that's a project smell. If putting the top guys with the newer people for mentoring is a problem, you made staffing mistakes. Maybe - on government projects especially - you don't have the power to get the right staff. In general, you don't want to have a staff where you have to pasture people. That's project smell. Good analogy - It's like the old craftsman, journeyman, apprentice system - yes, the apprentice mostly works with the journeyman - but the craftsman should spend some amount of time with the newbies - both benefit, and both learn new things.
In the end, most of this falls into project management - good process, good results. Bad process, bad results. How do you get junior people trained? What's the mentoring process? It all depends on what kind of junior people you have. How much hand holding do they need? Interesting set of points, actually. Too much too fast for me to transcribe...
Security and Windows - I'll go back to this. The mac hasn't had nearly these problems, and it's been around a long time, and has a decent sized user base - if it were as insecure as Windows, we would have had some big issues reported by now.
SWEBOK - bleah. Nothing good to say about this from any corner. Heck, I've commented on this before. The problem is, this may be used to rate developers and projects from a 'malpractice' standpoint. As usual, watch the lawyers get rich, and the rest of us suffer.
I know this rambled all over the place... but that's the way the conversation went - we bounced all over the place, exchanged a lot of ideas, had a few laughs.