Software applications (like homes, cars, and nearly everything else) need maintenance. Even when the software itself doesn’t change, the systems/devices it runs on and the larger software environment are always moving forward. This is called Software Rot. Most software maintenance falls into one of these categories: Updating Dependencies – Upating the frameworks, libraries, etc. that […]
Software rots if not maintained. The longer it sits on the shelf, the harder it becomes to work on it. It may even stop working on its own one day. This surprises my clients frequently, so I wanted to talk a bit about why this happens and how to plan for it.
Recent projects have made it crystal-clear to me that formal code reviews create waste and provide no value in return. By relying on pair programming, my project teams are delivering more effectively and efficiently than before.
Frameworks are constantly changing and evolving—especially open-source ones, which we rely heavily on at Atomic. And it’s not always easy to stay up to date. Updates sometimes deprecate APIs or introduce new architecture patterns. These changes can require significant rework of a project, and they are expensive for customers. Nevertheless, updates are worth it. In […]
If you experience sudden, drastic changes in the behavior of a piece of software, you should immediately suspect reaching some limit, threshold, or quota. I spend a great deal of my time supporting and troubleshooting software deployments. Generally, if a piece of software has been running without issue for a substantial length of time, any […]
Yes, really. How do we know that software we build actually works? How can we know that it works? What observations and actions contribute to a holistic, fact-based, confident understanding that software I just helped build does what it was intended to? I want you to feel a little anxiety about that question. Forget for […]
A successful software project consists of much more than actually writing software. There are product development concerns, usability concerns, aesthetic concerns, and, of course, delivery concerns. It often seems that the delivery phase of software development project is neglected. The product is valuable, the design sleek, and the code well-written and tested—but the final handoff […]
In my previous post, I briefly went over some well-known industry terms. In this edition I’d like to touch base on some internal jargon that, as far as I know, we use specifically at Atomic Object. Software Industry Terms Generalist Yeah, this is pretty much what you think it is. A Generalist is a person […]
Being a non-tech person working for a Software Development company, I hear a lot of things around the office that sound like another language to my ears. In an effort to join the conversation and understand more about what we do, I’ve decided to take it upon myself to create a glossary of terms. Since there are so many […]
Carl Erickson, our CEO, said it best: I think one of Atomic’s unspoken values is that of validation. We don’t assume; we show. We experiment to learn. We don’t rest until we can show we’re done, and it’s done right. Through validation, we drive out as much risk as is possible and makes sense.