I’m working on the algorithm for automatically generating and updating project schedules according to Critical Chain principles. Using a set of random, dependent tasks (represented by an identifier and estimated time), I can create a full schedule that identifies the critical chain, adds the necessary buffers, and sets the start dates for tasks. Special considerations […]
Category: Software Engineering
Technical Choices
I’ve been heads down researching and prototyping. Much of that work was deciding on the tech I’m going to build with. There were a few main criteria I’m using: Clojure There wasn’t much doubt that I’d build with Clojure. It’s been my main language for many years now. It’s productive and enjoyable to work with. […]
Residuality Theory Barry O’Reilly Summary Barry O’Reilly presents the problem as trying to determine what makes a good architect. Why do some architects succeed in conditions of high uncertainty yet others fail to find similar success? Engineers build ordered, structured, simple software and then put that software in a dynamic, unstructured environment. Barry defines Stressors […]
There’s only one reason we should ever trigger alerts: There is a failure or risk of failure we should act on. Everything else is just noise. It’s common to trigger alerts for non-failure situations or errors that require no action: In each of these situations, the alerts are just noise because there’s no action required. […]
Designing a service can be intimidating. We sit down with only an incomplete list of requirements, our wits, and previous experience. How can we have confidence that our design covers the given requirements, is flexible in the face of inevitable changes, and doesn’t miss large areas of risk? Start by asking good questions. Whenever I […]
Everyone says they want to fix tech debt, but, in my experience, almost no one really tries. Every developer at some point, probably If product owners and stakeholders can’t see the gain (or avoidance of loss) in fixing technical debt, we’ll be stuck with whatever random percentage of effort they set aside for it. Incidents […]
“Service” and “server” are basically the same word, so it’s reasonable to question the difference between the two. Services are abstractions we use to discuss our architecture. Servers are the hardware we use to run our system. They overlap in different ways, depending on what we’re trying to accomplish. One-to-many; One service == Many servers […]
Why do people bend over backwards to complicate simple logic and architecture? A developer complaining about code reviews Reviewing code can be painful. We set aside our work, switch into someone else’s context, and then put time into providing useful feedback. It’s frustrating when other developers reject our simple suggestions and fight to justify their […]
Depending on your team or the reference you’re reading, it can be easy to get confused on all the environments you need. There are no universally agreed upon names, and the same environment can be used in different contexts. To clear the confusion, here’s a pattern for how to think about dev environments. Your dev […]