This is a good summary of the “healthy pressure” we strive towards on our team as well:
While working without the pressure of explicit deadlines can feel liberating, it also increases the chance of distraction. Deadlines help us stay focused, aligned and driven – and can be used to keep project scope in check.
I really like the this Mountainsides approach to software projects from the Postlight team:
It’s sort of like a Gantt chart that was left on the stove too long, leaving all those neat and tidy bars melting into one another.
Nicholas Carr chases down the origin of the phrase ”It’s Not a Bug, It’s a Feature.” This bit stuck with me:
INABIAF—the initialism has earned a place in the venerable Acronym Finder—is for programmers as much a cri de coeur 1 as an excuse. For the rest of us, the saying has taken on a sinister tone. It wasn’t long ago that we found software dazzling, all magic and light. But our perception of the programmer’s art has darkened. The friendly-seeming apps and chatbots on our phones can, we’ve learned, harbor ill intentions. They can manipulate us or violate our trust or make us act like jerks. It’s the features now that turn out to be bugs.
It seems that more and more, we simply don’t trust our software any more. And I don’t think that’s a bad thing.
Ah, estimates. That thing we all know we need to do (and get better at), but no one really wants to talk about. Well, Gina Trapani takes the topic head on in a great post called Estimation Is a Core Competency:
Estimates don’t need to be perfectly accurate as much as they need to be useful.
Good estimates create trust among your PMs and business leaders and collaborators. Being able to identify the risks and uncertainties in a project early gives your project team the information they need to plan around those risks and uncertainties.
Are you consistently getting waylaid by unforeseen work mid-flight, or just taking longer to execute on the work you did know about? That creates distrust between engineers and business leaders, and if it happens repeatedly, that distrust compounds and calcifies into resentment— that is, if you’re still in business.
Gina goes on to give some great tips for better (i.e. more useful) estimates.
I read something recently that struck me as a really good idea for our team. Usually that feeling goes away after a couple of hours (“nah, it’s cool but not a good fit for us”) — but not this time. In Running in Circles, Ryan Singer talks about the knowns/unknowns in a project like a hill:
The most important question for a team isn’t “what is left?” but “what is unknown?” Can you see the edges? Have you gone in there and seen everything that needs to change? The only way to gain certainty is to roll up your sleeves and engage with the reality of problem.
At Basecamp our teams seek out the areas with the scariest unknowns and work on them first. This uphill work requires strategies. We wrote about these in Getting Real. Open the code, spike something that works, load it with real data and try it. When the whole feature is too big to prototype, factor out the most important pieces and spike them.
He has a a nice visualization of it:
He also uses an example from a recent project to show how they map this out:
As they “move over the hill”, different parts of the project become known, and they become more certain about what’s left to do. We’re working on some checklists to identify development risks before we start a project, and this looks like a great way to visualize those risks and track them as you go.
This is a fairly old post, but I only recently came across Dan McKinley’s Choose Boring Technology. It is so good.
What counts as boring? That’s a little tricky. “Boring” should not be conflated with “bad.” There is technology out there that is both boring and bad. You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough. MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.
The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.
He goes on to explain the process you should go through before you try out a new technology.
I find teams generally do a good job of thinking of the features that make up the core customer-facing functionality of their project. It’s the non-customer-facing features that tend to be forgotten.
— James Hood on why software project estimates are so often wrong, from Plan All of the Things!
Spoilers abound so proceed with caution, but Rogue One: an ‘Engineering Ethics’ Story is so very good:
What Galen Erso does is not simply watch a system be built and then whistleblow; he actively shaped the design from its earliest stages considering its ultimate societal impacts. These early design decisions are proactive rather than reactive, which is part of the broader engineering ethics lesson of Rogue One.
The exploration of how Galen didn’t just walk away but took an active role in the destruction of the Death Star is interesting and highly relevant to what I consider an “ethical awakening” in our use of technology. It’s one thing to #DeleteUber — and those campaigns can certainly be effective, in that case to the tune of 500,000 accounts. It’s quite another to “infiltrate” your company and basically sabotage its technology because you believe it’s ethically dubious. The really complicated question is who gets to decide whether or not a company’s “ultimate societal impact” is good or bad. And, of course, who watches the watchers…
It’s been roughly 15 years since I made an entity–relationship model, so it is with great surprise that I sat in a meeting the other day and thought to myself “This project needs an ER model before we can do anything else.” I almost asked out loud, “WHO SAID THAT!?” But once I got over the initial shock I realized that my subconscious isn’t completely full of crap (this time).
But let’s back up. I’m working on a project to combine a variety of different back-end services into a single product. As we were talking about it and the discussion shifted to design, I realized that before we could create user journeys and get started on the interaction design we first needed to understand the relationships between the different entities in those services. I worried that without that model, we’d get ourselves tangled up really quickly.
So I brushed up on my theory1 and got to it. First, the obligatory definition:
[An] entity–relationship model (ER model) is a data model for describing the data or information aspects of a business domain or its process requirements, in an abstract way that lends itself to ultimately being implemented in a database such as a relational database. The main components of ER models are entities (things) and the relationships that can exist among them.
This is a tool that’s primarily used as the first step in relational database design. But I found it really useful for us to define the constraints within which we could create user flows. Let me explain with an example. Here’s a simplified version of the ER model we came up with for this project (using Crow’s foot notation):
Each color represents a different back-end service. Here’s a subset of what the diagram tells us:
If all this sounds a little bit boring, I hear you, but here’s the power of this diagram: it ensures that whatever UI we come up with serves the underlying entity relationships, and not the other way around. This is huge. For example, if we started with the UI we might say that users can attach files to a task or project within the product’s main interface. But since a 1:1 relationship exists between Conversation and File, it means we can also attach a file to a task by dropping it into the Conversation view of that task. The relationships help us to come up with the most useful and robust UI.
What essentially happens if you start UI design with an ER model is that you create the boundaries of what’s “allowed” in the UI. It pushes you to think up useful ideas without the danger of coming up with something that wouldn’t work in the final implementation.
I don’t think ER models should be the starting point of every project. But in certain specific cases where many disparate products or services need to come together it’s proved to be really useful.
And now, on to journey mapping…
I find the common meme of “Oh, that’s ugly—a developer must have designed that” pretty misguided (and I’m not even a developer). The reason is that most developers I know have exceptional ideas (and taste). So these words from Marty Cagan really resonated with me:
I consider this mindset of the product owner (or more generally, the CEO or stakeholders) as the only one that can determine what to build, as toxic to teams, and a major reason for the lack of innovation. I’ve tried to explain many times that often the best single source of true innovation are our engineers. That doesn’t mean every engineer is going to be like this, but the mindset where no engineers can do this is a very serious problem. The engineers are working with the technology every day and are in the best position to see what’s just now possible. They are also disproportionately very bright people. When you combine this deep knowledge of technology, with a first-hand experience of the customer problems, great products can result.
“The best single source of true innovation are our engineers.” True that.