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

Maximizing Value Starts with Truly Understanding the Client’s Needs

Every step along the path to delivering a software project is a trade-off. Time and/or money are in short supply relative to the vision for a product, and every decision must be made with care. Moreover, there’s no one “correct” way to design or a build a feature—there are many possibilities, each with their own cost, time to implement, possibility for reuse, desirability, and maintenance burden.

Read more on Maximizing Value Starts with Truly Understanding the Client’s Needs…

3 Design Techniques for Non-Designers

Design and design thinking can’t solve all of the world’s problems. But design is noticed by others, whether your company/product has considered it or not. And design can make your product more usable and accessible.

From your website to your physical space to the way you respond to emails to your actual product or service, it’s worthwhile to ask yourself, “Is this designed the way I want my customers or users to experience it?” Read more on 3 Design Techniques for Non-Designers…

Why Hire a Software Consultancy?

As any product company knows, software development can be difficult to wrangle. Huge buckets of features, short timelines, and fierce marketplace competition can make it a major challenge to handle a release in-house, prompting many companies to reach out to software consultancies for help. 

Sometimes, this call for help comes a little too late, with only the threat of missing a release convincing a company to justify the cost of outsourcing the work. In this post, I’ll explain why it’s worth your while to work with a software consultancy right from the start.
Read more on Why Hire a Software Consultancy?…

7 Guidelines for Constructive Design Feedback

If you’re a client working with a polyvalent team of makers at Atomic Object, one of the most valuable things you can do is to give feedback throughout the project. This may come as a shock to you. In the past, you might have been involved in a project where feedback wasn’t welcome—or even treated as downright hostile. If that’s the case, let me be the first (and hopefully not the last) to apologize on behalf of consultants everywhere. Read more on 7 Guidelines for Constructive Design Feedback…

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…