Re: Re: What is a programmer?

Perrin,

I would say that you might well have crossed the line from a "Programmer" to something more complex. Some people use the term "Software Engineer", however others feel there should be a lot more stringency on the use of that term.

Much of the existing writing on managing software development argues against having the Developer themselves responsible for all the aspects you list; This is for both focus and issues regarding organizing a team.

Exactly how would it work if each programmer in a 20 person team was responsible for defining their own time tables and deliverables? Some sort of consensus would have to be achieved, correct? There is usually an individual assigned this role in a team, often the team lead or the project manager. While a developer can handle this task, it is often a better use of resources if the developer is allowed to develop rather than worry about organizing time schedules. There are people much better suited to this role, who can focus on it. While I do empathize with the situation that often the people who are given this role, often are not well suited; But this is a problem with the Co. assigning the wrong people.

It is well documented that a developer is often the worst tester of their own product. Unconcious bias relating to certain sections of the code which are unstable can creep in, personal opinions regarding ease of use and desired functionality can arise from a misunderstanding of specs, as well as the time required for testing is often business-wise much better done by someone the company doesn't have to pay as much. A QA dept can build a standard procedure and reporting chain, which when done right will result in a better testing of the product -- assume the QA group and programmer have the same testing skill, the difference would be the benefit of having an unbiased set of eyes to examine the product, and if the skills are not equal then the QA group needs to be better trained.

During the QA process, the testing team will need help from the programmer in understanding the details of the system and often in how to test functionality
This injects the programmers personal bias, and restricts the QA teams efforts. A QA team should proceed as a user, not as a knowledgeable developer. A QA teams job is to be the best BDU you can find, if you educate them too much about the system then you eliminate much of their value.

Spec gathering, this is part of a system designer's job. However, how time consuming and redundant would it be for each programmer in a 20 person team to do their own spec gathering? Quite. Even if they only gathered specs for their own particular section, there is always going to be overlap and it is quite possible that transition issues within the system would be overlooked. So, again the management of this process should be given to a single individual ( often the project manager, but sometimes an analyst ), which can bring in team members as required but in general leave the developers to develop.

From reading your view it seems that you either work in an extremely small development shop where you are the only one, or maybe one of two, on a project. Having the individual developer responsible for all of these tasks simply does not work for larger development teams and is often a collosal waste of resources.

I have experience developing in Co's with both large and small development teams. The Co is much better off in software development when they can afford to staff a team with developers, a project manager, a relationship manager, an analyst, a documenter, and a QA team ( yes multiple, not just one ).

Comment on Re: Re: What is a programmer?

Replies are listed 'Best First'.
Re: Re: Re: What is a programmer? by perrin (Chancellor) on May 20, 2002 at 19:05 UTC
I think the issue here is that you're interpreting what I said as "everyone does everything", which is not the case. Some programmers do a lot more of one thing than another. I don't usually bother with terms like analyst, architect, etc. They're all part of the team that creates the programs, and there's a ton of overlap in responsibilities. These days I spend more time on analysis and design than on actual coding, but I still think of myself as a programmer because the end result of what my team does is still a program. You can make distinctions if you want to, but I prefer to let the process be a little more organic than that and let people contribute where they feel able to. Much of the existing writing on managing software development argues against having the Developer themselves responsible for all the aspects you list That's true, but there's also a counter movement in Extreme Programming and similar methods to remove some of the bulk that is caused by trying to separate these things so much. Even when these tasks are officially separated, there is a lot of collaboration required. Exactly how would it work if each programmer in a 20 person team was responsible for defining their own time tables and deliverables? The programming team should reach this conclusion together, with input on priorities and schedules from the business. Usually the more experienced people contribute more to this part. It requires an ability to break features up into logical chunks and a basic understanding of the system design in order to know what can be separated. I don't know any project managers who can do this without extensive hand-holding from the programming team. A QA team should proceed as a user, not as a knowledgeable developer. Of course, we all know this. However, there is a lot of interaction between the QA team and the programmers because not everything QA needs to know is written down. They often need to create certain conditions in order to run their tests, like artifically making a product in a store application out of stock. Doing this requires some knowledge of the data model, the interaction between the application and the database, and some basic SQL. Most business projects don't have tech specs that go into the necessary detail on this sort of thing, so help from a programmer is needed. The bottom line is that I'm not opposed to separating these tasks, or giving out fancy titles, but the best programmers I've met knew enough about each of these things to help make them happen if the person with the official title couldn't do it for themselves.	[reply]
Re: Re: Re: What is a programmer? by pdcawley (Hermit) on May 20, 2002 at 13:10 UTC
Using the terminology of Pete McBreen's wonderful Software Craftsmanship, Perrin is a master programmer. Generally you only want one master programmer working on a project, a bunch of journeymen and a few apprentices. The master makes the big decisions, but delegates many decisions to his journeymen who may in turn delegate to apprentices. Note too that just because one knows how to do something doesn't mean one has to do it. Given good people filling the various other roles one can delegate upwards too. But when the buck stops with you (and if you think it doesn't then you're fooling yourself) then you must be aware of the issues and be prepared to nip problems in the bud.	[reply]