JRRZZ blog

What’s up with software development lately? As in the last five years or so. It used to be a fast paced ongoing stream of innovation. It seems to become sluggish and less innovative over the years. The engineers didn’t get dumber, they didn’t become more lazy all of a sudden. So what happened? I’ve got a theory that surprisingly fits and explains the recent developments in software engineering.

A long time ago, in the old days, programmers were programmers. They knew how to write code, they knew how to implement their knowledge into a system that complied to the requirements made by the technical staff. They could listen to a detailed technical story and almost instantly produce code. These programmers were skilled people with knowledge of advanced system engineering, algorithms, logic and so forth. Let’s just call them hackers from now on. These hackers were able to get a product up and running in no time. You just had to have skilled people to translate management gibberish into a language understandable for hackers. These roles were usually fulfilled by senior hackers with loads of experience. This system has produced lots of ground breaking code. Just look it IBM, Sun, Microsoft (to some extend) and other big companies. Entire operating systems were built in a matter of a few years.

Somewhere along the line it took a turn for the worst. The clear manager/programmer boundary was getting more fuzzy by the day. Managers started using hacker terminology, often entirely wrong. Hackers were forced to become “System Engineers”. Because management wanted it’s share of the fun, and just stealing terminology wasn’t enough, they needed a management perspective on the coding work itself. Object Oriented Programming was born. Don’t tell me this was a good thing. All the benefits OOP gives us can be made using proper modularisation. But now managers could see schematics and nifty other pictures. Thanks to this new way of designing a system, code becomes a byproduct. The system is built on paper. And just like we expect from management, the necessary paperwork has to be created before and after the system itself. In the old days it was alright to write well documented code in a clean way. Other hackers could read your code and comments, some documentation with your major design strategy and changelogs and that would be enough. How do you test or debug paper? Or even more important, how can innovation happen when the paper protocol restricts people from doing actual research? But there’s a solution. People started to write software to actually simulate an OOP system without even writing it. It becomes utterly abstract for the old school hacker. By this point he’s pulling his hairs out out of pure frustration. This same software can even output half the source code, using only a block diagram.

You know, what if. What if this OOP thing actually works. I’ve done it. And yes, it does work. But there are a few minor points of criticism. First off, development takes eons. You need to spend a lot of time building your classes and connections between them on paper or in a design tool. That’s quite a labour intensive process. Without that step it would be impossible to write code because it’s split up in too many modules with different connections between them. Second, you can’t force programmers to conjure up schematics and fill in the gaps in the code afterwards. It’s against their nature. This will work counter productive. Third, the code becomes almost unreadable and undebuggable. If you give someone uncommented code in C that person will be capable of understanding what it does in say, a few hours. The same amount of code in OOP C++ will take a small army to dissect and understand in the same period of time. Really, especially with inheritance and virtual recursion it becomes unreadable. You’ll simply need the diagram from which it’s created to understand.

And after all this I can still live with OOP code. If it’s documented properly and built the right way, I can manage. But the problem is that the kids don’t learn how to write proper OOP at school. Somehow the teachers just don’t get it. Time after time when I see OOP code from a freshly graduated student I just can’t help myself and vomit all over my keyboard. Object Madness. Somehow all the teachers think it’s a good idea to teach that every little thing where you can create some parameters and functions with, has to be an object. And every object has to inherit, be special, virtual, whatever. What hackers would make with two functions and a struct, a student would make it using three objects all inheriting from a big central singleton class. Schools deliver “System Engineers” who can’t write code and can’t think straight anymore. Yeah, they know how to create neat schematics and paperwork. But even the simplest programming tasks are too hard for them. And people can’t stop asking themselves why it’s so hard to find good IT students. If “System Engineer” would be my job, I’d hate my job.

Tags: Tech //