I had a transforming moment a number of years back. I used and understood C++, objects and the principles of object oriented design. At first these were an academic interest. I could see that isolating one part of the system from another was good. Intellectually this made a lot of sense. One part of the system changes independently from another. Objects can represent real world entities. Dependencies can be managed.
The one fateful day I was helping a client to redevelop an existing system. It was an embedded system. The original code was written in C. The rewrite was to be in C++. I was working with the systems engineer, I’ll call him Johnny. Well Johnny wrote the original system ten or so years earlier. Change was coming in the marketplace with significant hardware technology implications. A major hardware change was in the works. Johnny and his company had decided a complete rewrite was needed.
Johnny had his requirements specification. We read through it paragraph by paragraph and turned it into use cases. When more information was needed, Johnny would have to take time to research the requirement. He did this by going back to the old C code! Preserving the old system behavior was the requirement! The domain knowledge was captured in a tangled mass of C code. The actual system behavior, from an operator’s point of view was not changing, just the implementation details.
The real requirement was to run the system in the modern hardware utilizing the new technology. Unfortunately the existing application logic was so intertwined with the hardware control code, it was impossible to separate application from hardware implementation.
Ah! Ha! If this system had been designed with separation of application logic from implementation specifics we would not be doing a whole rewrite. The academic reasons for OO went out the window. Engineering and business reasons took their place.
Add Child Page to TransformingIdea