Hacker News Reader

Comment by ahoyhere | Hacker News Reader

A little outside perspective: This is exactly the way it goes with a huge percentage of IT-related projects, in many serious industries. The "Enterprise" is screwed.

View on HN

I think the key factors are politics and managerial ignorance - there appears to be a general consensus that the most qualified person for the job is the a. biggest suck up and b. the least technically knowledgeable guy/gal available.

The problem with having politicals in senior positions is that they will, by their nature, happily abandon honesty + humility - the two most important qualities required by devs/management for any software project to even have a chance of something approaching sane completion.

Unfortunately politics and honesty/humility are not compatible.

Luckily there are companies out there that 'get it', but depressingly few.

>The problem with having politicals in senior positions

This is a problem having politicals in any position of power what so ever.

The old saw about how the only person who should be in power is the person who doesn't want to be in power, huh?

Well, to be honest I think in some future time people will find it so strange that there was a time when decisions about critical aspects of a country where in the hands of people who were only experts at making people like them.

This is why creating an "advanced technology" or "R&D" unit in the business is very risky. You have to be sure you actually do get the elite, and not just the people who want to play with shiny toys and have the connections to get the plum assgnments.

That's very true, and sadly it's also true that most of the time, the people choosing the purported elite are the least qualified to do so.

The one thing about large enterprise projects is though, you can usually convince the mismanagers that it's good for their career, and the mismanagers end up disliking the competent programmers. If you're a vulture or a hyena a large IT project can become like a elephant corpse, easy pickings. Convince the mismanagers to move competent people to your team in exchange for your yes men. Then find a piece of infrastructure you need for your project and offer to build it for the larger project. This is basically an excuse to use their infrastructure, db servers, test servers, etc. Use this to get buy in to slip your own schedule so you have time to deal with the inevitable feature creep. Go to the design and planning meetings and suggest new and exciting technologies that they can figure out. When it doesn't work, take the hardware they req'd off their hands for the infrastructure you offered to build them. Make sure you integrate your project to the infrastructure first (you can always pitch it as reducing risk to the large project) so they can't make any changes to it with out breaking production code.

But why would I want to do all these things for the benefit of a toxic organization? That system feeds off people who try to do the right thing, then it chews them up and spits them out. In fact it relies on there being people who will do the right thing even tho' it means extra stress and no extra reward. Organizations like that deserve to collapse under their own weight.

Same reason millionaires want more money: it's about the game.

Not quite.

I read it as a strategy for firewalling off a section of the organisation from the useless people, which enables you do enjoy your work.

... For the benefit of the management tier above that allowed the toxic situation to develop in the first place. You can bet that you won't see any of the profits yourself, and they're laughing all the way to the bank, they took their eyes off the ball and still scored.

It's not as simple as that.

Firstly, money isn't everything for most people. Enterprise work can be interesting and rewarding, because you deal with problems that are quite different to the consumer space. If you can escape the toxic situations somehow, that is enough for many people

Secondly, enterprise work can be rewarding financially. Contract rates of $70-$150/hour mean that you make pretty decent money very reliably. Those rates let you hire pretty talented people, and if you can firewall them off from the wider issues in the company you can do pretty good work.

I don't know about the enterprise area, but when this happens in the gamedev industry (and it happens a lot), it's extra depressing because 90%+ of the people working on it will have poured their life and soul into it and really care. We're not talking individuals in a sea of office drones.

Part of the problem is that "release early, release often" is hard to do when it comes to entertainment products. MMOs & social games are starting to change that, but nothing close to the sort of pivoting you can do with, say, a productivity web app.

Yes, everyone who works on software for any company other than gaming doesn't "really care" at all. We don't care if your ATM transaction works flawlessly. We don't care if the health monitors keep you alive while you're in a hospital bed. We don't care if you accidentally show up on a police blotter because a database went corrupt somewhere.

Nope, but if we were working on games, we would care then.

You're trying to attack something I never even said. OP was talking about the "enterprise", which is known for its low-hanging fruit of embarrassingly terrible software. You seem to be talking about specialist systems software for banks, medical engineering, etc. or even software in general.

Well, that's because bank and medical software usually falls under the "enterprise" umbrella. So, while you may be right that a lot of enterprise software is terrible, there are projects in said enterprises that work great and for which people developing them care a lot. You generalized, so he/she struck back with a general statement.

