Are cars too complex?

The complexity of software is rarely understood, except by people who work in certain fields. A good example is vehicle software. For anyone who wants to have a basic understanding of software complexity, I suggest “How Software is Eating the Car“, by Robert N. Charette on IEEE Spectrum.

The article makes a number of very interesting points:

• That low-end vehicles are quickly approaching 100 microprocessor-based electronic control units (ECU), and 100 million lines of code.
• That vehicle cybersecurity is a huge issue.
• That vehicles have a huge issue with software defects.
• Vehicle software designed using today’s architectures is becoming unmanageable.
• It is extremely challenging to test vehicle software.

And to sum it all up, consider this: A Volvo contains 120 ECU’s, and 100 million lines of code. That code:

“…contains 10 million conditional statements, as well as 3 million functions, which are invoked some 30 million places in the source code.”

Vard Antinyan

Where are the pink OO unicorns?

In 1989 I was in third-year university, and object-oriented programming had started to catch on. It was the latest entity that was suppose to change the way software was designed and implemented. By the 90’s most universities had an OO course of some sort, more often than not taught by some academic who was basically learning it on the fly. The thinking was that if you didn’t know OO, you were behind the curve.

I remember OO being taught in a very strict and authoritative manner. Software was entirely designed in the form of objects and classes. In fact even the problem-solving space was suppose to be thought of in this way. This was touted as “object-oriented analysis and design“. I took a class on OO in fourth-year (I actually enrolled in an additional diploma to do the course because I had used up my quota of CS courses in my degree). It was nauseating, taught by an insufferable industry individual who had drunk way too much of the Kool-Aid. I remember lasting about two weeks before I dropped the course. Ironically a year later I did my honours thesis on OO problem solving in C++… but arguably it was more about the C++ than it was about the objects. I mean at the time I didn’t realize how horrible C++ really was.

“Object-oriented programming offers a sustainable way to write spaghetti code. It lets you accrete programs as a series of patches.”

Paul Graham, The Hundred-Year Language (2003)

By the time I took an OO class in grad school a couple of years later I realized that OO had become a cult. The textbook, “Object-Oriented Modeling and Design” written by Rumbaugh and colleagues (although nobody remembers the other authors) was horrible to read (which is not unusual in academia). It’s now considered a landmark in OO literature, but in my view it contained a lot of fluff, and not much content. Of course Rumbaugh was also one of those responsible for the other OO atrocity, namely UML, short for Unified Modeling Language (UML). But OO did spurn a whole publishing genre.

“UML has become complex and clumsy. For 80% of all software only 20% of UML is needed.”

Ivar Jacobson

Around the same time “Design Patterns” appeared written by the “Gang of Four”. I never read it, but I saw the effect things like patterns did to people… it left their minds in a sort of insentient state. The other thing people liked to harp on about was re-usability. It seemed like a wonderful concept, writing code that could easily be reused in other applications. The problem here is that reuse had nothing to do with OO, it already existed in the form of libraries, things that were just language, regardless of the OO-ness of the language.

“Object-oriented programming is an exceptionally bad idea which could only have originated in California.”

Dijkstra, E.W. Quoted by Bob Crawford. TUG lines, Journal of the Turbo User Group, 32, Aug.–Sep. (1989)

I mean many people actually believed that software should not be written in any way except using OO techniques. The problem lies in seeing problems only in terms of objects – everything is an object, and that is the problem. A shed is composed of pieces of wood held together with some type of fastener, let’s say nails. A hammer is used to strike a nail into two pieces of wood to join them. While a hammer and a nail are both “objects”, nobody in their right mind conceptualizes them in that way when building a shed. Too often OO becomes mired in discussions on taxonomic metaphysical questions.

At the end of the day, OO, like many other shiny things in computing is just a tool, not a way of life.

Why some students “miss the mark” in computer science

Not doing well in computer science courses, or indeed flatlining in them, seems to be far more common than it once was. There are many reasons for this, and I’ll try to outline some of my perceptions on why some students lack success (this is a follow on to my broader post on student success).

