Three Reasons To Keep Your Frameworks Up To Date

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 the long run, the expense of keeping your project’s technologies up-to-date greatly outweighs the cost. Read more on Three Reasons To Keep Your Frameworks Up To Date…

Diagnosing Problems: Limit, Threshold, and Quota

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 drastic behavior change that’s not related to a service interruption is due to reaching a threshold or limit. These thresholds could be very simple (no more disk space), or more subtle (an API starting to rate-limit requests). Below, I’ll mention a few of the different limits I’ve run across, and some common patterns of observed behavior. Read more on Diagnosing Problems: Limit, Threshold, and Quota…

How Do We Know Our Software Works?

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 moment that you’re working with smart people who participate in practices that help bolster your confidence. Instead, dwell on the frightening reality that people are flawed and make mistakes on a regular basis. Human communication is always incomplete, good intentions don’t guarantee good results, and it can be genuinely hard to build a broadly-shared mental model about how a problem should be solved. How do we have any confidence that our software works?! Read more on How Do We Know Our Software Works?…

DevOps – Software Delivery Done Correctly

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 and deployment have been neglected. The problem is, “‘dev complete’ is a long long way from ‘live, in production, stable, making money'” (Nelson-Smith, 2010).

In recent years, the DevOps movement has emerged as a response to some of these problems—improving deployment and management of software that has already been written. Read more on DevOps – Software Delivery Done Correctly…

6 Reasons to Build a Firmware Test Suite

At Atomic, we build a lot of systems that incorporate device firmware talking to software. We also commonly interface with other firmware or software teams.

I believe every project that involves firmware talking to software should include a high-level suite of tests that are written against the firmware’s interface to the software (e.g. Bluetooth, Ethernet, USB, etc). Read more on 6 Reasons to Build a Firmware Test Suite…

Technical Spikes – Rehearsing Your Software

At AgileConf 2014, John Krewson presented “The Show Must Go On: Leadership Lessons Learned from a Life in Theater” in which he outlined parallels between the stage acting and software development. Among his points on how project management is like directing and hiring is like casting, John remarked that when a director is preparing a performance, they don’t assemble the actors, distribute scripts, and say, “We’re all professionals. See you on opening night.” Even when everyone on the team is an A-lister, they still need to rehearse.

The same goes for software development.

Read more on Technical Spikes – Rehearsing Your Software…