Ask HN: Founders, what is the worst experience you had with developers?
And how did you manage to solve the problem?
Every time the development team could not grasp what was required. You literally had to exchange 20 emails with them for each specific point. Of course, this just increased the length of time for scope and in all cases furthered the time of the project.
Each stage of the application was over engineered to infinity. Spaghetti code everywhere and nonsensical functions, callbacks, literally everything was what the hell was the developer thinking.
Of course it just about worked. They had to ship something, but it was slow. The UI was painted into a corner, in some cases doing the wrong thing literally crashed the browser because of an infinity loop or took too much memory.
Some apps had about a billion dependencies and therefore could never be secure. I'm not kidding either, it's like the developer was a plumber instead of actually knowing how to code the simplest of things.
There was no way to ever extend it to build atop newer features or have any sort of roadmap for user requests.
In every single time, management outsourced and took the bid from the lowest priced company. How to solve the problem? Start from scratch with a competent local company with an actual design and development process.
Want to know the best bit? One company I know of, who spent $6 million dollars on a project with an Indian company. An in-house developer took 3 months as a side project and rebuilt it from scratch. It ended up being the code from there on in.
I have NIH syndrome due to seeing these issues pop-up time and time again. In my career I've seen well over $15-20m being wasted in projects due to management being completely incompetent and thinking sitting on the phone with a dev team will ensure success.
Turns out good engineers make good money. I've worked with some brilliant engineers from India-based consulting teams, and they were not cheap.
And then six months down the road, "why are all our systems so shoddy?" "Why are our development cycles so long?"
As a consultant, I've seen this pattern so many times it's insane. And depressing... and for better or worse, lucrative.
An HR manager once said each hire is a compromise in some way because no two candidates are alike.
One key in hiring remote is to take some extra time to get to know the candidates via video calls to create a connection and better determine what their strengths and weaknesses are, and get the conversation to a point where the compromise is acknowledged and you can talk about their ability to learn what they don't know and examples of that.
How effectively a developer can learn and apply new knowledge is they main thing I look for. Learning while you work is the new norm, but hiring is not always setup that way.
I have had good experiences with outsourcing in India itself as well, there are some serious teams there too. But there were some bad cases as well.
Money is definitely an indicator of quality, expensive might not mean good but cheap almost always means they're not top talent.
They should have regularly reviewed the work that was being done and if they had issues resolved them during the warranty period.
Your company chose the lowest priced company and was surprised when the quality of the work wasn't great. Because this isn't just unique to just India. This happens everywhere. To counteract this story. I worked at Apple where they used offshore engineers from India and the quality of the work was excellent.
You get what you pay for.
The lowest costs, of course, will win out in this case.
The only fix for that problem is replace management, which would have to be done ... by management.
We're supposed to get incomplete specs, it's the only way everyone can end up happy. It doesn't help pointing fingers at an ephemeral 'management' for not knowing exactly how an app should work up front.
In fact, it's usually overspecced in terms of technical architecture and woefully underspecced in terms of function.
It is more than that - it takes an incredible amount of time and effort to setup a good offshore team.
It took my current company over a decade to get to a point where we can consistently get ~10% lower project costs.
That’s a decade of failed and delayed projects! And we weren’t trying to go with the cheapest devs.
When your dev spend is a few hundred million or more a year this makes sense.
However, many many smaller companies have been burned. A couple of failed projects can sink these smaller companies.
Most companies know one can't hire the cheapest job applicant, they try (more or less successfully) to vet them, yet somehow outsourcing companies are exempt. One wonders how much these managers actually want the project to succeed.
At the same time, its interesting how broken this ecosystem is (despite the presence of several players vetting these 'companies').
My best suggestion: talk to Indian devs you know (and respect) and ask them for referrals of people back home.
What was the initial bid of the Indian company that ended up costing $6 million dollars?
Stories like these make my blood boil. And to be fair it's not just Indian companies. There are plenty of EU/US based dev teams that consistently fail to deliver and the company still keeps paying them.
I wonder if management just can't deal with sunken costs or if someone is trying to steal money from their own company by making under-the-table deals with the development team.
I've had a couple of clients that dealt with "cheap" teams and wasted years of their life trying to get a product up and running. Taking them on felt like rescuing abused puppies from a shelter. Their eyes would light up every time they witnessed a working feature, no matter how simple it was.
I am working with clients in the US, Europe and Australia. I know my limitations and never bid for work that me, or my team, can't deliver. This is why I have clients giving repeat work since last 7-8 years.
Many horror stories are caused by prematurely trying to go fast and making a bigger mess, not knowing how to design, specify, or oversee the building of software.
Overseas is as good as the garbage you can buy locally, but the problems get worse with the distance, time zone, and other things.
I am amazed that low cost outsourcing companies are able to fetch millions of dollars worth of contracts while actual competent developers have hard time landing them.
Part of it is because many colleges(and by extension, firms) in India are focused on knowledge of frameworks and languages as a key indicator of skill and quality. Many, but not all. Which essentially means that, developers are hired cos they know X framework or Y language. When clients ask for devs, how do they choose? Based on skills. Now, when quality is measured not by simplicity but complexity, everything will be over engineered.
Moving towards the business side I hired a lot of interns from commerce/marketing and they made my devs seem like little babies, it was shocking how capable, committed, team-oriented they were. It changed my view of things.
It's a matter of culture and perspective, and of course the fact that there is definitely such a thing as 'bad management' ... but Engs do have a tendency to think they know what's best for the product roadmap, and have really strong views about all sorts of things.
Some of this is good, in a way, but I really wish somehow the culture of development could be professionalized, both in terms of general approach to working at a company - but also in terms of the artisanal aspects of development itself.
It's important to set tone and expecations early, with smaller units it might work ... but as Eng teams get big, then they always end up reporting to Eng and not product, so it really depends on the culture that the VP Eng / CTO has established.
+ A general disregard for the talents and value of other groups. (Funniest example: 'ice cream day' at work and these devs cam to sit by us just as we were sitting down and a dev sneers: "Ugh, marketing". We just laughed.) Eng. talent is more classically academic, and yes, marketing is full of fluff, but good marketing, operations, finance is really hard. Basically an intellectual condescension that bleeds into a lot of things.
+ Failing to internalize that ultimately, they work for a business. Sometimes that means doing a lot of things an Eng would never do, like bolt-ons or weird add-ons to address specific customer needs. Cringing around metrics or optimizations that are ROI oriented and maybe not perfectly suited to their vision of what a 'good product' should be. This one can be a real problem in terms of attitude ... because they can get rally angry and stuffy. It's almost an existential debate over who really 'owns' the product in a sense - the business, or the people 'making it'? It really bothers me sometimes the cynical take that many Engineers have in this area - because the presumption is that 'they know better' or 'it's their thing' but really it's not at all. Basically, their view of 'raison d'etre' is often upside down. It depends on the organization.
+ Engs without management experience have a disrespect for how hard management actually is ... more so than in other groups. Marketing specialists are generally not like that.
+ Getting caught up in ideological wars about architecture, or 'bike shedding' - we're all guilty of this, but it's funny how ridiculous and perverse this is when you step outside of it. We're 'building something' not making some kind of 'functional art'. As techies we all love 'new toys' so this one is more understandable.
+ On the business side, if I ask staffers to get something figured out, to give me a quick analysis, to make some slides for the Veep, if they are good, they'll nail it down and move forward. On the dev side, if they even move to it, I get a lot of academic prose as though they don't know the language of business.
It's almost as though it's a little existential: so many on the business side play on 'sports teams' etc. are are very extroverted and team oriented, confident, and natural communicators. Often devs are not. So there's almost a natural cultural clash as well.
You don't have to strongly convince or persuade team players. They don't have tidbits of antagonism, or 'special needs'. They show up early, bang stuff out, realize that the world is somewhat political, that nothing is perfect, that we have to bend for customers, we do 'what needs to be done'.
Edit: hugely generalizing here. Everyone and every team is different.
Re-reading it I make it seems like devs are this terrible bunch! Not at all, most of this is subtle, it's nuanced, it's not like we have gross dereliction, just some different patterns of culture and behaviour.
How can the devs understand the business decisions and learn to make less academic slides if they are not exposed to the business?
I worked at a medium sized business where devs had lunch with sales/product/marketing and was treated as more than just coders. That has helped me a lot when it comes to the business side of work.
If you have problems with the developers in your company, it may be that the real problem is with the company culture.
Devs are unique in their peculiar aspect disdain for 'management and business'.
And unfortunately it's very rare that devs get such exposure but we agree it'd be great if they could.
I don't know what comes first.
But the places where engineers get on well with management are the ones where their opinions matter. Otherwise resentment comes in.
Granted technical folk are a special breed but being technical myself and having moved over to the business side of things, it's still equally important to think about motivation for devs.
To maintain engagement, I bring my technical guys with me to meetings where they can add value. And I always press about the value of meetings and what we're trying to get out of it.
Yeah, and this is exactly the kind of person that gets laid off first. You have to be a little bit of an asshole to survive. Have an "edge", even if it works against the company, so you are perceived as a "badass".
But I also think that there are some significant problems in what you've said.
You describe what looks like a siloed structure, where sales/marketing people are deciding on what to build, and then throwing it over the fence to the developers to just "get on with". Where are the fast iterations, looping frequently back to the customer, and involving the whole team in the process? Does a developer never have a good idea with regards to features? I think that if you want robots who do what exactly they're told, then you're going to end up with... a development staff of robots.
Meetings. Endless meetings. Agile, if done on a weekly cycle, gives you no fewer than seven mandatory meetings. I don't disagree that it's important to communicate, but the prevailing culture across the industry is absolutely towards superfluous meetings which involve too many people. And I think that's a big problem. Yes, developers need to understand that perhaps not all of a meeting will be relevant to them, but if they're not relevant to the meeting, then really they shouldn't be in it.
"Failing to internalize that ultimately, they work for a business." - I think that the above point on solied structures is relevant here, but I think that there is more also. It depends on the type of business, and I think that you're referring to B2B. But I have personally seen in the B2C case, with millions of users, the sales and marketing side - sometimes from different divisions - preference their own career objectives over the user's experience. "We sold this for a million dollars" "But there's spyware on the partner side sometimes" "Tough. Build the integration". So while I think that you're right when it comes to building a special-case for a particular customer who genuinely needs that special case, I think that there are also other cases here where it's not that simple.
A more minor point but when you say "as though they don't know the language of business", I think you're right, they don't know the language of business!
I find your sports team / jocks vs nerds analogy interesting, perhaps mostly to inform on your general perspective. Personally I would prefer a team of smart developers who care deeply about the product that they build, working hand-in-hand with the product team, designers, sales, and customer in short iterations where rather than deciding precisely what will be built up-front, the solution is instead found organically with valuable contributions from everyone.
But you're dead right on the 'new toys'. That practice is unforgivable.
Well, if they are not implicated in the business side of things, I don't see how they could be interested in. For example in my case, we're just getting feature requests for the next version, with no indication of business goals.
2. Hacking the servers after being fired and deleting the data
3. Insulting the guy from the marketing/sales/customer service department for lack of technical knowledge.
4. Asking the woman from the customer service department to be a cheerleader to up his motivation while he fixed the customer's problem.
If true, that is a pretty easy prosecutable criminal offense. Did you press charges?
That's as much a management issue as a developer one. There's no way the developer should have had sole power in the first place.
I mean, I get it. In a previous life I was "the IT guy" with absolute control over my domain. But I'd have hoped most organisations would have wised up nowadays.
May I ask what happened with this?
For many companies step one would be to contact the feds, and then the former employee would awaken to the sound of their door being kicked in pursuant to a search warrant for all of their personal devices.
Anything related to damaging computer systems via way of unauthorized (or even sometimes even authorized) access can easily become a federal crime.
The CFAA[0] comes to mind, see 18 U.S.C. § 1030(a)(5)(A).
Moreover, the feds are typically better equipped than local jurisdictions to handle computer-related crimes.
[0] https://www.law.cornell.edu/uscode/text/18/1030
Note: IANAL
P45's all round and the issue was solved, permanently.
Its slang because P45 has nothing directly to do with being fired. It is a tax document related to changing employment.
"Invented Here Syndrome" when it comes to the choice between writing 50 lines of code vs. pulling in 4mb of client side dependencies to use a giant 3rd party (yet Open Source and therefore Free!) library that incidentally offers a solution to the same problem, after about 50 lines of configuration.
vs.
"Not Invented Here Syndrome" for anything that involves paying money for anything. Such as that API that solves the exact problem that's blocking us from moving forward, offered by a company that does nothing but solve that problem for a living, because we might outgrow their Free Tier and therefore face potentially thousands of dollars of charges. Argued among half a dozen market-rate developers of a venture funded startup that could really do with having launched yesterday. Rather, let's pause to build our own version of that service first. Then build our product.
I tend to notice these things while working as a consultant, and thus something of a bystander in terms of being able to do anything about it.
After a few weeks Google caught that and banned our app. We lost thousands of customers and years of work and had to start over with a brand new app. Years later the infected app is still mining cryptocurrency because users ignore Google’s malware warning message and keep using the app.
PS: I should have said “our FORMER Android developer.”
My impression is that most of the time perceived bad experiences with developers comes from being a bad manager.
Source: developer
From the business side, here are examples I've seen:
- Have to use this technology, everything else is old, anachronistic, and unperformant
- System has to be scaled this way from the start (in startups, often, no it doesn't)
- Tension in how you trade off new features with clean code (there's a balance, and each environment requires a diff tradeoff)
- Building feature a certain way because it's easier for them, while ignoring what's appropriate for the customer/user
- Unwillingness or inability to explain technical topics to non-technical audience
- Making decisions solely on technical appropriateness, rather than broader appropriateness for the company (say, availability of other engineers to work on it)
There's lots on the managerial and business side too, but I'll save that for another thread.
P.S. A favorite quote of mine from Chinua Achebe (old proverb): Until the lions have their own historians, the history of the hunt will always glorify the hunter.
Any group we spend our time around will show itself in a good light. Even more so when we are a member of that group.
It's trivially easy to 'blame management'.
It's often the case, but it's often not either.
If, as I've sometimes seen, the dev asks for credentials, and a founder doesn't do it, or continually ignores the requests, but pushes for 'get it live', falling back to personal credentials (with reimbursement or using a company card) is a not-unusual fallback.
If, after it's done, requests for transfer to a 'company account' are not made, again, dev at fault. If requests are made, but not granted, owner's fault.
I've seen multiple scenarios happen, and they've gone in all directions.
Now I let them invite me to meetings when they think I'll add value, usually by talking through the product roadmap and business metrics.
When developers pushed back, they were called uncooperative, threatened with pay cuts or being fired, told they were not team players or were making too big a deal out of things. It was crazy!
In my experience, the times when management believe they are suffering from a problem developer are actually reflections of the management. There are exceptions like employee theft, issues with employees after they are terminated, and these things are often pretty black and white. But for all the other types of things that are more subjective about effort or cultural fit or finger pointing or tone or attitude or whatever, I tend to think most employees are absolutely not the problem, rather it is inept management and extremely poor culture mandates.
The part I do agree with is that responsibility to address the issues often is in management.
I do wonder if every tribe thinks they're good, and it's the other side at fault? ... I think about this a lot in my media literacy work, where I explore the empathy gap:
https://www.nemil.com/s/part2-terrorism.html
https://github.com/nemild/hack-the-media/blob/master/README....
I think as an abstract sociology problem, there is every reason to believe the dynamics of the situation make it far more likely to be problems with management or executives, and that it ought to require extraordinary evidence to overturn that prior point of view and instead believe it's sincerely an attitude / effort / tone / culture fit sort of problem on behalf of employees.
This isn't really special to companies where employees are developers. It's just a general property of the phenomenon of a corporation, period.
So, in all those cases, I believe, the only way is to say thank you and let go.
And i’m IC