Comment by ChrisMarshallNY | Hacker News Reader

Comment by ChrisMarshallNY | Hacker News Reader

ChrisMarshallNY

I have always done a "triage" of functionality, before starting. I call it "Front of the Box/Back of the Box/Side of the Box."

If it is important -to the end user; not the engineer-, then it gets prioritized over other functions. That is critical.

Think of a product package, sitting on a store shelf:

FRONT OF THE BOX:

This is three "Must Have" features. It correlates to the big, splashy text, on the front of a box. Without all of these, the product is a total failure.

BACK OF THE BOX:

This is four or five "Critically Important" features, that correlate to the smaller, yet still pronounced, features, listed on the back of the box.

SIDE OF THE BOX:

Everything else. Small text, on the side of the box.

When scheduling the project, it's critical to schedule Front Of The Box stuff, first, then Back of the Box, and, finally, Side of the Box.

Doesn't matter whether you are Waterfall or Agile. The important thing is to plan on implementing the "killer features," FIRST.

A lot of times, engineers want to get the difficult stuff done first (guilty as charged). This can often result in "bikeshedding" behavior, where a great deal of time is spent on stuff that isn't really relevant to the end-user.

When a project enters a "crunch phase," then it's important to start pruning. This is not popular. We need to remove feature development from the schedule ahead of us.

Since we have already implemented the important stuff, we will be pruning stuff that the end-users of our product don't really care about.

Also, I run what I call "Constant Beta." I get the project to an end-user-runable state, as soon as possible, even if feature incomplete. This gets me valuable feedback, and the important stuff (Front of the Box, first!) gets more testing than anything else in the product, since stakeholders are testing it, from the start.

This often results in pivots during development (as opposed to a janky MVP, destroying your brand).

But I have found many corporations won't do it that way. I had to wait until I was working for myself to do it.

Works a treat.

The reason you are supposed to do the "hard things first" is because of risk. If you do the easy but front-of-the-box things first, you might find out that the hard things are impossible. Software is complicated and so are requirements. Finding out your product is critically flawed too late burns time. I'm not into buzzwords or over-indoctrinated into methodologies, but I think Agile has that aspect right.

But if the "hard thing" is something not crucial to the end-user of the product, then it doesn't matter whether or not it's impossible.

Really bitter pill to swallow.

This philosophy is not easy for engineers (like me) to stomach.

a) That hard thing should have been cut out and by definition is not part of the product. Didn't see a bridge with space rocket engines recently, as one could say.

b) Most times nobody knows what is actually crucial to the user -- including the user and management. Books and theses have been written on the topic. Companies experiment until something sticks. There is always the chance a feature is unnecessary.

It depends on what you are doing. Frequently you know you have A, B, C, D use cases in that order of complexity.

A lot of people's instincts will be "Let's try it out with an easy use case like B" and then make the go-forward bases on that.

Then you go to tackle C or D and find out it's a no go.

The better strat can be a spike on D to verify the solution can handle it. This is hack and slash; your validating. After you work on the mature solution.

I've seen so many times people sink time into the mature solution based on A. Then you find out it won't work for D or you finally measure and find out there is no benefit.

The really important thing if you decide to go this route though is that each "thing" that goes on part of the box needs to be a complete feature. Typically projects aren't approached in that way - if someone builds out the front-end UI because that's highly user visible but someone doesn't hook up the backend (as an extreme example), the fact that the "front of the box" features are done is irrelevant, they're unusable without the less sexy stuff.

Not to say that it isn't possible to divide a project into independently "complete" features, it's just something you need to be really intentional about.

> they're unusable without the less sexy stuff.

Absolutely correct. I’m big on infrastructure. Infrastructure is not “shiny,” at all, most times, but it’s the glue that holds the whole shooting match together.

My designs often begin with infrastructure, but I’ve learned to architect flexible structure, as it usually needs to adapt to changing requirements from the frontend, as the project progresses.

In fact, I’m actually doing exactly that, with a backend connector layer, in my current project, right now.

The connector SDK (and backend server) is suffering performance issues, which degrades the user experience to an unacceptable level. Nasty time to encounter this, as the project is quite mature.

The current connector is really not something that can be easily adapted or fixed (I wrote it about six or seven years ago, as a generic SDK, for the backend server, which I also wrote). It needs a rewrite —usually a “death sentence,” this late in the project. I had to think long and hard, before making the decision to do this. If this weren’t a “Front of the Box” feature, it wouldn’t even be a consideration.

Because I always approach these types of projects in a loosely-coupled, “layered” fashion, it makes it easier to “swap out” parts.

Each layer tends to take the shape of a standalone “module,” with a clear, unambiguous, functional domain and API, along with its own testing, documentation, and project lifecycle. They usually take the form of discrete GitHub repos, and SPM packages. That is the case for the current connector, and will be the case for the new one (I already have it set up).

I expect the rewrite to take a few weeks. I’ll probably have the main coding of the SDK done, in a couple of weeks, but adapting the application to the new SDK, and fixing the inevitable swarm of bugs, will take a lot longer.

But it’s quite doable. It will work (I’ve done exactly this kind of thing, many times, before), and the final product will have a greatly-improved “killer feature,” as a result.

So I guess the TL;DR of that mess, is that the architecture, itself, needs to be planned in a way that affords reacting to unexpected stressors.

I love this. I've always used the idea of creating an MVP first, but I really like your box theory.

It basically was inspired by Scott Jenson's The Simplicity Shift.

https://jenson.org/The-Simplicity-Shift.pdf (Downloads a PDF).

Reply on news.ycombinator.com