Intermittent documentation fault

[suityou01]

In the gig where I am there is sometimes documentation for things and sometimes not. It's a bit of a lottery. I was recently asked to implement a bespoke "email listener" sub system into one of the new processes I was developing.

I knew nothing of this sub system, not where to find it or how to use it so I asked the person responsible this

"There is a requirement to use this technology. Is there any supporting documentation that can be made available for me to read in advance?

Many thanks"

And I got this response

"In an ideal world there would always be documentation, wouldn't there?"

I've think he is getting narked as I have maybe asked him once before about some documentation. He is the head of standards and documentation forms a large part of this job.

I realise in practice there is never any time to do the documentation as the business wants, and there may be a good intention to go back and do the documentation but it never does.

As a contractor it's fine as it takes three times as long to get anything done because you have to trawl through code and reverse engineer what has been done before you can get started.

I genuinely believe the peeps here would do the housekeeping if only they were given the time, but it's not revenue earning the way they bill their clients. As more and more systems get created, there is more and more vagueness about how things work.

I wonder if there actually exists a company out there that adheres to development standards rigidly, has nice neat proof read documentation about everything, and what it is like to work in that kind of environment. Is the grass any greener, or is it like living in the Truman show.

Formal methods and rigid documentation, or OK Corale coyboy code, or somewhere in between?

[Mich the Tester]

In the gig where I am there is sometimes documentation for things

Bloody hell, where's that? Sounds like paradise.

[Numpty]

I wonder if there actually exists a company out there that adheres to development standards rigidly, has nice neat proof read documentation about everything, and what it is like to work in that kind of environment.

I worked at a small software house that did that. Maintenance of code was a pleasure. Plenty of comments and appropriate documentation.

We could implement enhancements very quickly and charge the client lots.

Very few bugs were implemented live.

When the owners eventually sold the company, they became millionaires.

It taught me that doing the job properly the first time makes subsequent change easy and cheap.

However, experience has taught me clients are not interested in tomorrow, only today. They want it cheap and fast and couldn't care less if it cannot be maintained and will have to be completely rewritten from scratch in two years time.

[Mich the Tester]

... and will have to be completely rewritten from scratch in two years time.

Boomed!

[thunderlizard]

I was recently asked to implement a bespoke "email listener" sub system into one of the new processes I was developing.

That sounds like Zawinski’s Law in action:
http://www.catb.org/~esr/jargon/html...nskis-Law.html

[Gonzo]

It depends on the priorities for the organisation I suppose.

I once worked on a system designed for a fairly specialised job within Investment Management. The original system had been flung together in the no-documentation approach that we are all familiar with, because the priority was to ship something quickly.

As more customers came on board, more sublte variations were introduced into the functionality. At that point, the whole thing became a complete nightmare to maintain and the supplier started to suffer a reputation for late and buggy deliveries.

So then they decided that documenting everything thoroughly was the answer, and it was for a while.

Now the software is too expensive to maintain because of all the overheads.

[jmo21]

This is a classic software development issue I see everywhere I go.

Computer software is still such a young industry compared to others, and until software systems are seen in the same light as "bricks and mortar" engineering, there will never be good enough documentation.

Of course there are places that are better than others, but most places, documentation is out of date the moment it's written.

[Lockhouse]

In the olden days a high level of documentation was much more commonplace than today - now it's usually poor or non-existent. When I first went into IT many years ago as a humble operator I worked on a site where everything was done properly, all changes to source code were documented and hard copy filed, all specs were listed and up to date etc and after a while it became my responsibility to look after all of this. Once you got into a routine the overhead was surprisingly minimal and it did actually repay the time in terms of work saved. The by-product of this was you actually learnt loads about IT without realising it. It was very much a case of "wax on/wax off".

For the past 25 years all I've done is trade on that structured way of thinking I was taught at the time. I've learned loads of new languages but not really learnt anything "new".