Hard-Won Wrong Opinions on Software

Tech’s idea of “state of the art” is a moving target. Developers tend to pick up their expertise in real time — opinions, preferences, and instincts all tied to a hands-on need.

The specificity of it all makes practical experience a tough thing to question. How do we challenge hard-won process “truths?” Should we? Plenty of accepted facts stick around — communicate on the regular, don’t skip a tech lead, maintenance is forever, et cetera — but how many wrong opinions outstay their welcome?

Here’s a collection of software “truths” that we’ve needed to unlearn at Envy Labs.

Say “No” More

“Truth”: Scope creep sinks timelines and budgets. After defining what the application is and does, it’s good for the project to make the default stance on changes “no.”

At face value, being a bit overprotective of the scope makes sense. Change introduces unknowns, and unknowns introduce overages and blame. As a policy, though, it doesn’t hold up:

• The team will (inevitably) pick up new information along the way. A planned process won’t feel right in practice, a new competitor will pop up, a new tool will hit the market, and so on. Areas of the project will need to adapt — a truth that’s more pronounced as the build time increases.
• Success is a feeling, too. Stakeholders need to feel like the production application is their idea made whole; a reflection of their expertise, opinions, and instincts. A chorus of “no” chips away from their sense of ownership.

It’s possible to build good software the wrong way, and managing a successful project means making sure everyone’s influence is validated.

Agile or Bust

“Truth”: Software suffers in silence, and it’s slowed to a crawl by overplanned, documentation-forward processes. Agile is really the only worthwhile cadence, communication style, and approach to change management worth a lick.

Counter to our first “truth,” the idea of agile software development is all about change. Whether it’s weekly or bi-weekly, sprints set up short-term goals and short-term successes, with iteration as an ally.

The idea of agile isn’t the issue here. We’re concerned with the common side effects:

• Focus on the short-term is often at the expense of the long-term. It’s really easy for a decision maker to jump between priorities and toss the bigger picture away. And they never mean to — in Envy’s early years, there were many “where did the time go?” discussions after months of weekly client-led direction tweaks.
• On a long enough timeline, documentation (as both a how-to and a log of historical decisions) becomes both more important and less likely to happen. Small, achievable sprint goals make hard, vague project health needs tricky to prioritize.

Agile’s upside in communication, cadence, accountability, and as a feedback loop is invaluable. It’s a great process foundation, but doesn’t need to be followed to a tee: Some tasks, goals, and people should operate above the idea of a sprint.

Wireframes Help Everyone

“Truth”: Wireframes — low-fidelity, grayscale compositions — are a fast, cheap, and reliable way to make sure everyone’s clear about what’s being built. They’re a perfect visual snapshot of the scope.

We’re not shy about our love for wireframes, so this point has nuance.

Simply put, not everyone is good or practiced at filling in the fidelity gaps. Some stakeholders may not be able to project the idea of a finished, polished application onto a series of black-and-white boxes. From there, two things happen:

1. They tend to assume that more is coming; additional features or details will pop up later.
2. Dramatic change is still a possibility, in their mind. Wireframe approval loses its usual flag-in-the-ground level of importance.

The good news? Folks tend to be pretty forward if they think wireframes are gibberish. If you suspect an issue, there are a few ways to help the process along:

• Spend some time walking the team through what they’re looking at, why wireframes are important, and what next steps look like. Screencasts are great at this.
• Avoid asking for open-ended feedback. Directed questions help stakeholders focus on the details worth reviewing. Are all of the pages here? Did we forget any form fields? Will anything feel cumbersome for daily users?
• Poll wireframe-friendly team members for their gut reaction, then push into design faster to meet the needs of others.

Skip Sales and Marketing Until There’s Software to Sell

“Truth”: You can’t sell something you don’t have. Save on staffing costs by skipping sales and marketing until the software is set.

