Hacker News Reader

Comment by zakum1 | Hacker News Reader

The reason that software projects deliver so poorly in the corporate world is that senior executives and investors understand them so poorly that a large amount of recognition and attention goes to those who can "bullshit" rather than fix the problem.

This is particularly toxic, because often the senior executives and investors also have an interest in hiding the failure (avoiding personal accountability and avoiding write-downs on investment).

It is very hard to see how a culture of true reflection and learning can emerge in this environment.

View on HN

I think the biggest problem is getting the requirements right (as much as possible) prior to the actual coding.

Many managers seem to think that they can easily change the requirements in the middle of the project.

Requirements, infrastructure components, platform systems and promises from external vendors that "it'll totally be ready by the time you launch".

This is all things I've seen in the last month (yeah I'm not joining any more greenfield projects within organizations - if you think you're going to rebuild it from scratch and fix all the problems, you have no idea what went wrong in the first place).

Yeah but behind your "as much as possible" statement hides the whole softwar engineering profession. Getting the requirements right sometimes can paralize a team, making it loose "capabilities" or momentum or even having attrition impact. There's no single PM methodology solution to avoid having the deal with the tradeoffs associated with the agile vs. waterfall dichotomy.

Behind any popular or profitable succesfull software project there are sometimes as much "PMing" practices as there are coders.

It might be even the idea that (without an effort that matches or exceeds the implementation itself), you can "get the requirements right", i.e. that there is a point in time where the requirements are complete, fully understood and thoroughly specified.

Given the enormous scope of some of these projects I wonder if a prototype phase would help. Humans seem to have a hard time with conceptualizing and a slow, barely/non working and unscalable prototype might be worth the added cost/time. If it’s part of the requirement gathering process with explicit expectations set that it’s a prototype would it facilitate better requirements input? Naturally you’d have some people making assumptions about its fitness as a final product or MVP but (if a UI is involved) giant bright warning banners plastered all over might help with that.

The default state of a software prototype is to be shipped into production.

> Many managers seem to think that they can easily change the requirements in the middle of the project.

"But of course I can change anything I want, whenever I want, and you all are supposed to handle it. That's why we use Agile!"

You're right, it's hard to correctly spec out a software project. You can't build a house without the plans.

Another big factor is testing/QA. If your customer service department isn't going to throughly test your new program, and nobody holds them accountable, who gets blamed on launch day when it doesn't work right? IT!

You can build a simple house without formal plans, most especially if architect, builder, and owner/occupant are the same.

Divide roles, or increase complexity of the project, or its relationships with the surrounding infrastructure, and planning or standardisation requirements escalate quickly.

Yes, you can build a simple house like that. But what if halfway through the construction, the client says they want the bathroom on the other side of the house? You'd have to redo (e.g.) all the plumbing from the ground up, location of the heating system, walls, doors, perhaps even staircases ... etc. etc.

Note that amongst my qualifiers was unity of client and builder-architect.

You'll find plenty of examples of people on DIY or lone-inventor projects saying "we tried X, it didn't work, so we did Y instead. That's the unity-actor case of your hypothetical.

Dividing executive-agent roles is a complexity dimension.

Dividing executive (decision), design, expert (engineering), sourcing, external approval, interface, and labour/crafstmaan roles are multiple additional complexitty dimensions. And this doesn't even include the technical dimensions of the project and its infrastructure interfaces / interconnects.

Complexity is interaction between components and entities.

A form of Gresham's Law, whose generalised form is that equivalent current-cycle benefits outweigh non-apparent long term net advantage (benefit less cost). Or even more generally: a complexity constraint.

Risk is a nonapparent long-form cost, and unless specifically manifested (insurance, regulations, fines), will be ignored.

The results of a scholarly search for "a gresham's law of" are illuminating, spanning divorce, neighbourhoods, academic admissions, environmental regulations, incorporation, shipping, management, court citations, television programming, politics, and more.

https://scholar.google.com/scholar?q="a%20gresham%27s%20law%...

That's not the problem; looking at it as a cost center is. It all boils down to not enough growth.

It's seen as a cost centre because no one can manage it in any other way. The consultants have found one way to provide some results sometimes, but aren't motivated or able to do better.

What might alternatives be?

How about treating it as capital with a risk-return element, say?

omg in my dreams: then it would be an asset on the balance sheet and it would be a shareholder value increasing move to improve it. CIO becomes = CFO.

Reply on news.ycombinator.com