Jonathan Blow - What went wrong in software development

Excerpt from indie video game developer Johnathan Blow's Twitch channel where he discusses his opinion on how and when software development went wrong, how CS theories progressively branched off from practical, real-world problems, adding layers of abstractions where it wasn't needed.
Jonathan Blow is currently building the Jai language, meant to replace C++ for developing video games. He is concurrently developing a game using that language.

[neildutoit]

I honestly think frontend devs are the biggest propagators of the BS these days. Used to be Java people but now it's React devs. Worked with a React dev on last project, expert with 10 years of experience at top companies. This guy puts together this system with all these hierachies and integrations and plugins and libraries and you can see the guy is smart and his code is neat and what what but ultimately he could not get the interface to display what it needed to display. I eventually took over, knowing only the very basics of vanilla javascript (I'm a backend dev), and got solved the problem with a few lines of HTML and vanilla. What frontend devs either don't realise, or purposefully ignore, is that a website consisting of 5 pages is not a system. It does not need a system architecture. It does not need a philosophical model. It does not need 10 layers of abstraction. It's a few rectangles that need to be put in the right place and you can put them there with a script.

[bikeaday]

Solving a few obvious future problems up-front or planning to do so is okay. Solving every possible future problem up-front is just not reasonable. It took me a long time to learn how to not over or under abstract my code.

Analysis paralysis = too much abstraction.
Maintenance nightmare = not enough abstraction.

[jftsang]

You mean my class isn't doing anything concrete? But it uses design patterns!

[asdqwe]

People are too afraid to throw stuff away. Sometimes you need to write something to know what is wrong. People put so much prestige in their first designs

[liwenchang]

Have a coworker who is a syntax wizard and throws the most advanced syntaxes like variadic templates and type traits for just to make a c++ wrapper on an existing messaging C library. He worked on this for an year and discovered the his software is taking a lot of CPU usage and leaks memory in production systems. Instead of identifying the keypoints and how to design an efficient messaging system, he choose to stick to the original concept and spend his time working on nonexisting architectural and rather religous problems. He kind of fend off the responsibility by saying the performance is bad because the library he is using is too slow. But I would argue that the whole point of software engineering is to tackle those kind of problems and not create super advanced OOP architectures which no one can understand or maintain.

This reminds me of a motto that our company praised :"Doing the right thing is more important than doing something right."

[MartinMaat]

To me this is all moot. No one claims OO is algorithms. It helps to control complexity and helps communicating about software. Anyone subscribing to this message has never had to modify or extend existing code. In the end everything up from machine language is overhead. But it serves a purpose nonetheless.

[callmedeno]

It has gotten quite absurd.

I remember first year of college was good it felt like you were attacking problems using computers. It was going to be object oriented but at that stage we hadn't been taught the deep hierarchy of bullshit. I finished college but after years of seeing in the industry that this was in fact what building software was I completely turned off it. Something felt extremely wrong, it was as if writing code had become pseudo if not de facto Category Theory (before I knew what that was), and my interest for it wained and I ended up getting very little done while hating everything I did do. More recently after seeing some successful people show that there is another way I have dabbled again but I'm realising it will take a while to approach things in a simpler way once you've been taught to model the complexity first.

[dwayneyuen]

I like the underlying message. write the code then derive the abstraction. Don’t try to predict the abstraction.

[benhbr]

Premature optimization not only happens for compute time, but also development time. It‘s called refactoring, not factoring.

[danielkrajnik]

I agree with you, you incredibly buffed programmer

[apresthus]

I wholeheartedly agree. When I started programming I naturally programmed in a functional or procedural style but since everyone told me that you have to write OOP code I tried to conform to what "everyone" said was best. Most often than not I would get annoyed at spending most of my time conforming the style and structure to fit the accepted mold instead of actually just focusing on the core business logic if you will of the program. Ironically, it was when I had to learn Javascript to write web apps that I slowly started to escape from the cult. I went back to writing functional or procedural code. It felt much better and it sparked me to go and learn C properly. Strip away all the bullshit and just create cool stuff while maintaining control. I'm loving it! :)

[shableep]

solve the problem. keep solving problems until it becomes hard to maintain, then abstract. it’s sort of the same advice as “don’t optimize your code before it needs to be optimized.”

[toosafelol]

I do program the way you describe. I always hated having to design my whole program before a single line of code was written(as they teach you at school).
I just kinda go at it and refactor my code multiple times along the way to end up with a good readable and stable result/solution. We used to call it cowboy programming.

[HerbertLandei]

This sounds nice, but it doesn't scale. You need some kind of abstraction and structure, one core sets of ideas to have a readable, maintainable, performant and extendable system. You need to separate more higher level stuff from the nitty gritty details. OO might be the wrong tool for your particular system, there might be dogmatic BS nobody needs, but you need something to prevent your code from becoming a Big Ball of Mud (tm).

[rsmith]

Richard Hamming said "The purpose of scientific computing is insight, not numbers", so in the same vein, the purpose of programming is solving problems, not writing code. Writing code is only incidental and the complexity of a large proportion of the code being written today is not commensurable with the difficulty of the problems that it is supposed to solve.

[hyperTorless]

John is a smart man, not in the intellecual/theoricist sense (we call them "IYI"), but in the sense of a pragmatic guy who knows how things actually work. FYI he is building a whole new language (Jai) to replace C++ for developing video games. He is building a game with it too.

[RonWolfHowl]

Unpopular opinion: Modeling the problem space is important. What’s uncertain is whether that ought to be solved in-band with the rest of the program—the part that is actually executed at runtime. Doing so in-band can give you superpowers, but if done wrong, it can waste monumental amounts of time.

[KilgoreTroutAsf]

Brian Will has a brilliant video on why OOP is downright terrible.
Good abstractions take long time and lots of iterations to develop. Starting a program by imposing structure that you don't know for sure helps you solve the problem instead of just writing the minimal procedural code that actually solves the problem and refactoring later is not only a waste of time, but also adds incredible amounts of friction to the developing process.

[GroverAU]

Honestly when I came from electronics/PLC programming in the early 90's into the C/C++/Java space I thought people had lost their minds. For me, I work on the Input -> Function -> Output mechanism. And that you should be _doing_ something with a tangible result. Its why I prefer data driven programming paradigms like FBP where there is a clean "connectivity" for the program and the data simply stimulates the program. But I never see this in the wild... usually _so_ much replication, and conversion its crazy.

[GregoryTheGrster]

The nifty part about C++ is that the developer can decide how much he wants to go into OOP and OOD abstractions, including none at all (ie, procedural programming, or at most abstract data types).