Hacker News Reader

I was having a discussion with one of the people higher up in the org chart about why we need to move beyond a pizza-box development model. Currently what happens is that the CEO (small org, 10 people, he's effectively the CTO) makes small-talk with a dev about a feature that needs to be developed. The dev then goes and builds the thing based on the discussion (a week-10 day sprint), takes the resulting work to the CEO which will then flesh out what needs to happen in addition to the work done. There will be some iterations of this process until the code can be merged into main and the feature completed. It's not horrible really but it can be way more efficient. I'd really like it if we can move beyond this seat-of-the-pants programming and have a more robust documentation process. I've been a part of feature mills like that, I've built my own products (unsuccessfully business wise) and I've also done contracted work. Out of all of these I was most productive when doing contracted work. I think it was due to the customer having to really spell out all of the things wanted in the work product. The requirements analysis was far better than anything else I've ever touched. I don't know why it should be any less detailed when it concerns your own work. You should beforehand be certain that you know what you are about to build. You should state it in a document. The stakeholders should sign off on it being what they want built. All of this takes time and it should. The engineering part of it is mostly trivial. The hard part is building a consensus on what should be built.

That description of "pizza-box development" (unfamiliar term for me) sounds pretty good actually? Seems pretty agile: informal planning, time-boxed sprint, revisit with stakeholder, repeat. It gets so much worse when the implementers are further from the stakeholders or customers. What's the issue there?

I've also worked in consulting and appreciate the explicit requirements, but I find the formality much less efficient than the process you describe earlier. It ends up being very "waterfall" and exactly the approach the Agile Manifesto attempts to counter.

Perhaps you prefer a more waterfall, hierarchical development process, or the companies (big ones) or industries (highly regulated) that necessitate it?

Buy a pizza for the devs, rip off the lid, sharpie draw the sprint on the lid while eating the pizza.

As long as the next pizza lid doesn't contradict the last one, that sounds like a good early-stage startup process!

Even if it does, it means we’ve learnt something in the middle. And at least the first box was in production.

> a week-10 day sprint

A week-10 day sprint on _one feature_? They haven't drunk the scrum kool-aid yet. Just wait until they do - then every feature will be a "story", and no individual story will be allowed to be assigned more than 8 "story points" (which for some reason means "one day"). If you think a "story" will take more than 8 "story points", you'll be asked to break it down into "subtasks" of no more than 8 "story points" each (you'll be asked to do this accurately in a few minutes in a standup meeting). Trust me, if you tell a higher-up non-programmer that there's anything wrong with the development model, they'll hear "we need to move to the 'scrum' everything-is-mandated-to-take-less-than-a-day development model".

Don't scare us like that :-)

The most successful software company I have worked for used your “pizza-box” model all the time. With 150+ developers. It worked extremely well. The worst software company I have ever worked for spend 95% of its time documenting things and 5% of its time implementing things. It took forever to get anything done.

Somewhere betwixt those a happy medium lies

Not my experience at all (25+ years of experience working for companies in 5 different countries). However YMMV of course.

Well said. I think the key point you make is that we are paid to maximize the value of the business. If the business isn't profitable, we could all lose our jobs. Too many IC feel that if the company isn't maximizing their personal effort they are inefficient and wrong. However, sometimes more value can be added by NOT writing more code or more documents. It is sometimes more valuable to throw away a bunch of completed work and not fall victim to the sunk cost fallacy. Sometimes a "worse" architecture is the highest BV.

It's kind of trite to say that though. It's the business's job to ensure that the skills and resources at its disposal are put to good use, not yours.

We're not all a bunch of mini CEOs.

From what I understood, they are talking about the author’s complaint that he doesn’t get to spend 100% of his workday coding/testing/documenting. That doesn’t necessarily mean that the companies were poorly run - larger enterprises with more projects, teams and customers are going to require more meetings.

Maybe he worked at poorly managed companies, who knows. The fact that he was asked to participate in meetings instead of only being assigned purely code-related tasks isn’t very compelling evidence of a company being a “joke”.

I tend to find that where the PO/product job doesnt have to be shared with developers the velocity and quality of the product improves considerably.

I dont think that relatively speaking companies that dont do this are horribly run since it seems to be the norm but I can see why somebody who isnt used to it would rant.

In general larger companies do everything inefficiently. It's to be expected. Small companies wouldnt exist otherwise.

> the author’s complaint that he doesn’t get to spend 100% of his workday coding/testing/documenting

The author's complaint was that he only gets to spend 12-25% of his time on these tasks on a good day.

In my view the most effective organizations are made up of mini CEOs.

When you read about organizations which were highly effective there is usually a common theme of management by objective and giving people ownership. “The HP Way” and this speech by Rickhover are two such examples: https://govleaders.org/rickover.htm

An excellent illustration of the difference between a professional and an employee.

> The author seems like someone who just loves writing code as opposed to wanting to deliver maximum business value (As defined by the company), so it makes sense he dislikes big companies.

I think the point is that very little actual business value is being created. This not necessarily due to "actual business needs" but because of deterioration of culture over time and the inevitable principal-agent induced issue of managerial bloat.

Instead of accepting that increased communication needs will slow down everything to a crawl, how about eliminating needless communication? Thats how Amazon does it, and look where they are now.

It's always a worthy goal to try to improve communication efficiency, but it's also the case that a very common failure mode that programmers at the leaves of org charts do not understand what is driving the value of the business they're working in, and have an inflated sense of the importance of the code they're writing (or that they wish they were writing).

But that goes for everyone, until you can put it into numbers which aren't gamed. That's what is being challenged here. Do the communication methods as they exist today provide value, and to what degree? Do we have actual numbers?

Whenever the "we hate meetings / the current bureaucracy" crowd criticizes the current state of affairs, the opposition tends to seek the high ground and go "well but you just don't understand what drives value". Meanwhile, there is a surprising lack of numbers regarding all this.

Ironically, trying to measure this better would inevitably require more bureaucracy! It's a good point nonetheless.

But I'll also say a positive word for qualitative reasoning based on experience being a good first approximation of things. If something gets pushback from a lot of people who have spent a lot of time trying to coordinate large efforts, then it's worth considering that those people may be right. I don't know anyone who has spent a lot of time in one of these coordinating roles who thinks that the primary issue is too many meetings and not enough code being written.

>If something gets pushback from a lot of people who have spent a lot of time trying to coordinate large efforts, then it's worth considering that those people may be right.

It's one thing to consider it an approximation, it's another thing entirely to consider them "right" which is frequently followed with "so we won't investigate any further". Most of us don't live in situations where such decisions are actually critical. We can afford to criticize and experiment. Instead, this line of reasoning tends to be misused and shush any investigation.

>I don't know anyone who has spent a lot of time in one of these coordinating roles who thinks that the primary issue is too many meetings and not enough code being written.

And you don't think that group, much like others, may be a little self-reinforcing?

It isn't "so we won't investigate any further", it is "we don't think it is the best use of our resources to investigate this" and in my view it also implies "but if you have a good idea for how to investigate it empirically, please feel free to do so".

I don't think "that group" is self-reinforcing at all. Essentially everyone who comes in with no experience comes in thinking "meetings are crap, communication is crap, we just need to write code". Most of those people (but not all!) slowly but surely change their minds as they gain experience. But every one of those people is an opportunity for the thesis to be disproven. Similarly, nearly every new organization is an opportunity to try something new. Google didn't start out with lots of meetings and engineering committees and design review processes. They started out just wanting to write tons of code. They didn't hire management (or "agile") consultants or bring in outside managers as they grew to come tell them how to behave like a big company is supposed to. The people who started out writing all that code and ridiculing bureaucracy are the same people who eventually accrued processes to manage meteoric growth.

I really don't think people are as narrow-minded and closed off to this as you seem to believe. People are hungry for a better way to manage organization growth, it's just a high bar because people have seen lots of these kinds of efforts, and frankly just get kind of bored of chasing "one weird trick to make everyone way more productive" again and again.

Yes engineers can be at least as ignorant as the "MBA business types" they like to scoff at. I haven't seen that in a good engineer though.

Oh I have! It is pretty much universal in young engineers, many of whom are eventually great.

> it's also the case that a very common failure mode that programmers at the leaves of org charts do not understand what is driving the value of the business they're working in

If that's common and not being addressed, it must not be important. If it's not important, why mention it? Seems like victim-blaming.

"very little business value" is highly subjective. I'm sure that Amazon also has a lot of activities which generate "very little business value" under whatever measure you define.

Don't see how politics or "bickering over the pettiest feature like [...] what colour the chart should be" is what "deliver[ing] maximum business value" is about, as you put it.

The amount of energy and time spent on “politics” or “bickering over petty issues” is usually highly overstated by bloggers.

It’s easy to understand why. The 15 minutes spent bickering over the color of a button will be far more likely to leave an impression and remembered vs the 90 mins spent on ordinary, necessary and useful discussions in the same meeting.

Eh, it's been causing a lot of issues over a long period of time at least in my workplace, and it's been dragging projects that should've been 2-3 days to 2-3 WEEKS.

I'm sure it varies for people (which is why you're downplaying it), but for at least some of us, it is simply the truth, the reality we have to face every day we go to work.

Not sure I understand the thought behind the statement so apologies in advance if I am barking up the wrong tree, but communication scales beautifully in many different contexts. It's almost like a superpower if done right. I do agree though that poor communication does scale extremely poorly if that's what you meant.

Is there anything new ever written in this space or is everyone just repeating what Fred Brooks said in the 1970s?