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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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?
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.
Business people who don't take the time to listen and understand what they're managing will pick what sounds like the path of least resistance.
If the buisness people cannot be reasoned with this will result in staff not telling them what they're really spending their time on.
At this point management either a) steps back or b) buckles down and micromanages.
Results:
a) Unless there is some internal leadership within the team or you have rather good and motivated people, this will result in the team doing what they want, which will mostly be CV-Driven-Development or playing with the new shiney.
b) Important steps will be skipped, likely the team will feel the decisions are made outwith the group, yet the group suffers from the results of said decisions. Moral of the team will go down.
This isn't specific to programmers, any time you get management that's willing to bury their head in the sand and not understand their subject matter, you've got this problem. Team performance will go down and if this results in rotating non-technical management who all end up going down this road, you'll breed programmers that simply think all managers are useless.
This is the with career managers. The problem with technical managers is they often simply don't know how to manage. You want someone who can do both and who actually cares about delivering value to whomever your customer might be.
"Oh, East is East, and West is West, and never the twain shall meet."
Rudyard Kipling
Jokes aside, I think the OP is generalizing. Personally I get on fine with the vast majority of business people.
I don't get on with people that are incompetent. I also don't get on with people who have a lot to learn but pretend they don't. Some of those are business people. Some of them are fellow programmers.
Normally business people (sales) have features in mind that they know (or think) customers want. Customers often think they want something to deliver a business process that solves a particular problem, but might not be the most efficient process. Programmers are concerned with the management and control of their code-base. Often programmers cannot see the financial or business case for a new feature request. In many cases, it isn't really their job to do so, but it does help to understand the requirement.
As a result the two parties often have problems seeing eye to eye. However, this is a good thing. If we agreed with everything business people wanted then we'd have applications full of features, many of which nobody wanted. If programmers got their way then we'd have applications that no clients would want to use and buy.
In general each party has a niche of knowledge that the others don't. When each party can learn to appreciate the experience and knowledge of the others, then they can work together successfully.
There definitely is a schism, and I think it's largely down to different mind sets. Business people, have to be people people. They have to be able to manipulate emotions and be persuasive.
Whereas programmers tend to be more absolute, more black and white. We haven't evolved our skill sets to include persuasiveness or the businessman like people abilities, simply because we haven't had to.
Both types have adapted to their own environments, and they're entirely different environments.
I think a big part of the problem with programmers and business types is both parties not understanding each other psychologically. Programmers are strange creatures, often stubborn, highly intelligent, don't like being told what to do.
Project managers however are highly motivated, hard-working and like to push things forward. But you have to know how to speak to programmers, we're good at figuring out the 'how's' but we also need to know the clear 'why's'. They need to make the case to us instead of just telling us what to do, we like to feel in control. But they often give orders and we get defensive.
In summary, programmers need to understand that project managers and business people are just trying to push things forward, it's their job to try to get things done (let's face it, a lot of us would be sat on here all day without them). But business people need to understand what they need and be able to explain it properly to us without giving us direct orders.
They do - frequently and often. If you see a deep and non-personality based conflict it means there is a political disjoint within the company - the incentives for either side are misaligned - either because one or both sides have lost contact with customers and that having to clearly and logically spell out the disjoint is raising up a political problem the hierarchy is unwilling to deal with.
In short, if we don't address the difference in strategy represented by the Sales Director and the Operations Director then when the two different strategies and priorities are given to a programmer to implement - we can blame their kvetching on "IT guys"'instead of the two directors.
As for a solution: I would abandon Agile in such cases (!) and ask the board of directors onto a two day coached off site where we will address the issue. And suggest everyone polish their CVs in case.
Really interesting way to look at it, I think theirs a generalisation amongst businesses to think that the programmer is just a function rather than an opinion/craft i.e. putting a paper inside a printer, thats it just code.
I do not think a day or two somewhere can cure organizational dysfunction. You need to change the way people are working, incentives and processes. They will fall into the old patterns otherwise, no matter how motivated everyone after those two days will be.
They can, and they do. Sometimes they are even the same people. Where are you getting your premises?
If what you really meant to ask is "Why do two groups of people who operate differently sometimes operate differently?" then I think the answer is obvious.
In my experience, the gap was more between "people that do things/makers" (designers, hackers, texters, testers, linguists, statistics people) and "people that talk" (aka business type people, usually economy students). It occured that the talking-only people where at some point so out of touch from the work that actually happens, but yet in charge, and interfering with everybody.
Sounds like broken company culture, not a general truth. I've never experienced that problem anywhere I have worked. The only problem I've seen is that the "talkers" often do not know what is possible, and the "makers" often don't know what the business needs to actually make money. The big moves come when both sides get together to determine the company's direction.
"Not getting along" is what happens when one believes that "I" is more important than "we".
Once one gets beyond themselves, one can "get along". They still may not agree, but now they've put themselves in a position to solve problems, not perpetuate conflict.
This is also true in the general class "Why x can't get along with y," not just for programmers and business type people.
I run a software house and work with programmers every day. I'm a business type person (I guess?) in that I'm the CEO, but I'm an ex-programmer, so I'm a weird hybrid of the two types of person you're trying to draw a line between.
I think the question you're asking leads us to look for reasons why ALL business people can't get on with ALL programmers, which is simply untrue. There's lots of business people around the world happily working with programmers, and I'm one of them.
For me a good programmer is not good just because they can rattle off reams of beautiful code and fix bugs insanely quickly. A good programmer must also be able to prioritise their work, manage their time, communicate effectively, understand the wider context of the work they do and much much more. These skills outside of their core skills I refer to as "soft skills", and they're necessary in all walks of life not just programming.
In the same way, a good business person is not a good business person just because they can run a business that makes money. To get along with their employees they will need to be able to delegate work, communicate effectively, plan ahead and so on. Again, these soft skills are just as important as the ability to make money.
So if a business man who is only good at making money works with a programmer who can rattle off code, and they lack the aforementioned soft skills...they're going to have a hard time working with one another. Equally, if either of the two individuals lacks soft skills, the relationship is going to suffer.
What's really interesting (in my experience) is that a rockstar programmer without soft skills isn't just going to struggle to get along with business type people, she's going to struggle to get along with everybody!
Many can. And they're the ones who make a lot of money, especially if they're consultants who align with the goals of the business. I think patio11 has written on this topic several times.
Sometimes IT staff don't get on with people from "the business" and sometimes people from one department of "the business" don't get along with someone from another part of "the business". Usually stems from a lack of empathy. Often people get so wrapped up in their own department's work that they don't stop to consider how things are working in other departments and what pressures the other person may be facing.
Totally frustrating for all concerned. It so often feels like everyone has forgotten why they are there (to define, build, test and ship something) and just spend their whole time butting heads against each other because the other person is not doing things exactly the same way as they do.
You are not in business to "define, build, test and ship something". You are in business to make money and the development process helps with one of the ways to make money.
People constructing are accountable for being able to build on time (announcing fair informations). Constructing/building a product (not only coding) require the most accurate information possible and accountability. People are paid mostly with a (lower than business) fixed amount of money.
People selling relies on assymetry of informations. They are paid on commission (often not on the benefits but a percentage of the gross sell).
The business are hired with an incentive to lie, the builders are fired if they do so.
Business makes all the more money that coding costs less, and vice versa. And both coders and business are understood to be valuable and listened to. This is a classical conflict of interest.
If you had the classical Babel tower problem, some social origin issues (business schools are expensive), and what could be considered an unfair share of the values regarding the costs for persons (remember a coder lose all IPs on its works and his paid less than a business person making money on their relation ships that they are «free» to keep), than you have also a very simple marxist doxa (know how to make money) vs praxein (how to do) problem of unfair repartition of value. And according to marx it results in conflict between proletarian (coders) vs capitalists (business).
To sum up, take whatever explication you want it is a stupid logical conflict: a power struggle (that need no symmetry) because as pointed here and there by other contributors the incentive/goals are differents but they share the future/resources of the same company.
The relationship between technical and sales is always going to be complex.
A salesperson has to not only sell, but retain customers. It's their job, regardless of where the product is at. Customers are not easily acquired and the position is unforgiving.
As a hybrid sales/development guy, I was always conflicted selling products that I found myself having to convince users to stick with it on the renewal, because the product is not performing as it should or as promised. It was the technical side of me knowing this product is not really where it should be, just good enough.
And the clauses, yuck!, cancellation fees to end contracts, worst conversation to have with someone you're trying to build a relationship with. For anyone with a conscience, it's a hard position to be in but that's what you are being paid to do, sell. To survive you have to be at peace with the process and have a long term outlook that the product will get better.
It's crushing to have to sell a not so great product just as much as it is hard to push one out. I think what really makes the difference is the company culture and shared vision. If people are not ultimately working toward the same long term goal, there is going to be a disconnect.
Misleading question since it implies that all programmers dont get along with business types.
Clearly a subset of programmers DO get along with business types after all most established companies have programmers working for business types. Similarly many startup founders are BOTH a programmer and a businessperson.
A better HN question IMO would be: How do programmers and business-types communicate better?
A very generic question, so I'll put out a very generic answer.
"Business" is about making stuff people want. Business folks work with each other -- many times under low levels of trust and high levels of risk -- to make something people want.
"Programmers" already know what they're doing: programming. Therefore programmers really don't care so much about what people want. Somebody is paying them, so they program. They work inside a tight domain and usually with a small number of people that they get to know over a long-ish period of time.
These are two vastly different universes. Business folks are always using business skills to interact with coders: negotiation, price commitment, conflict facilitation, and so forth. They don't care what whiz-bang you are using to do the job. They just want the value.
Programmers are always applying programming skills to non-programming domains. Why doesn't the business know exactly what it wants? Why do they keep hassling us with providing estimates? How can people who are so clueless about things actually be running the marketing department? Why do they keep pushing for unrealistic schedules? And so on.
Very early on, organizations start stove-piping jobs. Bill is a CPA. He should only do accounting stuff. Joe is really good with people. We're just going to have him do pre-sales. Amit is a database guru. We'll have him do all the DBA work. We need to have some defined roles around here! Where's my job description?
This seems to make sense, but over and over again, this logical separation of concerns comes back to bite. After a year or so of doing just the "DBA work", whatever that is. He starts viewing things not involving database administration as a waste of time.
You keep that up over many years, and allow the company to grow? You've got a bunch of folks who all like the folks they interact with and see everyday, but are deeply suspicious and completely clueless about everybody else. Not a good thing.
I'm with onion2k on this one. It's mostly do to with differing mindsets and world views.
I'm not a coder, I'm in Digital Marketing, but yesterday I had a meeting with management regards their Google Ads campaign. A simplistic overview of the dilemma I had yesterday: We need to collect data on how well their site is performing for which we need to run trial campaigns so that we can analyse data. The management team see it purely as an expense and don't see the value of the "learning" exercise. That causes a struggle. Now the result is that the campaign that will be run is already compromising the quality of the learning that we can do, and this because the "Business" people have to be answered to.
For me the division is mostly centered on quality.
The sales I'm working with want me to ship whatever, ship fast.
I want to ship quality.
Since money always wins, this usually ends with me giving in, feeling bad about it and .. blaming the sales people for being short-sighted/focused on the immediate return only.
Something to keep in mind about quality - sometimes programmers spend ages doing something in a way that seems like the right way, and the end result is either unimpressive, or a disaster. That destroys goodwill.
A project manager who had a history of working with unreliable developers may be drawn to a mindset of only trusting near wins, or even distrusting elegance-based arguments.
How many products (physical or virtual) have absolute quality? What is the price point and competitive advantage of your product? Software is no different than physical products in balancing quality with price. The only advantage software has is that we can improve the quality later.
If people buy your product because it has the fewest bugs and is more resilient when things go wrong then push hard on the sales team. But if your product gets sold due to it looking nice and having a few wiz bang features then give them some slack.
It comes down to 3 things:
1. Communication
2. Different incentives/goals
3. Modus operandi
@1 Tech people speak tech - no marketing bullshit. Business people often don't understand what programmers are saying and it causes the frustration. Mental models are skewed by marketing and sales.
@2 Programmers want to build things properly, use cool stuff and develop skills. Business guys want to meet their quarterly targets.
@3 Business people want to solve problems with money. A lot of problems cannot be solved that way. They have a internal voice whispering "reduce cost and increase revenue", but it doesn't say "technical debt".
PS This is not binary. Programmers can behave like business types and vice versa.
Here are my 2 cents, since i am involved in both management and programming.
Developers and programmers are often right about their opinions. BUT, that opinion is not always the output that company wants. Here is a simple example;
- Company wants to get rid of one of their products. (not enough sales, a new better product is planned, etc. )
- Dev lead wants to have extra resource for his/her team because of deadlines etc.
- It gets rejected
- Dev lead warns the company that releases will be delayed and customers will not be happy (true)
- Manager doesn't do anything about it because product's future is already decided.
- Dev lead is not happy about this decision.
It is kind of hard to satisfy both management and employees at the same time but that is the nature of it.
One source of conflict is that many "business type" tasks/projects can be fairly easily time-scoped: "a report about opportunities for our product in Poland" can be a 5 minute comparison of populations, or a multi-year PhD dissertation.
Technical work often has a more rigid "minimum viable solution": a civil engineer can't just give up on a bridge halfway over a river, nor can he say "I just skipped the wind loading calculations and hope the school buses don't run on windy days." Some types of software (especially embedded e.g., aerospace and automotive) have similar concerns about safety and warranty.
Business people are only in for the money (and power). Programmers are little artists interested in something that
in it's core has nothing to do with money. Programming is about a passion for creating things with technology.
The main problem is that most people are taught, and still think, that money makes things possible, while in
reality money is the most destructive thing mankind has ever encountered. Money hinders development
in so many ways, not to speak of the horror it causes like: wars, poverty, abuse, pollution and much more.
Business people do not understand this.
Huh? Working means getting along with different kinds of people.
I think that if you aren't getting along with a business person, it is incumbent on both of you to discover what the disconnect is. What are you each missing? Maybe it is an understanding of technical limitations on their part, or a blind spot about the business on yours.
Except in the case of ill will on someone's part, discussion between adults should resolve the problem. If there's ill will, that's a good job to leave.
When I've seen problems before, it's usually due to a lack of mutual respect. Either you have the business people thinking of the programmers as relatively useless nerds who can't do anything right on their own, or you have the programmers thinking that the business people basically sit around and do nothing.
I've never seen any real problems if both sides realize and understand that what the other side is doing is important and not easy.
Looks at what they do, and you'll find the source of their biases.
A coder works with objects that are between math and infrastructure. From math, he gets the logical reasoning. From infrastructure, the long term need for solidity. A coder is also much product oriented.
Bizdev works with more fluid concepts (perception and human psychology) and focus more on the cash flow. Time is essential in business, a good product late rarely succeed.
This is silly, and untrue. Any business where this is a case,is a business that is doomed in the first place - the best people get along fine across the spectrum.
For me,im implement accounting.most customer want to follow their rule.no gap no frs or whatever.just request.customer need third party accountant to consult so smooth project.i see havoc in oracle e business and baan implementation.internal staff request non functional and destroy the good base erp.their vendor everyday meeting and meeting and day by day programmer left..
I hope you're being tongue in cheek, because if not you've missed the point that while you think that, business people will think exactly the same about you from the other side.
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.