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.
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.
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.
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.
There are good and bad communicators on both sides.
> 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
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.
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.
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.
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.
years and years of Dilbert, for one.
"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 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!
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.
The first paragraph is spot on.
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.
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.
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?
"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.
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.
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.
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.
@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.
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.
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.
That said, there are plenty of conflicts between programmers and their managers. Usually, it's because the management doesn't understand programming.
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.
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.
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.
Like the cool guys at school back in the days.
b> How long it will take?
p> About 2 months.
b> We need it in 1 week.
....
http://www.nytimes.com/2009/11/03/health/03asperger.html?pag...