I was thinking that one way that a coding team could work would be that coders would be rotated through several roles. This would prevent people from getting too comfortable towards the goal of preventing problem areas (code quality wise) from developing in the department.

  • Architecture
  • Production Coding
  • Documentation
  • Quality Control

Splitting off architecture as a role will help, I hope to clarifty role-wise for a coder when they are expected to have input on process, vs. when I'd be happier if they were actively attempting to hit a metric and fulfill a specification.

I think it is a good idea for the design team to get input from the coders. Let me give you a non-programming example. My brother was a civil engineer in charge of the maintenance of the province's water treatment plants. When the design for a new plant came to his desk he showed it to the people who would be doing the actual hands-on maintenance. Their major input was that some of the pipe runs were continuous. That meant there were no junctions that could be disassembled to clean the insides of the pipes. They would have had to cut the pipes after installation and install access points to allow for cleaning.

Design people often don't have maintenance as a priority.

Are you implying that a single person would constantly rotate across positions involving software architect, coder, writing documentation, and doing QA? I'm not a fan of this strategy. Firstly, different people have different strengths and weaknesses. You want to put each person in a position in which they will thrive at doing what they're best at. A good coder isn't necessarily a good software architect. A good software architect isn't necessarily good at English grammar and writing documentation. I think, instead, you want each single person you hire to do one specific thing, excel at that one specific thing, and be better than anyone else at that one specific thing.

I'm saying that the design team should get input from the coders who will have to implement/maintain and software system. A designer might not put hooks into the code for logging that can be enabled and disabled as required for troubleshooting. When I designed infrastructure I put in many hooks of this type. In a production system they would usually run disabled, but by setting a few global flags a lot of very useful information would be instantly available to the person (usually me) who would be called in at three in the morning to fix a problem.

@Reverend Jim

That meant there were no junctions that could be disassembled to clean the insides of the pipes. They would have had to cut the pipes after installation and install access points to allow for cleaning. Design people often don't have maintenance as a priority.

I agree and if anything I would go further. I don't see coding and design as seperate fields (rather, seperate roles.) In other words, I think that to be a good coder one must show some talent for design. And to be a good designer one must show some talent at code.

If anything I feel a distinct preference for working with maintenance coders than with trail-blazers.

I like your allusion to the need to make application components disassembleable (sp?) and find your choice of plumbing perhaps apt. Perhaps you might feel something about the possibility of making software so that it fails predictably?

and find your choice of plumbing perhaps apt

Before I retired, if someone asked what I did I usually replied, "digital plumber". It was not my full job but it described the major duties much better than just "programmer".

@dani

Are you implying that a single person would constantly rotate across positions involving software architect, coder, writing documentation, and doing QA?

Yes.

I'm not a fan of this strategy. Firstly, different people have different strengths and weaknesses.

Yes, but given that the req will request five properties, if someone is good at four of those things coming in that makes them already an A-level candidate. Somebody showing up to an interview who is good at three out of five (60%) is a B-level candidate and would probably get the job.

Expectation value would be someone who would be truly good at two out of five (40%). And there's a shortage of qualified coders these days! So 40% is pretty solid in today's climate.

You want to put each person in a position in which they will thrive at doing what they're best at.

I hear you, but I think that there is something to be said for rotating people around a bit. Since I can't give any one person full accountability for every aspect of coding, I'll try to give every person a bit of accountability for all aspects. My reasoning, building upon what our friends here have identified as a need for code maintenance, is that if I nudge people to make maintanable code they will write stronger code to begin with.

I think that to be a good coder one must show some talent for design. And to be a good designer one must show some talent at code.

I have never experienced this in any of the companies I have worked for.

It's a bit different for web apps, since some designers know (the quirks of) HTML/CSS, but to me that is not coding.

I frequently had to deal with Engineers who felt they could both design software and write it. I only once met an engineer who could do both competently. She got her degree in computer engineering and started in my group as a junior member. She rose quickly through the ranks and even became my boss for a couple of years (my happiest at work) before going on maternity leave. The other engineers failed miserably at both design and coding.

I think anyone who aspires to software design should be forced to spend at least one year doing software maintenance. You learn a lot about what not to do by having to work with someone else's bad decisions.

Reading this I thought, suppose in a group of cave men, some were good at making wheels and some were very good at making wagons. If they switched rolls might they get round wagons with square wheels?
On the other hand, if they had a wheel maker who insisted on making square wheels, switching roles might be a good thing.
Maybe one size doesn’t fit all.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.