zlacker

>>vimes6+(OP)
Which is more likely: Businesses invent truly arbitrary deadlines for the hell of it, or the “engineers” don’t want to pay attention to business requirements and competitive pressures?

When so-called engineers stop spending half the development schedule choosing a framework and the other half trying to make their dev setup work on everyone’s personalized laptop they will have some credibility complaining about “arbitrary” business goals and requirements.

>>gregjo+N8
From anecdotal evidence, a) is more likely than b). The deadlines are arbitrary because most companies are slow bureaucratic oil tankers that are difficult to steer and will mow down everything in their path once a course is set. Management's job should to be to work on this, to improve the system as a whole and making it more nimble, not on myopic deadlines that fulfil some checkbox and are tied to your EOY bonus. This is outlined by people like Deming and others in the systems thinking space.

From experience, in their career, engineers not only need to excel technically, but are also forced to pick up everything from UX, methodological BS (from Scrum to Itil) to domain specific know-how in multiple fields or areas. Since many managers do not know what they're doing, senior engineers often times end up being de facto management consultants as well. If you are working in a business environment (as opposed to writing low-level drivers or whatever) it's almost impossible to not pick up on what's going on around you.

How many banking managers know how to code? How many engineers working in banking know at least something about the processes, compliance issues, how the org is structured, what the competitors are?

The stereotype of the autistic programmer who is only interested in shiny gadgets and tech needs to die.

>>kitsun+Rb
I agree, except the programmer (autistic or not) who wants to be left alone to code and play with shiny things is not just a stereotype. Just read through HN any day to see posts about ignoring meetings, marketing, management, business priorities and focusing excessively on languages, tools, the “best” ways to do things, dismissing non-programmers as hopelessly useless (“many managers do not know what they’re doing.”)

As a freelancer I have to get to know the business my customers are in, I can’t just focus on purely technical things most of the time. Many times I have described my work to other programmers and heard how they want to be left alone to code. I take over legacy software and failed projects for a living. The two main reasons in my experience for software dev project failure are (a) developers did not bother to gather and understand requirements but rushed to start coding, and (b) poor communication with the customer and stakeholders. Those faults may come from arrogance or inexperience, or both.

>>gregjo+Wc
> (a) developers did not bother to gather and understand requirements but rushed to start coding

Because of arbitrary and too short deadlines

> (b) poor communication with the customer and stakeholders

Communication is a two way street. Why blame devs for all this?

In my opinion, when a project fails, you have to blame the people higher up in the management chain who are coordinating the work, rather than the engineers. (in a large company)

If engineers are to blame, maybe look at your hiring standards and hire better engineers. This points back to the management again.

> Those faults may come from arrogance or inexperience, or both.

Don't hire arrogant or inexperienced engineers then?

>>Financ+kg
Management may be at fault, but anecdotally I see programmers rushing to code very often. Almost every one of my customers has the same story: the last developers stopped answering emails and calls when the project ran into problems.

I have worked with terrible managers an dysfunctional organizations, but I have seen developers rush to code and stop communicating far more frequently.

I don’t really care about blame. These are people problems with no single solution. When I get involved in a failed project the customer has moved past blame and just wants to salvage something to meet their requirements. The programmers will blame management with little introspection about their own role in the failure.