• Computer science is tough – Technology is hard. Visions of become a “game programmer”, living in some gaming utopia are just pure fantasy. Computer science is a life-long learning experience, because technology only ever evolves.
• Not being prepared – Some students now take computer science because it is considered a somewhat lucrative career. Sometimes these students are not well suited to computer science. What do I mean by that? They lack the interpretative, analytical, problem-solving skills that they will need in computer science. Or perhaps they have no programming background, and struggle in introductory programming classes.
• Disliking programming – If you don’t like programming, then you will struggle in computing. Sure, there are quite a few CS jobs that don’t require any direct programming, but you still have to know how to do it. For example, you can’t design software without some innate knowledge of the programming languages underpinning the implementation, their strengths and weaknesses – and you can’t understand that without an intimate knowledge of the language.
• Banking on rote learning – There are some STEM degrees that are little better than extended exercises in rote learning. CS is not one of them – you have to be able to solve problems from day 1.
• Not practising – CS is all about practise. When you learn a programming language, you have to practise writing programs in that language – lots of them. Students that don’t practise, will never become proficient in languages.
• A shaky foundation – Students that barely pass a course that is a prerequisite for an advanced course will struggle. Computer science courses are generally constructive – material from one course will be used as a foundation in the next, and so on. If a student has a poor understanding of a concept, they will struggle with new concepts that build off that “old” concept. For example struggling with stacks and queues in a data structures course could be indicative of not properly understanding how arrays work. This failure to understand basic data structures will manifest in an inability to do understand advanced structures such as trees, and likely create a lot of anxiety.
• Not able to solve problems – Students who don’t like the challenge of solving problems will arguably never be successful in computer science. If fact I would go so far as to say someone that is inquisitive, and likes problem solving will be successful in CS, regardless of their programming experience. Software is simply ideas and concept, problems solved by way of a program which allows a machine to do something. If you can’t problem solve, CS is not for you.
• Taking the easy route – Some people, a distinct few I might add, get through a CS degree using less than scrupulous means. They post their assignments to websites for someone else to do, and find other means of circumventing the system (and they always have an excuse). These people will never be successful, even if they do manage to get a degree.
• Not following instructions – If something says “Do A, then B”, it’s not for anyone to question it. It’s like taking a chemistry lab, and someone deciding it’s a good idea to put sodium into water (and there is always one clod who does). If an assignment says “follow this algorithmen then it means exactly that. There are times to be inventive, and there are times to just follow instructions.
• Not working hard enough – People always put the onus of learning on the instructors… “I didn’t do well because the prof was terrible”. Sure there are bad profs, but the reality is, that the prof isn’t doing the learning, the students is. The student has to put the effort in to learn the material, practise, and frankly try and go beyond what is asked. If someone needs help understanding something, they should ask… but they should also have made some attempt to understand it themselves. Students also have to work outside of classes, doing their own projects to build up their software portfolios.
• Math – Look this is a tricky reason. You have to have a reasonable understanding of math, i.e. you have to like numbers, because computer science is often about numbers, e.g. cryptography, image processing, data science. But you don’t have to be an expert in stuff like calculus – great for theoretical CS, not much use in real life. It’s actually better to have a strong understanding of statistics (and again good problem solving skills). If you don’t like numbers at all, then CS isn’t for you.
• A lack of attention to detail – CS is all about the fine details. Complicated algorithms have to be implemented correctly – the tiniest mistakes can cause gargantuan problems. Someone who is not detail-oriented may struggle in CS.
• Not knowledgeable – Some people are not successful in CS, not because they can’t program (they might be exceptional programmers), but because they can’t think “outside the box”. They may have few interests outside CS, and it becomes all-consuming. To be successful in CS you also have to have interests outside it.

There are also other issues, like challenges in students personal lives, but this is not really specific to CS. The demands of jobs, school, family and friends all contribute to things like stress and depression which in turn impacts studying.

Look, the bottom line is if you are not doing well in computer science it’s time to reevaluate why you are doing it in the first place. If your number one reason is a “good salary” but you lack the aptitude, then it’s time to change to something else. If you are struggling now, you don’t want to make a career of it – nobody wants their software designed/implemented by a CS grad who isn’t good at what they do.

Teach yourself you must

People think a degree in computer science is the path to some Utopian career. Nothing could be further from the truth. First of all you have to have some talent for CS, and have the ability to program, or at least the willingness to learn. Most of all you have to have the ability to solve problems, and think outside the box – if you don’t have that or aren’t willing to build those skills, I would forget about CS as a career. It’s amazing how many people do poorly in CS degrees, because they don’t actually enjoy programming.

All that being said, much of what you likely will learn in a CS program is somewhat nonsensical, and in reality you will forget it as soon as you have learned it. Part of this is because you are not really learning it. You are cramming the information in your mind for long enough to pass the course, then expunging it. Yes, you may retain snippets of information that are relevant to things you are doing, but in the large the rest is likely not retained. A good example of this is all the “breadth” courses degrees make you take. Unless you are super interested in the topic, likely it will just be another box ticked. Like arts degrees that force people to take a science credit – what’s the point? To fulfill some degree mandate?

Even some of the computer science stuff is quite esoteric. Will you ever care about B-trees? Will recursion ever *really* be that useful? What about programming in the language Scarooch? Will you ever learn to develop and implement a large system, or an app? Unlikely, unless you take a project course or something in fourth year, and again mostly teach yourself how to implement an app. Once you know how to program, you could arguably learn more as an apprentice software maker in a company. In all these years, I still don’t understand B-trees, or indeed see much use for them in my work.

Then there is the issue of profs. In my experience, there are very few profs who spend any great length of time actually writing a good amount of lines of code. Most don’t understand what CS really is. They may code in some esoteric academic language, and the closest they have been to app development is when they use one. Some do academic research which is also pretty far removed from reality. Teaching is a side gig, a task they have to perform. In many cases much of the knowledge you pay for at university can be easily found online for free.

You have to go into a CS degree knowing that it will not prepare you 100% for a job. This is likely true of most fields really. Why? Because if you do an apprenticeship to become a carpenter, or plumber, it is a mix of theory and on-the-job training. CS programs don’t really do that – unless you do coop, but then you are learning on the job, in a software company. Sure a university degree will likely teach you some things, but life will ultimately teach your more.