One of the keys to getting good quality out of software development is to control the scope of each line of code carefully. This connection isn’t particularly intuitive, but it is strong and useful. We can loosely define the scope of any piece of code as the percentage of other lines of code in the system that ‘might’ be affected by a change to it. In the simplest case, if you comment out the initialization of the connection to a database, all other lines of code that do things with that database will no longer work correctly. They will error out. So, the scope of the initialization is that ..read more

The idea is to express the instructions to the computer that you’ve crafted in a succinct but entirely verifiable way. If the expression is huge, the size itself will cripple your ability to verify that the instructions are correct. If the expression is shrunk with cryptic syntax, maybe when you write it you will remember how it works, but as time goes by that knowledge fades and it will cripple your ability to verify that it is correct. If the expression is fragmented all over the place, the lack of locality will cripple your ability to verify that it is correct. Spaghetti code or scrambl ..read more

I’ve seen many, many variations of programmers reacting to what they believe is over-complexity. A common one is if they are working on a massive system, with a tonne of rules and administration. They feel like a little cog. They can’t do what they want, the way they want to do it. If they went rogue their work would harm the others. Having a little place in a large project isn’t always fun. So people rail about complexity, but they mean the whole overall complexity of the project, not just specific parts of the code. That is the standards, conventions, and processes are complex. Sometimes t ..read more

There is something hard to do. Some of the people involved are having trouble wrapping their heads around the problem. They get some parts of their understanding wrong. In small, subtle ways, but still wrong. Then they base the solution on their understanding. Their misunderstanding causes a clump of complexity. It is not accidental, they deliberately choose to solve the problem in a specific way. It is not really artificial, as the solution itself isn’t piling on complexity, instead it comes from a misunderstanding of the problem space, thus in a way the problem itself. This is mangled c ..read more

A good decision in a software development project is one that moves you at least one step closer to getting the work completed with the necessary quality. A bad decision is one where you don’t get a step forward or you trade off a half step forward for one or more steps backward. Even a fairly small software development project includes millions and millions of decisions. Some decisions are technical, dealing with the creation or running of the work. Some are usability, impacting how the system will solve real problems for real people. A well running software development project mostly make ..read more

You know the final version will be very complicated. But you need to get going. It is way too long to lay out a full and complete low or medium level design. You’ll just have to wing it. The best idea is to rough-in the structure and layers first. Take the simplest case that is reflective of the others. Not a “trivial” special case, but something fairly common, but not too ugly. Skip the messy bits. Code the overall structure. End to end, but not fully fleshed out. Then take something it is not yet doing and fill in more details. Not all of them, just more. If there are little bugs, fix th ..read more

Major points: Coding is always slow Coding produces both code & bugs The code always needs to be edited, the first version is just roughed in. Do not use disposable code in industrial strength projects. The primary goal is to produce a minimal amount of readable code. You want the code to be as small as possible, it is easier to deal with. Larger codebases are worse, not better. You want the code to be as readable as possible so it is easier to edit. If it is a choice between small or readability, readability wins. If it is a choice between readable or performance, readability wins. Y ..read more

Naming is hard. Very hard. Possibly the hardest part about building software. And it only gets harder as the size of the codebase grows, since there are far more naming collisions. Code scales very, very badly. Do not make it worse than it has to be. This is why naming things correctly is such a fundamental skill for all programmers. Coding itself is oddly the second most important skill. If you write good code but bury it under a misleading name, then it doesn’t exist. You haven’t done your job. Eventually, you’ll forget where you put it. Other people can’t even find it. Tools like fancy I ..read more

Given a large problem, we start by breaking it down into smaller, more manageable pieces. We can then solve all of the smaller problems and combine them back together to solve the original problem. The hiccup is that not all decompositions are created equal. If you break a big problem down into subparts, when they have any sort of cross dependencies with each other you can’t work on them independently. The dependencies invalidate the decomposition. So we call any decomposition where all of the subparts are fully independent a ‘natural’ decomposition. It is a natural, complete, hard ‘line’ th ..read more

“Calling something an anti-pattern is an anti-pattern.” There are lots of ways to accomplish things with software. Some of them are better than others. But the connotation for the term ‘anti-pattern’ is that the thing you are doing is wrong, which is often not the case. Realistically, the ‘pattern’ part of the phrase is abused. A design pattern is just a generalized abstraction of some work you are doing. It is less specific than an ‘idiom’. It is less specific than a ‘data structure’. It is just essentially a code structuring arrangement that is common. That is, it is effectively a micro-ar ..read more