Application Rewrites – Getting Started

Ugh. Imagine you are responsible for leading a project to replace a 15-year-old, complicated, internal business application. No one is happy with the status quo, and the complexity of the application makes this project seem intractable.

You ask yourself, “How did things get this bad? How am I going to get started?”
Read more on Application Rewrites – Getting Started…

When to Call in the Consultants

The decision to contract with a software consulting team is an important one. Bringing in a consulting team like Atomic Object when you don’t need one can be a costly capital mistake. Understanding when to bring that team in and when to let them go is equally important. I’ve recently been using an analogy that I find especially effective in helping potential clients make that call.
Read more on When to Call in the Consultants…

When Should a Startup Hire a Software Consultant?

Atomic Object works with all sorts of companies, from technical startups to established traditional businesses to Fortune 500 companies. We engage each company differently, trying to structure the engagement to best meet the needs of the client.

Startups, in particular, have a number of cost/benefit questions to consider before engaging a consultancy like ours. Depending on the situation, working with a consultancy can be a smart move or a bad fit. Read more on When Should a Startup Hire a Software Consultant?…

Utilize Your Software Consultants to Frame Product Management Decisions

As software product consultants, we’re typically not in a position to take responsibility for significant product management decisions. However, we care a lot about the decisions that are made and want to know that our customers have the best information and context to make their decisions.

At every stage in a project, from sale to delivery, we can provide important information to help frame product management decisions. Below are a few things that a good software consultant brings to the table when product management work needs to get done.
Read more on Utilize Your Software Consultants to Frame Product Management Decisions…

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?…