Submitted by akinsgre on
Following from the thread on Managing Geeks, and comments made elsewhere, I'd like to get some feedback on the "problems" with Software Development groups (both internal and commercial software) as seen from outside those departments?
Does anyone want to list things that they see as detracting from the reliability of their interactions with their own software development groups?
[list]Lack of seeing the big picture - programmers tend to focus on the peice they have and will do that extremely well and then find it doesn't fit in to the big picture.
Blaming schedule slips on others - it is always someone else's fault.
Lack of communication - this is a huge issue and is my biggest challenge right now.
Dual responsibility - the programmers can do testing and documentation but NEVER at the same time as programming. You are much better off getting separate people to do those types of things.[/list:u]
Are these things also problems with SW Dev in general, or are there more systemic problems as SW Dev integrates with the rest of an organization.
I'd be particularly interested in comments from folks that work in commercial development
Problems with Geeks
While these 4 areas appear to be problems in themselves they seem to point out a wider systemic problem in organizations that are encountering these.
I would hope that this is an exception rather than the norm.
In my stint in commercial software development environments, one thing noticeable is structure.
You normally have a structured team of a project manager (or managers if its a program), team leads, senior developers, developers, testers, technical writers, dbas and so on.
Each role is responsible for a specific task:
tech writers for documentation
testers for testing deliverables
developers can focus on module development
sr. developers on integration
leads on architecturing, keeping schedule on their area
project manager for overall project management
now since these are roles and not every organization has the luxury of resources.... you may have resources with several roles.
The key is making sure that expectations are clear for each team member and roles are not conflicting (e.g., developer cannnot system test his own module).