People Problems
Scott Ambler, promoter of the Agile Data Method, provides some interesting insight into the software developer's working environment.[2]
Different visions and priorities. Developers focus on the specific needs of a single project and strive to work in isolation from the rest of the organization. Administrators focus on the overall needs of the enterprise, sometimes to the detriment of individual project teams, yet the scope priorities and issues of each are all different. To make matters worse, project stakeholders, including users all the way up to senior management, have varying priorities and visions as well.
Over specialization of roles. Specialists tend to be too narrowly focused. Because they are specialists, they may have difficulty relating to other professionals.
Process impedance mismatch. A number of recent approaches to
software development advocate an incremental and iterative approach. However,
many IS/IT managers still view the process as a serial or near-serial process.
Consequently, there is a process mismatch necessitating a cultural and organizational
change within the organization.
Technology impedance mismatch. Developers work with objects and components whereas data professionals work with databases and files. Software engineering principles form the underlying foundational paradigm for objects and components whereas set theory forms the underlying foundational paradigm for relational databases (by far the most popular database technology). Because the underlying paradigms are different the technologies don't work together as well as they should.
Ossified management. The technology and techniques used by IT professionals change rapidly. As managers progress up the corporate hierarchy they deal less with technology and more with people issues. It doesn't take long for their previous technical experience, on which they base decisions, to become obsolete.
Organizational challenges. Poor communications and "office politics" hurt development efforts just as badly as they hurt other enterprise efforts.
Inappropriate documentation. Either too much, or too little, documentation may prevail depending on management will. Too little and it becomes impossible to retrace earlier steps; too much and no one reads it.
Ineffective software architecture efforts. Software architecture is not a well established discipline, let alone a profession as in building construction. A lot of people simply don't know where to start. And, if they do, the resulting models are soon abandoned.
Ineffective development guidelines. Some organizations struggle to develop guidelines for all their IT people to work to. But, as with any guidelines including project management guidelines, some people are not aware of them; if they are they don't understand them; or if they do they consider them obsolete; or they are otherwise unwilling to follow them anyway.
Ineffective modeling efforts. Some people focus on a specific aspect to produce models that look very good only to discover that they do not reflect the real world, especially if past experience and practices are not factored into account.
2. Scott Ambler, abstracted from http://www.agiledata.org/essays/vision.html#WorkingTogetherIsHard,
2002
|
Reasons Why Linearity Doesn't Work for IS-department-type Software Development
