This text is a reaction to this micro blog post:
early-career people should take the time to download and look at the leaked farcry code. not to learn some new technical lessons, but to disabuse themselves of the notion of “clean code”. nicebyte
From reading more of the thread, my interpretation is: “You don’t need good programming practises to make money from software.” That might be true, in some circumstances, but to make it an “early-career”-advice I would like to add some perspective.
First I want to separate internal and external software quality, as described in this post. Internal quality is from a developer perspective, external quality is what the user sees. They can be more or less dependent of each other, but have different effects.
J.B. Rainsberger has a talk on “The economics of software design” (video). There he introduces t0, the point in time where the total cost of having written the code is the same regardless of if we just did it fast and sloppy or slower and intentionally sustainable. We don’t know when t0 will be, but it exists for every project. After t0 you reap the profit from having continuously improved the code since the start. In just implementing features as fast as possible, we bet against the project surviving past t0. We only save money by not caring about “clean code” if the project does not reach t0. The t0 measure is about the value of internal quality.
It is interesting to use a game as an example for when internal quality is unnecessary. Games are one of the few kinds of software still distributed on physical media. I believe that a lot of games change less over time then other software. The cost of a messy codebase come when we want to edit it. Bugfixes in a feature complete codebase can be plastered on, as long as the code do not move.
In my post on useworthiness I talk about how utility and usability mix to decide if software is worth using. If we can not add new features utility will suffer. Usability will be a problem if the internal quality problems show as external quality problems, or slow down improvements in user experience over all.
For games that change more over time, like Pokémon Go, the condition of the codebase matters, and will start to show. Niantic has publicly stated that they have quality problems. In Pokémon Go the problems shows as defects, delayed features and draining of the users resources such as mobile data and battery. All of that results in lower external quality.
The gamble here is both with t0, “will the project die before the codebase does?”, and with the users tolerance for unreliability, in relationship to how the game makes money.
This is why my “early-career” advice is:
Find work where they care about code quality.
It will be better for your mental health as well, but that is for another post.