This should be titled "How not to build a system". In the early days of programming, application development was a black art where the programmer huddled in a corner and would not allow anyone to view the code. Even if others were allowed to view the code, it was pretty much incomprehensible.
After years of good programming practices, I thought that we have left the black arts behind. I was wrong, in 2001, while working on a short term contract to implement a module on an embedded system, I found the embedded system that had no design. I asked some of the programmers where I could find the design so I could use it to design my module for the system. They looked at me with a blank stare. I met with the project director and the chief programmer and told them that they had no design for their system. I was met with anger, as they stated that they had a design, but when they moved to the new office, they had to leave it on the white board at their old office.
In the past, I have had to reverse engineer systems written in assembly language, so my first thought was that reverse engineering a system written in C++ would be easy. Indeed, if there had been any type of underlying structure or design, it would have been easy. Unfortunately, I discovered that instead of design, "Random System Development" was used, and there was no basis for most of the classes.
I found that the chief programmer had no background in computer science or software engineering, had a PhD in Zoology, but couldn't get a job in his profession, so he read a book on C++ and became a programmer. Also, because he had a PhD, he became chief programmer. Once I understood that he was a Zoologist, all those classes made sense. If a system design had been done, there would only be a few classes, so they might be endangered. By creating superfluous classes, he could populate the entire machine and create a ecosystem that would keep him employed.
If the ecosystem were stable, I could have implemented my module (no design necessary) and gotten away quickly, but the chief programmer was adding and deleting classes at random that affected my module. Fortunately, the chief programmer took a vacation, and no changes were made for a week, so I finished my module, demonstrated it for the project director, put the source under configuration control, picked up my check and was gone.
I don't know if that company is still in existence, but with the engineering processes they don't have in place, they should not be.
I take pride in the systems I create. I normally even take pride in applications and modules I create. However, I take no pride in the module I left in the random embedded system. I tried to improve the software process by offering a tutorial, but since I was an outsider, failed to get the backing. I offered to meet with the chief programmer to "pick his brain" and create some type of documentation for the system so it wasn't the maintenance nightmare it is, but was told that the customer would not fund it.
Somehow I feel that something should be done to correct the situation. All of the projects I have led, involved customer reviews, where I had to demonstrate a design. If their customer accepts the system without review of the work done, then it is the customer who is responsible, and the customer who pays the price.
On systems I am responsible for, I take pride and request my customers review my work at each phase of development unless they request it first (and my customers not only request a review, they insist on it).
I once met with the owner of the company before knowing how they randomly created systems, and he had a vision of achieving CMM SEI level 4 within three years. In the short time I was there, no evidence was visible, and when I mentioned software processes at a group lunch, the single software engineer in the group was the only one who agreed with me (and she was an entry level engineer). The other programmers scoffed at the idea.