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 ). | [reply] |
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] |
| [reply] |
I've always felt that writing code was easy, and I still do. It's the other stuff -- figuring out what code to write -- that's hard.
Amen brother!
This hits the nail squarely on the head and drives it a good way into the wood.
In a perfect world I'd be able to spend my time designing and coding based on a perfect understanding of a perfectly defined, immutable, project spec. But if the world were perfect it would be no fun.
Maybe you will get lucky and have reasonable requirements and a spec. But they won't be complete. You're still going to have to gather/clarify requirements with the person who produced the docs.
Maybe the big, `strategic' design has been taken out of your hands; you're still going to have to deal with the tactical design issues of functional composition, naming of parts, algorithm choice and all the other details that help you build a good program instead of a ball of mud.
Of course, you may want to be micro managed, but if that's happening wouldn't it be much quicker for your puppetmaster to just fire you and do the job himself?
You don't have to excel at all these things. You don't have to do them all all the time. But if you intend to get better at your craft you're going to end up either knowing how to do them, or you'll have some pretty strong ideas on the subject that you could put into practice if you had to. It's all part of the process of active learning that (I claim) is one of the fundamental skills/goals of any half way decent programmer.
| [reply] |
You are using an unpretentious title which is part of the
misunderstanding here. I wouldn't say you're being arrogant about what a programmer should do. I think you're being
humble by calling yourself only a programmer.
Gathering user requirements is often the job of a dedicated analyst, or at least a lead programmer. Translating these into a development project is the job of some sort of visionary or logistical person (like an analyst or programming lead). This is similar to a land developer or a really good general contractor in building construction. You might call this position a 'Applications Analyst', or possibly a 'Requirements Specialist' or 'Customer Needs Analyst'.
Deciding what parts need to be made and how they fit together is the job of a software designer or software engineer. This is sort of like an architect, and sometimes the job title is reminiscent of such -- 'Software Architect'.
A linguist, psychologist, or artist (or preferably all three) is best suited to UI concerns. Which is best depends upon how much the interface differs from what the users have already seen, the major goals of the interface design (being more attractive than normal, just being familiar, or actually being easier to use). In any case, some projects which a user sees have a dedicated interface designer. Programs that only talk to other programs are generally
okay to have an interface done by a programmer or software designer. Ideally, this person is equivalent to part interior designer, part landscaper, and part Feng Shui master.
A programmer often is someone who simply writes programs. This is especially true of people employed specifically to maintain an already operational project with no budget for redesign or major refactoring. This might include some unit-level design decisions, but often just consists of translating the requirements of a single component at a time into code. These are the carpenters, bricklayers, plumbers, and electricians. The construction jobs of panellers, painters, plasterers, carpeters, etc. fit into this category or the one above, inclusively.
Keeping everyone working together and keeping them on schedule is the job of a project manager, kind of a general contractor of sorts. They make sure the requirements analyst's (land developer) vision reflects the user's needs and is in turn reflected in the software designer's (architect) more detailed design. They make sure the programmers (trades workers) implement what the software designer's design mandates. They make sure the interface makes sense to the user, that the main program and the interface work well together, and that everyone has everything they need in order to make all of this come together. The quality assurance is ultimately the project manager's responsiblity, as is setting reasonable timetables and providing for the needs of the people working on the project. Additional people are often used to help the project manager do all of this, abive and beyond what I've already mentioned. This can include unit testers, system testers, staff assistants, dedicated customer liasons, documentation writers and for extended maintenance programming departments (which any successful project turns out to need, of course) this can include technical support,
customer complaints and suggestions staff, etc.
Under certain methodologies, many of these tasks are shared among a group, with each person filling part of every role. Extreme Programming seems to promote this to an extent, for example.
In small IT shops, in constulancy businesses which aren't dedicated to programming, in an IS department at a non IS company, or in some other cases people have to take on more than one job role. simply by neccessity. In fact, in very small businesses, such as a self-employed consutlant or a partnership with two or three people, it's common that every role in a company is upon the shoudlders of one person. Not only does this include requirements, design, initial programming, testing, debugging, maintenance programming, and documentation, but also the mundane business matters of sales, marketing, accounting, facilities management, reception, and public relations.
Just because one person fills more than one role doesn't mean there's not more than one role to be filled. A person employed as a 'Programmer' in title might be expected to do more than write code. There's really more to the job in that case than the title implies. That's where a resume comes into play, showing what a particular title really means at a particular company.
Christopher E. Stith
use coffee;
| [reply] |