As it turns out, strategy and implementation aren’t unique to development. A completed product isn’t a magic finish line for drumming up awareness and customers. Both take time.

Sales and marketing need a seat at the table early. They’ll need a chunk of the budget, too — not just whatever’s left over. In return, those teams can spin up, offer competitive feedback during development, pick the right channels, and get ready to do their thing.

We lucked out during our own foray into bootstrapping a product. An existing audience of peers (more on that shortly) was a shortcut to profitability, papering over a later-than-recommended marketing team add. Development doesn’t mean much without customers and/or investors, so stay supportive of efforts that give the project a chance at both.

Peers Signal Success

“Truth”: Gallery-worthy applications with some social buzz from other designers and developers are well-positioned for success. Peer attention is a great marketing shortcut.

We just alluded to this one: A strong community of designers and developers helped us get a product off the ground. Conversely, some of our worst-performing personal sites topped out on referral traffic from industry-related galleries and physical magazines (remember those?).

Unless your customers are peers, craft for craft’s sake won’t turn into success. A fancy design or animation is still fun, worth trying, and helpful as a learning tool, but it’s probably not your lead gen strategy. Beware the inflated analytics.

One Stack is All You Need

“Truth”: Our preferred tech stack is best-in-class, and we’re mandating its use organization-wide. Hiring, new projects, and learning efforts should all be directly linked to it.

We started as a Rails shop. During the aughts, a company’s tech stack bled into its identity, influencing things like:

• Communities and conferences you’d hang at
• The choice between an enterprise or startup focus
• Clothing, usually in connection with the previous point
• Preferred project processes
• Luminaries in the field worth paying attention to

It was like hitching yourself to a music genre in the 90s. Or Mac versus PC. Once a subjective choice becomes part of your identity, you’re more apt to dig in and defend it.

Factions around frameworks, libraries, and languages are still around, but not quite as pronounced. People carry preferences, but there’s no objective “best.” All of ‘em have success stories at this point.

Picking some organization-level tech stack favorites is good for team building, focus, and shuffling developers around. It’s a limiting worldview, though, and won’t be “best-in-class” forever. These kinds of choices should only serve as a jumping-off point — give others a shot, build small things in new ways, and see what makes other corners of the development world tick. You’ll need to know what’s next.

Could we still be a Rails shop? Sure. But it’s not the best tool every time; Rails is a great hammer, but every application idea isn’t a nail. Our tech stack opinions are loosely held, serve the project, are reevaluated often, and (so far) keep us well-rounded.

Crunch Time is Part of the Gig

“Truth”: The nature of project- and phase-based work invites deadline pressure from time to time. We’ll need to cram some extra effort in here and there.

This one’s not wrong-wrong, but we shouldn’t be OK with it.

Ever start placing to-dos behind an upcoming vacation? See the emails pile up while you’re out of office? That first Monday back is a tough exercise in catching up and prioritizing all the things you’re now behind on.

Putting in extra hours for a deadline is just like that — except, you know, without the vacation part. You’ll teeter on the edge of burnout (or push through it), only to be rewarded with all the tasks that were punted during the last deadline sprint. The cycle starts anew.

Avoiding the crunch (and the impending burnout) (and the poor-quality work) takes a few steps:

• It’s not normal or expected, and management should agree.
• When the overtime cycle starts, treat it like a process problem. What was missed? How do we avoid that in the future?
• Lean on agile’s cadence. Weekly or bi-weekly goals (should) keep status on track — and keep corrections on the scale of days instead of weeks.
• Deliver bad news early. It’s much easier to adjust budgets, timelines, or goals at the start of the project than a week before launch.

Some Truths Don’t Stand Up

Success and failure are the main characters of learning, but reevaluation is right there in the supporting cast. Some of the “truths” around software development aren’t evergreen, especially as the industry marches on at a fever pitch.

Fortunately, developers are used to being lifelong learners. We just need to apply that to the things we think we know, too.