• Gary Varga (10/22/2013)


    Sometimes the problem is what the team have implemented.

    Sometimes the problem is the team.

    Gaz - Love it!

    I led a project back in the 80's where I was the project manager and the team architect. We had a large number of people on board and due to a very tight timeline not everything got reviewed as it should by me and parts of the QA was delegated out to a senior developer. One of the dev staff wanted to do things an alternative way and in review the senior developer and I both said no. The developer went ahead on his own and developed it using the unapproved technology. Once his first major component was installed in the development environment we saw that the internals of the machine were showing a huge workload with a small number of transactions being active. Actually one system subroutine was running constantly consuming huge resource allotments.

    When I investigated this in detail by reading believe it or not a huge internal core dump I was able to determine that the problem started and ended with the use of a self-defining data structure in an IBM CICS world. FYI this was mainframe PL/1. When I found this I called the developer in and we discussed the issue and got to the point where he admitted that he went ahead on his own initiative and did it his way even after being told no.

    Sometimes the problem is the team!

    Not all gray hairs are Dinosaurs!