Choosing technology has a huge impact on a team’s performance, and when you are starting out, you have a lot of decisions to make. We often get hung up on technical features, or weather we should use a framework or a bunch of libraries. The reality is you have to gain a deep understanding of the business realities coupled with your team’s values. From there, you then evaluate your startup cost (opportunity cost) against the cost to maintain the system over time (carrying cost) to arrive at the best decision. Technical features are a part, but a small one.

Martin Fowler recently tweeted a link to his blog post about Kent Beck’s four rules of simple design, which I think could be improved upon (and, which can lead programmers down the wrong path at times):

Kent’s rules, from Extreme Programming Explained are:

• Runs all the tests
• Has no duplicated logic. Be wary of hidden duplication like parallel class hierarchies
• States every intention important to the programmer
• Has the fewest possible classes and methods

In my experience, these don’t quite serve the needs of software design. My four rules might be that a well-designed system:

• is well-covered by passing tests.
• has no abstractions not directly needed by the program.
• has unambiguous behavior.
• requires the fewest number of concepts.

To me, these flow from what we do with software.

I take GitHub’s new security vulnerability notifications seriously, and try to patch my apps whenever something comes up. I recently had trouble doing so for a JavaScript dependency, and uncovered just how utterly complex management of NPM modules is, and how difficult it must be to manage vulnerable packages. And I’m left wanting. I’m also left more concerned than ever that the excessive use of the NPM ecosystem is risky and dangerous.

In the imagined Timeline Programming Language, there are some unusual restrictions on the type of code you can write. I thought might be worth seeing if they can help us with real code. I find that when you apply constraints to your work, you often get forced into novel solutions, and occasionally even superior ones. So let’s take Timeline’s restrictions on expressions. In Timeline, you cannot have a compound or nested expression, and the only thing you can do with an expression is assign it to a variable. You cannot use them in control structures, return statements, or method invocations.

I gave a talk at Pittsburgh Tech Fest that I’d been wanting to do for a while, which is a talk about how to program a time machine and what the programming language for it might look like. I re-recorded the talk.