So the name of the first chapter is “A Pragmatic Philosophy”. And the Authors say this as a philosophy of approaching problems and their solutions. Pragmatic programmers think beyond the immediate problem always trying to place it in its larger context to be aware of the bigger picture.
This sounds great, right? And right up our alley. This highly correlates to the Strategic mind of software design described by Prof. Ousterhout. He describes the strategic mind as one that thinks about the future impact of the code, code reuse and not increasing the complexity level. It’s going to be interesting to see the correlations or things that set this book apart from Clean Code or A Philosophy of Software Design.
But alright, the first section in this chapter is called: The cat ate my source code haha. I indeed remember some funny titles in this book. What they mean with this title is that you as a professional game developer must take responsibility. You take responsibility for your work, but also for your career and learnings. You’re also not afraid to admit your mistakes or ignorance. So even you practice TDD some weird edge-cases might slip through and create bugs. These things happen and you need to be able to be honest and take responsibility for them. We all make such mistakes they are part of being human. So be proud of yourself, and be honest about shortcomings.
Being part of taking responsibility is that you should provide options and don’t bring lame excuses. That’s true. Lame excuses don’t belong in a professional workspace. For example, I can still hear old classmates say that all of their code is gone after their IDE crashed. This is just a lame excuse for them haven’t done shit and went out partying the entire weekend or playing video games. Everyone knew it back then, and where this might have been “acceptable” in school it’s certainly not acceptable on the job. Since there are a lot of people and money involved.
So instead of excuses bring options. Don’t say something cannot be done but explain what can be done to salvage some solution. There are often multiple things that can be done to fix some situation no matter how bad it is. Not every option might be nice to hear but still the options are there and they can be well considered.
The next section is called Software Entropy. This is such a cool title right? Software Entropy is essentially just the complexity creep Prof. Ousterhout has talked a lot about in his book A Philosophy of Software Design. Uncle Bob will call this dirty code or rotten code. Software entropy is really the reasons why clean coding practices are such an important skill to have as a programmer. So thank the software gods for writing such amazing books about this topic.
Many factors impact software entropy. Where the most important one seems to be psychology or culture at work on a project. Isn’t that interesting? It’s not skill, education or experience but psychology and culture. But it makes total sense right? I mean, if the entire team says; “we don’t write unit tests because it slows us down” then the culture of the project team just confirmed that tests are worthless and thus you end up with a codebase without a test suite. Or maybe, when you have some toxic project manager who’s micromanaging everything the culture will be impacted a great deal as well. Everyone will be stressed out and on the edge of their chair all day.
In the book the have a very nice analogy about how buildings start to decay. So there are many very nice, clean and beautiful buildings in a city. But there are also dirty, broken down and abandoned buildings in a city. According to researchers in the field of crime and urban decay the biggest indicator or trigger of a building starting to rot is just a simple broken window. If the broken window is left unaccounted for too long, then the building will get abandoned and start to break down entirely to turn into a rotting hulk. People don’t repair it because it looks like no one cares.
So don’t leave broken windows in your code because this will lead to software entropy. Broken windows can be many things like bad designs, wrong decisions and poor code. Generally, any kind of technical debt might qualify as a broken window. Try to fix these things as soon as possible. Put them on some schedule at least so people know what’s going on and they get tracked in your project management software. Don’t just leave them around and wait for the entire project to crumble. People will care about the project.
The next section of the book is called Stone soup and Boiled Frogs. I told you these titles were interesting right? This section is essentially about two things; Being a catalyst for change and remembering the big picture.
There will be these moments where you or your team needs to build some game. But in this particular case, you know exactly how to do it. You’ve seen and experienced the Matrix at this point. You know how to tackle the problem, how to implement it and how to verify it. But now you must ask your superiors or some other committee for permission to do the project. And they will defend their resources. This is what the authors call “start-up fatigue”.
You as a pragmatic programmer must then negotiate some minimum viable project. And then develop it well and present it to them in such a great way that they will say “of course it would be better if we added features x, y, and z”. These features are ones that you recommend to them and thus you still end up with the project you had in mind in the first place. So be the catalyst for change and don’t stay idle or waiting for too long. Take responsibility and let your voice be heard because you were hired to do exactly that.
But also, remember the big picture. Don’t fall for the over-engineering trap for example. Try to remember why some project is started and what problems it aims to solve. Of course, software evolves and grows to maybe solve a totally different problem. Like when you have to pivot your start-up for example. But try to keep your eyes on the price and don’t stray off to some remote destination.
In the book they again have a nice analogy for this, boiling a frog in a pan of hot water. Hence the frog in the title of the chapter. It’s generally known, but I’ve never tried this personally that; if you throw a frog into a pan of boiling water the frog will jump right out. But if you put the frog in cold water and gradually heat the pan up until it reaches the temperature to boil, then the frog will stay in there. So, the frog definitely does not remember the big picture. It got distracted. Don’t be the frog.
Next there is a section that is kind of popular. You may have heard of the term “Good-Enough Software” before. It’s not originally from this book but from an article in IEEE software by Ed Yourdon which goes as follows; “You can discipline yourself to write software that’s good enough – good enough for your users, for future maintainers, for your own peace of mind. You’ll find that ou are more productive and your users are happier. And you may well find that your problems are actually better for their shorter incubation.”
But what exactly does “Good-Enough Software” mean. This might be highly subjective, right? I mean good enough should not imply sloppy, poorly designed and produced code. Well the authors make the case that Quality should be on your requirements list. And this comes right back at us right? We have been talking about code quality for a long time now and I think we know what “Good-Enough Software” and Code Quality means. We’ve discussed this in-depth while digging into the Uncle Bob’s Clean Code and Prof. Ousterhout’s Philosophy of Software Design. But on the other hand, the authors make two interesting cases in this book which we have not discussed to great length yet. And that is to involve customers into the trade-offs you need to make and secondly you need to know when to stop and don’t over-engineer something.
Usually, you will make software or a game for someone else. We all get requirements which we need to translate to a working game. Sometimes though, we do not get requirements about how “good” the software needs to be. I mean, if you are working on software for pacemakers or maybe software that is launched into space the term quality takes a totally different form. But what the authors rightfully note here is that quality should be part of your requirements. It must and will always be important because if quality is not high up the ladder, your game will suffer in some form or another. However you should not be overzealous about it. Don’t strive for perfection because you will never get there. In software, there is always room for improvement. It’s like trying to reach 100% test coverage. You can try to reach it but you never will, it’s an asymptotic goal. And on the other hand, the authors tell something else which I find fascinating and I quote: “Surprisingly, many users would rather use software with rough edges today than wait for a year.”
This really sounds like our industry right? How many times have you signed up for some beta access of a game? A lot of people do that nowadays, just because they don’t have the patience to wait. But I guess that’s also more of a western or cultural thing, but yeah… Many people will agree that we rather have great software today, than perfect software next year. And this is very true because it is what Agile workflows are all about. We create minimal products and then ask around for feedback and iterate on it to improve it.
So there’s a constant flow, or a trade of software and feedback. This is how good enough software is developed. Based on this process it also becomes pretty clear when you should stop or pause development of some game.
The authors compare software development to painting in this analogy. With painting you start out with a blank canvas and raw materials. Then you think of something you want to paint, make some rough sketches and start painting to fill in the details. Painters also have the habit of constantly stepping back to view the bigger picture, literally. This allows you to have critical eye to view the work you have done. And how often have you heard some artist talk about how it is crucial to know when stop paining or the the painting will be ruined? I know I have. At some point the painting is just done, and any more edits to it will only ruin it or make it worse.
So don’t spoil a perfectly good game with over-engineering or endless finetuning. Move on and let the code stand in its own right. And this is so true, I couldn’t agree more. I’ve had these moments where some game or software was essentially finished. It matched all requirements and did exactly what I wanted it to do. But I kept working on it to improve the structure of the code to fit some design pattern better. No one really wanted it since it did not really improve the system that much. But I did, because I thought it would make it even better than it already was. So maybe, I shouldn’t have done it. But yeah.
Next time we will continue chapter 1 with advise on keeping a portfolio.
Bye!
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments