When I first began building complex React applications, I struggled to determine the best way to name and organize my components within my codebase. Having come from the Rails school of convention over configuration, I was perplexed to find that most modern JavaScript apps rely heavily on custom configuration and don't adhere to any sort of community-driven conventional norms. That's changing slowly with the advent of toolkits like create-react-app, but even its conventions go right out the window as soon as you npm eject.

After a couple years of learning and mistakes, there are a few guidelines I use when organizing my React components so my code is more readable, understandable, and succinct.

Compose your components into smaller subcomponents

While it's tempting to just keep adding bits and pieces to your component's render method, this can grow to the point where it becomes difficult for new eyes to discern your intentions. Imagine a render method like this:

render() {
  return (
    <div className="todo-list">
      <div className="todo-list__items">
        {this.props.items.map(item => (
          <div className="todo-item">
            {item.title}
          </div>
        ))}
      </div>
    </div>
  );
}

Instead of rendering todo items within the root component's render method, create a new component:

const TodoItem = props => (
  <div className="todo-item">
    {props.item.title}
  </div>
);

Then, call it in our root component's render method:

render() {
  return (
    <div className="todo-list">
      <div className="todo-list__items">
        {this.props.items.map(item => (
          <TodoItem item={item} />
        ))}
      </div>
    </div>
  );
}

It's a subtle change, but making these sorts of changes proactively can keep your components readable. And becuase React only re-renders those components that change, extracting smaller components can improve your application's performance.

Extract iterators into class methods or new components

Extracting a subcomponent is a good first step. But we can go one step further by extracting the map iterator call into its own method in the root component. This improves the readability of the render method:

render() {
  return (
    <div className="todo-list">
      <div className="todo-list__items">
        {this.renderItems()}
      </div>
    </div>
  );
}

renderItems() {
  return this.props.items.map(item => (
    <TodoItem item={item} />
  ));
}

Now when we scan the render method, we see a more succinct summary of its contents!

Only use ES6-style class components where state is needed

Notice in my previous example that I've opted to use const to define the TodoItem component. This is because, in its current incarnation, the TodoItem component is stateless.

In React, stateless components are merely functions that return a React-wrapped DOM element. Unlike using the ES6 class keyword or the now-antiquated React.createClass method, stateless components cannot hold their own component state in a this.state object.

The reason this syntax is favorable is because it encourages authoring code in a functional style. Let's expand our TodoItem component to include a "Delete" button:

const TodoItem = props => (
  <div className="todo-item">
    <div className="todo-item__title">
      {props.item.title}
    </div>

    <button onClick={props.onDelete}>
      Delete
    </button>
  </div>
);

Here we've enclosed the title in a new container div, and then added a <button> tag with an onClick handler set to a hypothetical onDelete thunk handler that we would pass through from the parent component.

Just like in our iterator extraction example above, there's opportunity to make this component more readable. However, because this component is stateless we can use a more functional style:

const Title = props => (
  <div className="todo-item__title">
    {props.value}
  </div>
);

const DeleteButton = props => (
  <button onClick={props.onDelete}>
    Delete
  </button>
);

const TodoItem = props => (
  <div className="todo-item">
    <Title value={props.item.title} /> <DeleteButton
    <DeleteButton onClick={props.onDelete} />
  </div>
);

Our goal in doing these extractions is to reduce fatigue when scanning your components' code. New developers who visit this code for the first time will be greeted with components whose markup is only a few lines, making it much easier to parse and understand than if they were tens or hundreds of lines.

Keeping this habit early on will mean your codebase can grow and remain understandable to newcomers.

Organize composed components into subdirectories

So far, we've built the following components:

• TodoList
• TodoItem
• Title
• DeleteButton

As our codebase grows, the way we physically organize our code on disk is going to become more critical. I've experimented with a couple methodologies.

The first is to create a directory called components, dump all your components in there, and call it a day. This is fine for projects with fewer than 20 or so components, but it becomes cumbersome as the number of components grows.

Instead, I've settled on creating subdirectories for certain root-level components. In our example, we could envision the following directory structure:

  components/
    TodoList/
      index.js
      Item/
        index.js
        Title.js
        DeleteButton.js

Organizing our components in this way has the following benefits:

• Components only ever reference other components within their own subdirectory.
• We can name components based on their context. For instance, instead of naming our item component TodoItem, we can call it Item. This reduces unnecessary verbosity.
• Our components become portable. By encapsulating their hierarchy within a single directory, we can reuse the component in other codebases easily.

Marketing yourself sure is an anxious chore. I'm plenty qualified for all sorts of full-time jobs, but I'm resolute against taking one since I know I work best when I'm free.

What does freedom mean to me?

Freedom means the ability to wake up when my body tells me instead of when an alarm sounds its siren. It means I can take some time between clients to ride my bicycle around town casually without worrying that I need to return to the office. It means I'm not burdened by day-to-day inter-office politics. That I can provide immense value without being physically present.

But it's tough out there. Not in the economic sense; there's probably plenty of work to be done. But marketing yourself as a consultant is no easy task. Most consultants probably wouldn't admit such a thing on their website for fear of being perceived as a failure or a fake.

I'm not afraid of that because I know my value, but I am afraid of failure. I'm afraid I'll soon be applying for jobs and working 40 hours per week and giving up on this whole consulting thing for good. Which is humorous in its own way given the fact I'm nowhere near failing. But that's how fear works, isn't it?

Limiting beliefs are beliefs we hold which constrain us in some way. We define ourselves by what we do or don't do, what we can or cannot do, what we are and what we aren't.

The tech industry, with its continuous cycle of innovation, cutthroat competition, and social darwninist hierarchy, can foster some pretty sinister limiting beliefs. I struggle with them regularly and I'm sure you do too.

I'm too old. There's plenty of chatter about ageism in the tech community. As someone who's turning 32 this year, I'm fearful of it, in spite of not having experienced it. I do wonder though, whether ageism is a bogeyman insecurity that can be overcome in the minds of those affected, rather than a form of systemic oppression. It's tempting to give up on that new startup or to believe we're unable to grasp new technologies on account of our age. But the market doesn't care how old we are, truthfully.

The market is too saturated. I'm running up against this resistance right now myself. Building a consulting business is no easy task. There is plenty of advice of how best to proceed when building a consulting business, and I've learned over the past few months that it's easy to get sucked into their vortex and forget to do the work. While some of the advice is prudent to follow, most of them are just selling shovels to the miners. I'm learning that the best way to build a business is to build the business. The market doesn't care how many players are in the game. It's just a matter of standing out among them.

All the good ideas are already taken. This one is fascinating to me, but I'm still succeptible to it. Imagine someone saying this in the days before the Internet. Lawyers didn't decide not to start a law firm because there were already lawyers in the world. Dentists didn't say "Well, there are already people fixing teeth. I guess that dream is off the table." Why are we so caught up in the notion that our idea need to be original? Competitors are a sign there are people willing to pay for what we offer. It's just a matter of providing more value than they do.

I'm writing this as a gentle reminder to myself: There's abundant opportunity for thoughtful and innovative people. It's just a matter of training our minds to open.

I'm noticing a trend as I'm bootstrapping my consulting business. There are plenty of awesome software development gigs, but most of them are full-time positions.

I have nothing against full-time positions; they're great for people who enjoy capturing a regular paycheck each month and don't like the sales process. But I'm not sure I understand how hiring full-time staff benefits the employer, especially in terms of cost benefit relative to hiring results-oriented consultants to complete the same work.

Employees are paid for their time. No matter the enriching culture you provide them internally, they have little incentive to be efficient aside from the possibility they'll lose their job. Most employees do want the best for their company, but their principal concern is the livelihood of their families and their ability to live life on their own terms. Paying an employee's salary for a year does not translate into results for the business. I've spent months as an employee working on projects which never made the company a dime because they were ill-conceived from the start. I got paid and the company got nothing.

Consultants charge for the outcomes they produce. If you need a new user interface for your web application, I'm going to spend a fair amount of time asking you why you need it. I'm going to dig deep into how such a move could improve your business fundamentals. I'm going to ask you difficult questions that have more to do with sales, marketing, and users than technology, infrastructure, or design.

When I send you an invoice, I'm going to tell you exactly the results you paid for. If you're not satisfied, you'll get your money back.

Feeling pressure to keep your team members employed because you know they rely on you for paying their rent? Hire a consultant and you won't have that problem. I'm happy when you don't need me anymore. Hopefully I worked myself out of a job and you can spend the money you would have allocated to my salary on marketing to more users or innovating in other ways.

There's a stigma abound that independent consultants are hawks looking to scoop up a payday without providing real value in return. I want to debunk that myth for good. Consultants are seasoned professionals who realize they don't thrive in the employer-employee model. We want nothing more than for you to succeed and to help you find the best possible path to get there. Our business is not one of billing hours, but of optimizing costs. We charge fees not based upon the time we spend, but based upon the value we provide.

I'm an anxious person.

Wait, strike that. I'm striving not to carelessly apply labels. I sometimes suffer from anxiety. There. That's better.

I sometimes suffer from anxiety. Having spent the majority of my waking adult life in front of a screen, I'm no stranger to the anxiety-inducing nature of life online in 2017. The average computer or smartphone user has hundreds of apps vying for their attention, each hoping to take a slice.

It didn't used to be this way. Before 2009 and the introduction of Apple's Push Notification Service, your iPhone left you alone except for when you received a phone call or a text message. Those were simpler times.

Now, if we don't do something about it, we're subject to a near-constant buzzing and chirping. Emails. Text messages. Tweets. Likes. It doesn't stop. As a technologist, I feel almost apologetic for the culture of distraction that is now our everyday reality.

That's why I want to do you a favor. I'm going to make a suggestion that hopefully will change your life for the better. Ready?

Turn off all your notifications.

That's right. Turn them all off. Even your text messages. Maybe leave your phone call notifications on so people can reach you in case of an emergency. But you haven't experienced the serenity the people of the twentieth century took for granted until you turn off all your smartphone notifications.

Afraid you'll miss something? You won't. If something is important enough, someone will call you.

Consultant. The word conjures up thoughts of business attire, meetings, and an expensive invoice. When you're going to hire a developer, you usually don't seek out a consultant. In fact, you might steer clear of them for fear that they're only out to line their pockets. What you're looking for is a freelancer. Someone you can trust. Right?

It's difficult to discern the difference between the two, so I want to explore what each term means and how to gage whether the person you're hiring should be deemed a consultant or a freelancer.

The biggest distinction between a freelancer and a consultant is that a freelancer thinks in terms of deliverables, while a consultant thinks in terms of outcomes.

Imagine you're losing sales to your competitors and you attribute this loss in sales to your competitors' superior online sales experience. You want to hire a developer to build an online store that can rival your competitors.

When hiring a developer who bills themselves as a freelancer or contractor, it's likely they'll focus more on the deliverables. They'll take orders from you and you'll (hopefully) end up with the online experience you envisioned.

But what if that online experience doesn't result in the outcomes you expected? What if it has a net negative impact on your sales?

It's not your developer's fault, necessarily. They built what you asked for, focusing on what to build. But their interest and focus is on deliverables—the website, the technology, the means. Yours is on outcomes—the traffic, the sales, the customer satisfaction.

But what if your developer understood your desired outcomes? And what if instead of billing you merely for the time it took them to produce deliverables which may or may not achieve those outcomes, they billed you for actually achieving the outcomes?

That's the essence of hiring a consultant. You're not paying for a web application; you're paying for the results that come from that web application. A consultant is a partner. Their interest is your interest. They guarantee outcomes that they believe they can deliver, instead of billing you arbitrarily for their time which may or may not produce the desired results. They seek to intimately understand your business and how it can be improved through technology. And because they're billing you for the results they achieve, they're not going to sell you technology you don't need to achieve them.

Usually interactive projects involve one or all of the following creative talent:

• User experience (UX) designer
• Visual designer
• Front end developer
• Back end developer
• Quality assurance engineer

A traditional project lifecycle looks something like this:

1. The user experience designer expresses user flows and wireframes which represent the final product. After your approval...
2. The visual designer processes the wireframes into mockups which capture the client's desired visual aesthetic ("look and feel"). After your approval...
3. The front-end developer begins building the mockups into HTML, CSS, and JavaScript, which drive the user's experience in the browser. They'll also inform the back end developer of what API will be required. After your approval...
4. The back-end developer builds the API while the front-end developer integrates.
5. If you're lucky, a QA engineer tries frantically to break things and reports what they find to the developers for fixing.

And if you're really lucky you'll have nothing but praises to sing about the your product and everyone can go home early.

Except that never happens.

What really happens is that you notice things. Things you didn't notice when all you were working from were some black-and-white sketches. You realize a button's text is confusing, so you ask if it can be changed. Your supervisor informs you that the product needs to work differently.

If only you could have shown your supervisor sooner.

If only you could have seen your product in its early stages to collaborate on its success, instead of leaving it to the mercy of an agency.

That's the problem prototyping solves. Prototyping is when you build a product iteratively, collaboratively, and with as little upfront design as possible.

It puts experimentation above specification, and outcomes above delivery. It implores developers to become product- and design-focused instead of just playing an adult game of paint-by-numbers.

Your average developer builds software according to a design specification.

Developers who prototype design software to achieve outcomes through experimentation.

A new paradigm

As programming tools have increased in capability, developer productivity has increased with it. It's now not unfathomable that a solo developer execute both the design and implementation of a small- to medium-sized digital product.

Composable user interface libraries like React mean we rely less and less upon visual designers to inform the first versions of our products, because it's trivial to iterate on visual aesthetics in the midst of a product build.

And technologies like hot reloading of stylesheets mean that a developer fluent in CSS can rapidly design a gorgeous user interface without ever consulting a visual designer.

Paradigm shifts like this one have occurred throughout the course of software development history. Agile development killed the idea that you could build software successfully with rigid upfront specification, but its methodology speaks very little about user experience and what role developers play in shaping it.

I believe we're now going through another transformation: The realization that developers, if up to the task, can play a unique role in driving the user experience conversation. And that role can be so profound that it changes the entire process of product development.

Now, I don't want to make any wild claims that visual designers are unnecessary or that all developers should start focusing on user experience. After all, we need specialists in all sorts of disciplines, and big projects will always require the leadership of a visual designer to create cohesion and establish identity. But I do think that as product managers, entrepreneurs, and anyone who buys professional software services realize the potential in granting product leadership to their developers, we're going to see a shift in methodology.

And too, as developers begin to recognize the value they can bring to a product by becoming more involved in the user's perception, experience, and value, they too will embrace this subtle but powerful change.

The power of simultaneity

A non-technical user experience designer can offer only so much in terms of real value to end users. They can demonstrate a concept, but not execute it for analysis.

A non-technical visual designer can produce a new identity for an interface, but relies upon the whims of a paint-by-numbers developer to bring that concept to customers in the product.

A design-focused, user-focused developer can execute all of this simultaneously. They're able to conceptualize a visual identity, produce a working prototype of an interface concept, and give it to real end users to test their hypothesis.

By putting your developers in the design seat, you reduce the communication feedback loop that inevitably occurs between designers and developers. This new autonomy produces design decisions which both serve the user and consider technical challenges.

You have an idea for a new online product offering. Maybe you already have a thriving business and you want to reach more customers with an interactive experience. Or maybe you're a budding entrepreneur who has a fresh idea to take to market.

What's the first thing that you should do? Maybe you should brainstorm a compelling and memorable name. Then go register a domain name. Hire a designer to create a logo. Sketch some wireframes. Hire a developer. Build the app.

These all sound like reasonable starting points. And they're all things thriving product businesses have done, so it's natural you'd follow this progression.

But none of these activities involve the reason you're building your product in the first place: your customers.

Your customers aren't going to come to you because of your name. They're not going to pay you because you have a sweet logo. And they don't care about your app.

Your customers only care about one thing: That their life is improved because your product is in their lives.

It's fair to say then that your customers care about outcomes. They care that, after using your product, they feel better, have more money, or are otherwise more satisfied than before using your product.

An outcomes-oriented approach

Instead of focusing on deliverables like mockups, technology, and a snazzy marketing page, what if you focused on the outcomes your customers will experience? What if you spent time answering questions like...

• Who am I serving?
• What problem am I solving for them?
• What makes me better than the competition?

The answers to these questions might involve technology or visual design, if you decide those things are necessary to helping your customers solve their problem. But they certainly aren't the core reason your customers want what you've got. You've got to identify why they came to you in the first place. How do they think? What annoys them? How can you alleviate their existential suffering... or at least make their lives marginally easier?

When you know who you're serving, you're able to learn from them about what they want. And when you know the problem you're solving and how your solution is unique, you won't dilute your message and scope.

If you're actually solving someone's problem, they won't care if your branding isn't perfect. They won't mind if your site looks terrible on mobile, so long as they don't need to use the site on mobile. And even if they do: As long as they're getting value from your product, they'll be willing to wait.

That's the essence of prototyping: Building a working version of a product idea that provides real value to real human people, and putting everything else off until after you've done that.

Your objective is to confirm or refute your product's value hypothesis by conducting experiments which simulate aspects of your product idea—not to hold off "launching" your product until a "public release."

That doesn't mean you won't eventually choose a marketable name. It doesn't mean you're going to skimp on any aspect of your product for good. It just means you recognize that the thing your product must do in order to be viable is provide someone somewhere with real value.

If you're doing that, you have a successful product. If you're not, you just have a bunch of code and images and text chasing a fantasy.

The prototyping process

I've spent my career leading the early stages of digital products. Here's the process I use to reduce cost and encourage experimentation when taking a new product to market:

1. Identify the problem you're solving, and for whom

Clearly define the problem your new product alleges to solve, and the specific segment of the market who has the problem.

My favorite exercise for defining your problem and target market is the Fool-Proof Positioning Statement by Dan Janal:

The Fool-Proof Positioning Statement is a two-sentence message that tells people what your product is and how they will benefit. The second sentence tells people why your product is different than others. Here's an example: David Letterman is a talk show host who entertains baby boomers so they can feel good before they go to bed. Unlike other talk show hosts, he performs a Top Ten List.

A positioning statement identifies the following elements:

• Category of product
• Primary audience
• Primary benefits
• Competing products
• Primary difference or uniqueness

Take for example, a positioning statement for Formbot, my SaaS for sending webform submissions to Slack and email:

Formbot is an online service that helps developers of static sites receive feedback from their visitors without setting up a server. Unlike other form services, Formbot connects to Slack.

I had the idea for Formbot because I had a real and annoying problem: I love building websites with static site generators, but I didn't want to have to set up a server just to receive form feedback from my visitors.

Once you've identified your primary audience, identify real people within that audience who have the problem you want to solve. Get their assurance that they would gladly pay money to have the problem solved. Forge relationships with them. Ask them how your competitors' product could be better. Listen.

2. Identify desired outcomes from using your product

Now that you have a handle on the problem and the audience for whom you're solving it, it's time to identify how you're going to solve their problem.

Do your users want a fully-automated solution, or one with an interface that affords more customizability?

What are your audience's success outcomes? If your audience gets nothing else out of using your product, what is the one thing with which they need to leave in order to continue using the product?

Organize your product's hypothetical features into user stories. These are a special type of device for thinking about a product's features in terms of their outcomes instead of their deliverables. Each well-written user story identifies a persona, action, and outcome for a given software feature:

As a Formbot user, I want to connect my Slack account so that I can receive potential sales leads in Slack.

• As a...: the persona who has a stake in using the product
• I want to...: the action they're going to perform to reach a desired outcome
• so that...: the valuable outcome the product grants them

Note that the action for each user story needn't be explicit. You don't need to explain that your user should press the "Create Message" button; just explain that they're going to send a message and why that's important. For instance, here's an example of a user story that's too bound to deliverables and has no real business outcome:

As a user, I want to click the "Create Message" button to open the Create Message dialog so that I can send a message to my clients.

Instead, focus on the outcome of the action as it relates to the user:

As a user, I want to send a message to my clients so that I can follow up with them and make more sales.

In doing so, you decouple implementation from your outcomes. When you engage a developer to build the first version of your product, you'll be measuring success not by whether there's a button that reads "Create Message" (irrelevant to your business), but by whether your users can effectively reach their clients (relevant to your business).

3. Determine the most valuable feature of the solution

Of all the user stories you wrote, which one offers the most value to your users? If you were stranded on a desert island and your developer could only build one feature (yes this is a terrible analogy), which feature would you have them build?

Do your prospective users from step 1 feel the same way? Would they start using your product if you could deliver them that one feature?

Formbot started out as a single feature with hardly any user interface. It was barebones, but it did one thing exceptionally well. So it attracted a small but loyal userbase. As a result, I was able to capture user feedback and better understand why users were satisfied and why they weren't. This informed further development and further feedback collection.

You might think you need features that most products have, like email alerts or two-factor authentication. But when you force yourself to think in terms of delivering value to real human people you are actually talking to right now, you find ways to help them without a ton of expensive engineering work.

Again: That's not to say email alerts and two-factor authentication aren't valuable. They're both immensely valuable and you should build them. They might even be inseparable from your most valuable feature, and you might need to build them in order to satisfy your users. But strive to build the least product possible to deliver the most value. Usually that's less than you think.

4. Build and deliver that feature to your audience

Now that you know the featureset that will deliver the most value to your users, it's time to build it.

It's not time to create wireframes. Nor is it time to hire a designer. These are both actions that result in deliverables, like wireframes and mockups. We're prototyping, so we don't want deliverables. We want outcomes.

The first iteration of your product probably won't be pretty. But it'll solve a real problem that your identified real human users need solved. So it doesn't need to be pretty. It needs to work. And for that, you need a developer.

Developers are a dime a dozen. Most developers focus on deliverables. They build the features you want built in the way you specify. They paint by numbers.

What you want is a developer who focuses on outcomes. Remember the user stories you wrote in step 2? You know how I told you to make sure they specify your desired outcomes, as opposed to the path for getting there? You want to find a developer who thinks like that. Someone who sees the road ahead of your business and can steer your product accordingly.

Instead of asking how? like most developers, you want to find a developer who asks why? Instead of estimating how long it'll take to deliver "your app," you want to find a partner who can estimate how long it'll take to validate your business.

Here's a secret truth about software development no one wants you to know: You're never done. Your product will always have bugs, unimplemented features, or things you don't like. It's a fact of the business.

Developers don't want you to know this because they make their money on deliverables. For them to be done with a project is for all the deliverables to be completed. But by this definition of completeness, no project is ever finished.

But you're not going to focus on deliverables. You're going to focus on outcomes. You know that by focusing on deliverables, you can't clearly say whether you've achieved your desired outcome. Having a product with a gorgeous user interface that doesn't have any users is a sure way to go broke. But having a product with an ugly interface that helps 1,000 people achieve a desired outcome means you've proven your hypothesis. The gorgeous interface will come later.

5. Assess the value delivered

You've built your first feature. Your users are now able to walk through one workflow from start to finish. It's not pretty, but it works. Now it's time to see how your audience responds.

Because of how little you've actually built, you might feel ashamed to share this with your audience. But ask yourself this: How would you feel if you made it "perfect", shared it with your audience, and discovered it didn't help them?

And what about the best case scenario? What if your one feature helps your audience in ways you didn't think it could? If that happens, then congratulations! You've validated your product idea. And you did it without spending all your money on vanity deliverables like branding, visual design, and SEO marketing.

6. Refocus your efforts accordingly

If your first feature was a hit, then you're probably feeling encouraged and want to press on. If your audience didn't respond the way you hoped, then you're probably a bit discouraged and might feel like giving up.

Whatever happened, you can rest assured that because you reduced your deliverables to only those things that help you validate whether you can deliver your users the outcomes they desire, 100% of your investment was in pursuit of providing your users with a valuable experience.

You didn't spend lavishly on a hip domain name.

You didn't hire an expensive visual designer.

And hopefully, your sunk cost is low enough that you have the emotional wherewithal to be able to walk away unscathed.

Or, you can choose to regroup and reposition your product. Because you didn't lock yourself into a specific featureset with lavish marketing and polish, you can conduct another experiment. You can continue this process indefinitely until you find something that sticks.

That's the beauty of prototyping. That's why I focus on outcomes. And that's how to build a product people will actually use.

Read on: How is prototyping different?

Ah, the age-old question that eludes anyone who wants to build custom software: How long is this going to take and what will it cost me?

I've been on the receiving end of this question numerous times. And until now, I always butchered the answer. Because in order to properly assess cost when we're building software, it's inadequate to assess the cost of building the software you think your business needs. Instead, a great consultant will analyze your business's unique situation and recommend a path resulting in business outcomes that don't strain your budget and get you to market faster.

Ask yourself: What is the value you hope to deliver to your users? Can you deliver a small part of that value with less effort than you’re envisioning presently, and get it to market faster? Are you operating with invalid assumptions about how your users will behave and what they'll expect?

Imagine you go to a software vendor and tell them "I want to build a car!" They give you a specification for building a car and tell you it'll cost $50,000. You cringe at the price, but go forward with it, because you need to build the car.

A great consultant will ask you why you want to build a car. "Because I want to get across town!" you'll say. And then they'll ask you if a bicycle for $500 will get the job done.

When vetting a consultant to take on your MVP project, it's critical to ensure they possess both the hard skills required to build a working application and the experience to know when what you’re asking them to build isn’t in your best interest.

You're trying to find a consultant who will find the simplest solution to your problem, as opposed to building what you tell them. Building the thing is the easy part. The hard part is defining the thing to build that produces the outcome you desire at the lowest cost.

Rather than building a wireframe specification and handing it to a developer to implement as you've specified, you'd be better off to seek a consultant who can unpack your business, analyze its core needs in the context of technology, and then deliver to you working software week after week.

If you're non-technical, you're probably not in a place to understand the technical consequences of what you want to build. When your ideas are placed under that scrutiny, you might change course because there's a more expedient way you didn't see before.

We knowledge workers love rituals. We're always seeking ways to reduce friction, increase productivity, and increase visibility. There's Agile, XP, Kanban, Pair Programming, and now even Mob Programming. There's an entire industry within an industry devoted to teaching others how to apply these principles.

Some teams hold a daily standup. Most hold some form of an iteration planning meeting. And some apply points-based estimations during their planning meetings.

Both standups and estimation have value, depending on your team. If you have a dedicated project manager who scopes the next sprint's work, they might benefit from points-based estimations because they can measure how much progress to expect next. And if you work on a team building a high-touch customer-oriented product, you might benefit from a daily standup to keep your non-technical stakeholders in the loop.

But I've been on too many teams who did one or both of these rituals even though they didn't provide any tangible value. And in many cases, the maturity of modern network tools has rendered these rituals all but obsolete.

Are your daily standups redundant?

Before the likes of GitHub pull requests, it was difficult to, at a glance, see what your teammates were spending their time on. If they had a question, the daily standup served as a space for making inquiries without feeling like you were interrupting their day.

But now that GitHub pull requests enable a one-click view of ongoing efforts by your team and a vehicle through which questions can be asked and answered on our own time, the daily standup is a relic of a less connected past.

And even if you do commit to a daily standup, does it necessarily need to be a synchronous meeting where everyone is present at the same time? I've worked on a team with a #standup Slack channel. We each post our daily standup in the room. Everyone can read up on what the rest of the team is doing that day and whether they're blocked. And no one has to interrupt their workflow to do it.

Ask yourself: Do you get much or any value from your standup, or is it just another mindless ritual?

Are your estimations meaningless?

Stakeholders want to know how much their software is going to cost. This is a reality with which every software developer must contend. But another reality is that software estimation is a losing game.

We can try, to the best of our ability, to assess a software problem and estimate how long it will take to come up with a solution. Armed with an understanding of a fixed software problem, estimating the time to build a solution is actually relatively easy. But software problems are rarely understood correctly ahead of time, and are rarely ever fixed.

Most software problems are complex enough that they require further inquiry after beginning development. There might be a variable we didn't consider during estimation. We might have misunderstood the original problem and gotten that feedback from the customer halfway into development. When was the last time you developed a piece of software without asking for clarification from your customer in the midst of development?

And even if you're fortunate enough to understand a problem thoroughly enough to implement it to the customer's desires the first time, there's a good chance they'll change their mind about it in the middle of development. Maybe they think of a better way. Or maybe business conditions have changed and it makes more sense to do things differently. Whatever the reason, requirements change. And when requirements change, you can kiss your original estimate's accuracy goodbye.

Okay, then what do we do instead?

Estimation and daily standups attempt to solve a real problem: Making sure everyone involved in your project is held accountable and are aware of the changing conditions of your project.

If your team reports that they find value in these activities, then keep doing them.

But if you really consider the opportunity cost of continuing to live by these rituals, you might find their cost outweighs their benefit.

Does interrupting everyone's flow during ongoing high-value development work to hold a daily standup have a net benefit to your team's productivity and happiness? Or would the team be better informed by committing to reviewing open pull requests and tickets once per day on their own time?

Are your estimations providing your product owner with valuable insight into what progress they should expect in the coming months, or are your estimates so skewed from reality that they're meaningless?

Do you own your rituals, or do your rituals own you?