#begin

While You Are Coding

David and Andrew start new this chapter (6) off with a very shitty and outdated way of thinking and I’ll quote: “Conventional wisdom says that once a project is in the coding phase, the work is mostly mechanical, transcribing the design into executable statements.” Haha, I mean: that screams WATERFALL very loudly.

Being pioneers, Andrew and David quickly disregard this notion, of course. They say that this is the single biggest reason why programs are: “ugly, inefficient, poorly structured, unmaintainable and just plain wrong”. As I mentioned before, this is what Prof. Ousterhout will call tactical coding.

Coding is far from mechanical. As Dave Farley says, Software engineering is a creative process, a design process. It’s not some mechanical process with a focus on production. It’s focus lies on design and idea generation and applying these ideas in a structured manner. These ideas require careful thought and judgment and Andrew and David say that people who do not think about their coding, are programming by coincidence. So they will spend some time on explaining how one would spend careful thoughts about their coding.

This also involves algorithm speed,the O() notation and of course refactoring, testability and the evil wizards we discussed before. We shouldn’t write code on autopilot, like we sometimes drive our cars. A good driver is always analyzing the environment and anticipating situations as they unfold. We need to apply that to coding. As David and Andrew say: “It may largely be a routine but keeping your wits about you may well prevent disaster.

Programming by Coincidence

So let’s investigate what Andrew and David think is programming by coincidence and how we as pragmatic programmers can become more deliberate about or coding. They start this chapter of with this weird analogy of old war movies where people are poking the field looking for landmines. Once they think it’s safe, they take a run for it and of course get blown to pieces. They say that we as developers work in such minefields sometimes as well. There are many traps lurking out there for you and we shouldn’t draw false conclusions. We should avoid programming by coincidence

I think it’s funny how they mention ‘old’ war movies, yet this book was written in 1999 and this minefield cliché in movies is still going strong haha.

Next they talk about imaginary programmer Fred who’s given some assignment to code up something. He starts coding, and it seems to work. Then programs some more and it remains working. Several weeks later, and having written shit tons of code, the code stops working. And Fred has no idea why. After spending a hours upon hours trying to fix it, he still can’t figure out why the code is not working.

Andrew and David make the case that, Fred doesn’t know how to fix the code, because he doesn’t know how it works. Fred did not write any or at least not nearly enough tests to know how the code works. And, driven by coincidence, Fred moved lightning fast like a rudderless ship.

And this is exactly what Uncle Bob warns us for in Clean Code. His first question giving some Clean Code presentation is this: “Who has been significantly slowed down by bad code?” I can hear him saying it, by quoting him haha. This is also what Prof. Ousterhout refers to as tactical programming. Being fully focused on the task at hand, not thinking about future implications.

Accidents of implementation

David and Andrew list a couple of reasons why programming by coincidence can occur. The first one being that Fred’s code was driven by accidents of implementation. This happens when you are relying on undocumented error or boundary conditions. Fred wrote the code, using internal libraries or maybe using external libraries. Yet he doesn’t really understand how this code works. For example, he doesn’t know in which order to call functions, remember temporal coupling? But he might also just not know what each function does because of a lack of documentation. Why should functions be used and what do they actually do?

In the end Fred gets the thing working yet he has wired all kinds of functions together. At this point he’s even more unaware of what the hell the code is doing and he’s afraid to remove some of the code to backtrack his decisions. As Uncle Bob would say; “Fred has become afraid of the code that he wrote. Which is wholly unprofessional.”

David and Andrew say that Fred really should dive back into the code and fix it because: It may not really be working, or some boundary condition Fred is relying on is just an accident. Some undocumented behavior might change in the next release and all these additional calls will slow down the code and will increase the risk for bugs.

Accidents of Context

The second reason why Fred’s code is shit is because Fred is relying on some context, the wrong context. By this Andrew and David mean that the context in which the code is used might impact or pollute your mindset while writing it. For example; if you are writing an inventory system for your game, should that system rely on your UI or Database for storage? Of course not! The UI and Database should be plugins to your inventory code. But what if your inventory system fully integrated and depended on UI and Database code? Your inventory will become a large steaming bowl of spaghetti. And, we all know what monster is hiding in that bowl!.

