[onion2k]

I believe it's largely down to short term goals versus long term goals.

From the business perspective, the company should do things quickly because that means the jobs are more profitable, cashflow is stable, and the business team believe that they can always find more clients even if the product is horrible. This is the short term outlook.

From the programmers perspective the company should do things slowly because that leads to more maintainable software, less technical debt, and higher quality products with fewer faults. Less money comes in, but the clients stick around for the quality goods. This is the long term outlook.

The thing that leads a company to fail is when neither side recognises is that both outlooks are wrong. You can't run a company churning out bad code forever because your technical team get annoyed and leave, but equally you can't build things forever because clients don't have unlimited money.

There is a balance. If one or both sides don't understand that then the business is not going to work well - it'll churn through developers or it'll never make much money.

If you find a job at a company that recognises the problem and attempts to resolve it you will be happy as a developer.

[erik123]

Given the fact that all corruption starts with the corruption of language, you will quickly have a good idea of what someone's job is. In programming, contradictory ambitions are pointless, because machines won't work properly if you allow them. In business or politics, you don't face machines but other people. It is perfectly normal for a business person or a politician to hide the contradictions in what he says by skillfully using and abusing meaningless words. The conflict between programmers and business people/politicians is that the latter are not aware of the fact that their contradictions may work absolutely fine in marketing or advertizing but that they will not fly if the field of software. Here a link to Orwell's "Politics and the English language": https://www.mtholyoke.edu/acad/intrel/orwell46.htm. He is way more proficient than me at explaining what the problem is all about. By the way, this is the real reason why healthcare.gov from the get-go never had a snowball's chance in hell to go live for a reasonable budget and within the desired timeframe.

[informatimago]

Indeed. Check http://www.ribbonfarm.com/the-gervais-principle/

[seren]

On a related note, project management role tends to move quickly from one project to another, while the technical people are always responsible for the same area of the code/product.

As a consequence, what tends to happen, is that the project management tries to release as early as possible, and this is their primary role and they are accountable for it, but when you got a robustness issue in one or multiple customer site 6 months later, no one will ask the project manager to fix the issue, but the technical people will be under high pressure and will have to justify why the issue has not been caught earlier.

On the same vein, project management won't necessarily have any issue increasing the technical debt, since they might not be the one leading the next major product iteration, so they have the option to pass the debt to someone else so to speak. On the other hand, the technical team has never that option available.

This is an awful generalization, and some people are more mindful than other of the consequences, but this is a general tendency I have seen in multiple places. This is just another way to look at the long term with short term consequences.

[kourt]

bad code forever because your technical team get annoyed and leave

And the effects of technical debt and bad code will eventually result in slow iteration and poor product quality which will eventually become visible to customers.

[voidlogic]

This x1000. I think that OPs sentence above was the only off part of their assessment, most was spot on.

When I was a consultant integrating niche specific 3rd party apps, where even the "major vendor" was often a pretty small operation. It was not uncommon to see this happen.

Slow releases, years of minor updates, with "the big update" always on the horizon. Inability to come out with a 64-bit version, etc. All very common and signs of poor project management, technical debt, or most likely, both.

Sometimes we would be resolving issues with their "support engineers" only to realize they had like 2 developers (one of which we were talking to) and a whole team of sales guys.

[holograham]

I find this binary opinion flawed.

Programmers have short term and long term views. If you push a release out with a huge painful bug you will QUICKLY rush a fix out even if you go into technical debt to do so. Alternatively (good) programmers do have long term goals in maintainable and stable code bases to deliver consistent quality software to end users.

Likewise a business-type has short term goals -- quarterly earnings, quarterly service signups, business performance metrics, etc to investors/wall street. But alternatively must have long terms goals too to keep the business alive and growing. Investors do care immensely about quarterly results but they also care about long term results. No one will invest in a company that is likely to go bankrupt after the next quarter. IMO business folks get lambasted a little too much on their "short term" focus. Point me to a company that had a strong quarter than is likely to go bankrupt within a year or two (no hindsight comparisons). Business types are constantly balancing short vs long term goals and companies are constantly figuring out better incentive structures to reward business-types for that balance. Is it perfect? No. Are there exceptions? Yes. But it's what is happening every day in the business world.

[zura]

Also, programmers are usually "to the point" people, while business people love buzzwords.

[gk1]

Condescending remarks like this don't help the issue. A business person can also say "Business people are down to earth, while programmers love to use jargon that nobody understands."

There are good and bad communicators on both sides.

[erik123]

There is a reason why anybody who works in a job in which he faces the laws of nature, will prefer a very precise vocabulary and will shy away from using words that could not possibly have an unambiguous meaning. It is exactly the opposite of what for example advertisers, politicians or business people do. They want to keep everything as ambiguous as possible. They do this because in their jobs they do not face the laws of nature but other people. So, it is way less of a problem for them than for an engineer. The bridge will simply collapse if the computations are ambiguous.

[onion2k]

Not the most scientific test in the world, but Wikipedia's 'List of Buzzwords'[1] page has 79 for business and 82 for technology. Programmers love them more!

[1] http://en.wikipedia.org/wiki/List_of_buzzwords

[TheCoelacanth]

Many of the technology buzzwords are actually business buzzwords, not programming buzzwords. For instance, PaaS and SaaS are business models, not anything technical. Cloud and Digital Rights Management are marketing terms.

[robmccoll]

Does your experience with business people resonate with this at all? http://www.youtube.com/watch?v=GyV_UG60dD4

[simonswords82]

I'm sure there are some business people who love buzzwords but surely you're not saying that ALL business people (anybody who runs a business) love buzzwords?

[waps]

I think you're being very optimistic about programmer motivations, to be honest.

> From the programmers perspective the company should do things slowly because that leads to more maintainable software, less technical debt, and higher quality products with fewer faults. Less money comes in, but the clients stick around for the quality goods. This is the long term outlook.

This is the good version. But as we all know, to some extent these factors play a role too :

1) programmers have lost the battle with the software's complexity, but are fighting to retain control of it. This can also be a manager.

2) programmers have invested in certain technical decisions (a programming language, framework, ... whatever) and are unwilling to consider swapping it out, even when it's obsolete

(We all have seen the database product used in large firms that started life as a windows application, and has "moved to the web". Instead of writing a web interface, these fine people have written something like a VNC server that runs the actual application, and a JavaScript client that just downloads the pixels, and sends mouse events to the server. Sigh)

3) Programmers are trying to solve an "interesting technical challenge" that they DO NOT HAVE. An example would be a datacenter management solution for a webhosting company. Automated failover, globally distributed RPC, horizontally scalable load balancers, nosql replicated datastores ... That's great if it takes 10% of their time (because every now and then, they do build a great system), it's a disaster if it takes 90% of their time. But since it is so much more interesting than solving customer 1538's problem with the current reporting system ...

4) programmers have formed a clique, and are "going for job security"

Given the organisations most programmers work in, I feel sympathy for people using factors like this. We all know how responsible banks' management is, so I do not think doing any of the above against them even approaches immoral actions.

But what I'd like to state is that as a young programmer, or project manager, approaching problems in large companies without looking for the above factors is likely to result in disaster.

[dochtman]

On balance, I don't think programmer motivations worse than businesspeople motivations on average, though.