Wait, I'm generalising?

silverbax88 interpreted my

"I don't know about the enterprise area"

to mean

"Yes, everyone who works on software for any company other than gaming doesn't "really care" at all"

And I'm the one jumping to conclusions?

All I know is I've yet to meet someone in gamedev who doesn't care about the product they're working on. Probably because the pay is much lower for the same level of skill as elsewhere, so you won't find anyone doing it for the money. Have I met software developers in other areas who don't give a crap? Lots. Have I met ones who care? Also lots. None of this contradicts anything I've said.

Your sarcasm is wrong, because you are claiming the converse of what pmjordan claimed. Its a common logical fallacy.

Sometimes it feels this is so because we have a lot less number of ruins when it comes to IT related projects. Stop construction of a building you have a gigantic half constructed bloat of concrete and bricks. Nothing can be reused (except for the land). Stop construction of a program and you will have some files which can be deleted, all the machines are general purpose and all this can be reused.

I think it is partially because nobody has figured out how to reliably estimate project costs and timetables for software. If houses routinely came with estimates like "We think this house will cost between $200k and $2.6 million to build, and it could be done in between 6 months and 10 years, and at the end it may or may not have a bathroom", every general contractor in the country would be in the unemployment line.

"Oh, the wizards burned through another $300,000 last month. Well, who knows what those wizards do. Tell them to get the payroll system ready by next month, OK?"

I think the problem is more fundamental than that. The requirements for a house are pretty much static. The requirements for an application are often in constant flux.

I think the requirements for the house change a lot more than you think. There's definitely a push/pull with the client in civil engineering as well. And for contractors, oh boy, do they deal with clients changing things on them constantly.

I don't have much faith in most Enterprisey teams to ship good software even if they have a thorough concrete spec. We love to blame changing / incomplete specs, but I'd imagine that most dysfunctional teams would manage to bone up a perfect spec anyway.

The largest problem is that the people telling you what they want are not good enough to through every possible path the user may want to go down. This leads to specs that are ambiguous at best, contradictory at worst. It takes a good developer to see the hidden things in the spec and raise the questions that need to be asked before the development goes too far down a bad path.

Programmers have it worse: http://ifaq.wap.org/computers/architects.html

What makes up a house is generally understood. A application or game is often a custom job with all sorts of different features and functions. Any decent company should be measuring these things as best they can. It appears that is often isn't done. It's remarkable that EA hasn't been able to do this since they have a bevy of projects that they should be able to use as a rough yard stick.

The analogy fails though because most houses are build in a standardized way, software would have to be pretty much wholly the result of picking and matching preexisting components.

Houses probably aren't the best comparison. Commercial real estate is probably better, being a larger investment and with more interests pulling in different directions.

http://i2.photobucket.com/albums/y17/jamesinclair/IMG_6378.j...

A huge hole in the middle of Boston's Downtown Crossing shopping district.

The historic Filene's department store building was torn out, to be replaced with a 38 story tower. Funding evaporated. The project stalled in November of 2008.

  The software entity is constantly subject to pressures for  
  change. Of course, so are buildings, cars, computers. But 
  manufactured things are infrequently changed after 
  manufacture; they are superseded by later models, or 
  essential changes are incorporated into
  copies of the same basic design. Callbacks 
  of automobiles are ready quite infrequent; field changes of 
  computers somewhat less so. Both are much less frequent than 
  modifications to fielded software.

  In part, this is so because the software of a system 
  embodies its function, and the function is the part that 
  most feels the pressures of change. In part it is because 
  software can be changed more easily--it is pure thought- 
  stuff, infinitely malleable.

- Fred Brooks, No Silver Bullet

Good essay but I don't think he adequately addressed the problem of transaction costs for changing software, either in process or later updating, of course that wasn't his primary point (it has been a while since I read it and I could be misremembering).

I think you've just described government contracting.

Ahem:

http://en.wikipedia.org/wiki/Scottish_Parliament_Building#Ti...

> you will have some files which can be deleted

I sure hope nobody deletes files after stopping work on a project. What a waste. Storage is so incredibly cheap...

Agreed. Putting files on tape and sending them to Iron Mountain is the new Delete button.

I agree. There is no field of human endeavor (except war) where you can spend so much and have so little to show for it, as the enterprise software business.

Reply on news.ycombinator.com