So don’t let the context in which your code is used pollute your design. And yes, there are scenario’s where the context will impact your code and these will be carefully thought through. You can’t always separate this but you can put mindful thought into making sure you took action to lessen the impact.

Implicit Assumptions

The third reason why Fred’s code is a big steaming bowl of spaghetti is because he made implicit assumptions. Andrew and David say that coincidence can mislead on many levels. They also say that and I quote: “Testing is particularly fraught with false causalities and coincidental outcomes. It’s easy to assume that X causes Y. Don’t assume, prove it! Assumptions are rarely documented and often conflict between different developers. “Assumptions that aren’t based on well-established facts are the bane of all projects.”

I think they are so right here. Assumptions truly are a massive cause of bugs in software systems. Imagine working in a code base without any tests; it’s all just assumptions at that point, right? When bugs occur its just hack and slash to fix it, building upon your assumptions. In the end, you might fix some bug, but the reason why its fixed or why the bug manifested in the first place lives inside your brain. If you didn’t first write some test to capture and reproduce the bug; that assumption is just yours, and it’s not encoded in the source code.

How to Program Deliberately

Andrew and David then give us some tips on how one should program deliberately. So how would Fred fix his shitty code? Well they say that as a developer, you should always be aware of what the hell you are doing or you will end up like the boiled frog we talked about some episodes ago. You also shouldn’t program blindfolded. Meaning, you don’t want to program an application or game you don’t fully understand because that will lead to programming by coincidence. Always proceed from a plan, however small or large that plan might be. Don’t just start of slinging code like a cowboy or girl of course. You should also rely, on reliable things. Haha yeah, that one seems obvious! Don’t rely on assumptions or accidents. Document all your assumptions somewhere, or better yet, design by contract! This helps communication your assumptions to others which will make the system more robust. And don’t just test your code, you must also test your assumptions.

Let me give you an example of how I test my assumptions recently. I wrote this neat little library to work with Unity3D resources. I wanted to extend the resources API with the capability to query all resources in your Unity3D project, and its package dependencies. My editor plugin also wraps the built-in functions provided by Unity3D like Resources.Load(“MyAsset”);. Now, I’m pretty sure that the Unity3D team wrote unit tests for this API, if not, shame on them. But I wrote a number of tests to confirm my understanding of the resources API. And interestingly I found some suspicious things like I could create resources with the exact same name, yet different types and they would have unique ID’s! This is really weird since the file system of your operating system should prohibit this. There can’t be files with identical names, yet unity allows this somehow haha. Well, at least my test happily passes. You can find Better Resources on this website under projects. But let’s get back to the book.

Andrew and David also say to prioritize your effort. You should spend time on important aspects and these are likely the hard parts. Haha Yeah, how often have you postponed the hardest part of some project till the end only to realize that because of how the system is build it’s become even harder to implement. You will often see that the first 90% of a project go relatively quickly, but going these last 10% takes a very long time. Spend your time early on the fundamentals, because without proper fundamentals it’s really hard to build a house.

And lastly they mention that you shouldn’t be a slave to history. Don’t allow existing code dictate future code. All code can be replaced when it’s no longer appropriate. And although I think they’re right, this point should be taken with a grain of salt. Sometimes you really do need to implement with existing or legacy code. In this case you should keep this integration layer isolated and as thin as you can. The way this integration layer written is probably dictated by the existing code, but once it leaves this boundary it should no longer have to. So be aware of this.

And this wraps up the first section of this chapter; Programming by Coincidence. I think we’ve learned a lot of interesting things like programming by invalid assumptions, wrong context, and wrong implementation. I feel bad for Fred and I hope he takes up the tips given by Andrew and David to straighten and decomplect that steaming bowl of spaghetti!

#end

01010010 01110101 01100010 01100101 01101110