Thursday, May 04, 2006

Standards and communication

Very often companies are standardizing their software development process. The lack of a clear structure often leads to information stored in heads, documents wandering around the place and architects knowing where to find the desired or needed documentation, and telling you what you have to do.

Every time there is this issue: "no time to do it right, IT managament doesn't want to pay for the improvements of the process". Often projects are becoming more and more expensive because the business is "invisible" paying for improvement of the overall process.

The result is that the process will never be finished or in a solid state.

What are the symptoms:
  • Look at what we've got, not what we don't have. - this leads to inactivity on items which need to be addressed.
  • We will improve it during development of the project - this leads to unfinished stuff because of deadlines.
  • Developers are only commited to the project - this leads to different code in projects and not following a standard way of working which makes it very inefficient to maintain the code.
  • Big influence of the business on the IT architecture - this leads to an inefficient IT architecture because the technical and conceptual models shoul be separated.
  • More to follow...
My point is that a developer, because of these defects, always searches for the facts and finds them on a late point during the development stage, which could lead to a big impact on the code.

I am still struggling to find a way to smoothe this process. Advocating other ways of working, pushing IT management and pointing out where it hurts doesn't always result in an improvement. The issues are moved to the next phase, hoping they will be addressed then...

1 comment:

  1. The problem is and always will be the flow of information. We still don't seem to have that under control.

    The process is always and never done.

    A process is done, because whenever you do something you are following a process. It maybe undocumented and in your head or a full blown formal process, it is there.

    A process is never done, because the people and the projects change, each having their own requirements on the process.

    Accept these two seemingly contradictory points and things are more clear.

    This is why I suggest describing a process (through observation) instead of prescribing it (through documents and process police.

    ReplyDelete