There is a difference between complaining, voicing opposition and articulating trade-offs less technical people may not be familiar with.
Eventually customer got tired of having to defend how many statuses he wanted in combobox or what process their company want to use.
By that I want to say, there is definitely such a thing as programmer not willing to consider business point of view for a second and thus being impossible to work with.
It is vital to understand business needs. A lot of times businesses want changes that are hard, and very hard to implement. It is our responsibility to work with the customer to come up with a solution. The customer must accept the consequences that come with their requested change.
Unfortunately, some things are impossible to do. It is never good to be the bearer of bad news - I have myself told that we cannot do it this way, but I have always given a thorough explanation of why it is impossible and suggested workarounds and alternatives. I think sometimes this behavior can be the difference between the perception of being impossible to work with and helpful.
Truth is, it takes a lot of effort to balance your work against the ever-changing set of requirements coming from your stakeholders.
By questioning in don't mean having honest questions nor trying to understand, but being convinced that there must be mistake and forcing customer to defend every tiny choice.
And sometimes the customer wants radiobox instead of combobox are just wants to have it without having to spend 20min on meting to defend the choice.
For example, password requirements. Many companies are not aware of the latest best practices and guidelines and request that we block browsers from generating or remembering passwords in password fields. Or they give us a list of draconian password requirements that are clearly debunked by the latest guidelines.
Or they ask us to basically break the HTML spec.
Like I tell my four year old son, I'd love to get a million dollars but I'm not going to get it because I stamp my feet and demand it.
Trade-offs need to be made on both sides. I agree that an engineer that doesn't provide alternatives when a customer demand is not technically feasible should be corrected. However the customer should be prepared to choose from those alternatives or change their demands as well. The first step to success is shipping and the most common reason for software projects shipping late is a failure to start. I'm not against firing bad customers.
It's much easier to ship without a contentious feature and figure out how to add it later than to delay shipping (for certain features within reason, of course -- please don't ship half-baked security libraries or aviation control software).
I was specifically talking about situation where requirements are possible and not ambiguos. And where engineers starts "knowing" customer is wrong and keep knowing it despite it regularly turns out it was enginers lack of domain knowledge.
There is no trade off between these two situations.
I don't know what you mean by breaking html spec. Browsers keep it and we work either with it or around it?
re: HTML -- I've had strange requirements come in that required us to work around the HTML spec in order to get the UI to work they way they wanted. We eventually found a better solution...
but the point was that not all requirements are golden; sometimes the customer is plain wrong, ignorant, and stubborn.
If the problem is that the issue hasn't been explained well enough then the developers need to work harder to better explain what the problems are and why they're problems.
If the problem is that the business person doesn't have the necessary background to understand the issue then you have a huge problem. That person is going to be a problem at every step. I don't envy anyone in that situation. In the past 25 years of development I've never actually encountered that situation though.
Unfortunately, some business people are compensated as direct function of revenue (growth), even though they have to pull engineering levers to obtain that delta in revenue.
For a lot of these people, once they’re convinced that doing X will lead to growth, no explanation will convince them that it isn’t worth it.
Make sockets as first priority and then write tcp stack as "unneeded"/postponed is quite frequent from a bussiness standpoint. Not complaining about situations like this is just hurting the bussiness.
The core problem is that too often business needs are dogmatic and management is too entrenched to fix it.
This is the reason why so many large-scale IT/digitalization projects end up colossal clusterfucks: no one on customer side has the spine to say "our processes and workflows were made in an age where people did things by hand, let us modernize them while we're already at it".
> clearly articulate trade offs to stakeholders
may be the constructive cousin of complaining.
You're on the edge of contradicting yourself.
If the business environment is fast paced, ie your development process for ingesting features and specifying behavior is ad hoc, ("we are agile/do scrum, except we service requests from customers immediately as they come in instead of waiting until the next sprint") it's absolutely vital to the business to have a good code base.
Being able to make rapid changes without breaking everything requires a good code base. If your code base is full of landmines, you necessarily cannot send an average coder out to implement some average feature, because they'll necessarily have to (re-)teach themselves about half the idiosyncrasies of the codebase before they can do anything.
It's fine to have a shitty code base if your business environment moves stodgingly. ("You want a new form in the UI? OK great! We need a scope of work, a formal specification, we will charge you by the hour, you will need to pay us to recertify the entire product. Let's set up a meeting with contracting and legal next quarter to iron out the details.")
In my experience, the people who implement features quickly in a shitty codebases do so by breaking stuff in non obvious ways. This includes myself. This is fine for my organization because we only ship once every six months, and we only ship anything after two months of exhaustive manual testing. If the organization just decided, "we're a fast paced organization now, now we ship every two weeks" we'd lose all our customers fairly quickly as a result of the precipitous decline of the quality of our product.
I suppose fast paced business environment+shitty codebase is also ok if the goal is just to sell the company as soon as possible. But that's a personal objective, (and a selfish one) not a business objective.
All that is usually done at the expense of others - be it teammates or future maintainers.
It works great for MVPs and such, but falls flat on its face when you have to add new features to a three year old application, whose original creator moved on a while ago.
I once spent 6 months fixing someone else's MVP. Every bug fix exposed 2 more. I begged for a do over. Nope, we've invested too much money to abandon.
Once I understand the problem well enough, I banged out a full rewrite in two weeks. I had just one bug before release (one of the trig equations had the wrong sign, facepalm slap).
You had me until this statement. It's been my observation that "business people" are usually self-interested manipulators who hire people they don't need if it makes them look important, game/trick OKRs, hide all failures from their superiors (and would fire you if you went behind their back), often damage brand trust/equity to try to get good metrics for a quarter (e.g. google), willingly let massive problems (e.g. security holes a la equifax) fall on the floor rather than risk being associated with problem by helping.
Not all, but more than half.
To make it easier there really are only 2 business constraints: Time and Money. Everything can roll up to one or both of those.
I'd also like to note that asking an engineer to estimate a project, is work. That work (creating the estimate) takes both time and money. The more time and money engineers spend on creating an estimate, the more accurate (and valuable) it will be.
Here. This is an estimate for almost every business software project: Between $0 and $100MM. That took me no time and as a result, has no value.
The other end of that spectrum is an estimate with perfect accuracy and full value. Meaning -- we know, to the penny, what it is going to cost. An estimate like that is going to be EXPENSIVE and might even eclipse the cost of the entire software project.
Knowing that creating estimates take time and money, the question inevitably becomes "Well how much will it take to create the estimate?"
The answer comes down to: How much do you want to invest in it? Or better put: How important is estimate accuracy to you?
Business people decide the value of things, rely on that. "What is the dollar value of this to the business?" is a legitimate question to ask to a business person. If it's worth $1, then use my estimate above. If it's worth $1MM then the next question is: What percentage of that inevitable end value is it worth to spend on the estimate?
Most of the time the number that comes back is not derived from some magical corporate formula, it's gut feel. Which by the way is essentially arbitrary, which I wouldn't call useless. But let's call it what it is, it's a number that is palatable to the business to lose.
So, given that number, we now know how much time to spend. Your accuracy will directly reflect that amount. If we want to be more accurate, we'll have to spend more money.
Business people are responsible for the money and engineers can not manufacture more time.
Rely on both of those.
As a freelance programmer I had to learn this. Companies don't give anything about the language, the VCS, the LOC, spaces or tabs, or anything unrelated to them.
You just add value to the company by creating great software they can use. This also means software that can be maintained and updated.
Some people in this thread complain about the "They don’t complain about business constraints". But when you start complaining about their business constraints, how can you add value to their business? You can only add value when you think about how you can create something that works best for them to keep those constraints. And ofcourse this includes discussing constraints when you are sure you have a great idea to make them better, but most of the time other people thought better and harder about those constraints than you did.
Edit: maybe it is unclear what you mean by "business constraints". In my mind you are talking about the company business, but others might thing about programming business logic.
My anecdata for the last 15+ years doesn't support this claim.
Sometimes dumb people can still be lucky and make money (one place was dumb all around but their business was a unassailable monopoly, and another had 40 years of dumb customers who agreed to terrible annuities so failure would take decades to happen no matter what was done) and sometimes bad decisions or understanding in business or tech lead directly to failure.
There is no single type of success or failure in either business or tech.
But I create great insights. Whole new ways to see a problem. Making the intractable and complex simple and obvious with a novel mental model.
For instance, I replaced a high end CAD/Illustrator style print production workflow with a simple form. Answer some questions and out pops a production plan.
It took me 4 years to earn that insight. The entire industry modeled the flow information exactly backwards (https://en.wikipedia.org/wiki/Job_Definition_Format). It took me forever to overcome my initial misunderstand of the problem -- I mean really, how conceited am I to think everyone else is wrong and no one else thought of this before me -- and see the problem like the production workers do. I had to bridge the domains of print production and software design.
Alas, it's been a while since I've had a gig which could afford that kind of investment. My last gig, recommenders for fashion, which turned out to be a complete hoax, devs were slaves to JIRA, "just do 80%" and move on, throw everything away every 2 years, unless it's "legacy", in which case just suffer with it.
I wonder if there's much room left for dinosaurs like me.
Many engineers may cringe at this... but this is true. Code is only as good as it is able to fulfill a business need: that is help the organization meet its strategic goals.
Technical constraints - maintainability, security, performance,... - are really subservient to that principle.
That is, they aren't unimportant. Rather, their importance is relevant - or a priority - in so far that they help achieve the higher goals.
... but this isn't a universal maxim!
> Also, for better or worse, if an engineer is not of the variety I listed above, they are replaceable in the eyes of the business.
An employer/employee relationship is very much a business deal between humans. An employee sells expertise and potential for a fixed amount of time in exchange for a fixed salary. As with any deal, such business relationships extend beyond simple monetary compensation. Especially because employees subjugate themselves to the authority of their employer, making it inherently a skewed relationship.
When humans invest their time and effort in a venture, they hope to get a due sense of satisfaction and self-actualization from doing so. That's where aligning values makes all the difference.
What many business people fail to see is that employees don't identify themselves as resources, liabilities or labor. They see themselves as partners who hope to make a meaningful contribution, and they are willing to do so provided that they are treated as such: with a due sense of empathy and respect for their opinions, what motivates them to come to work each day; and so on.
If they don't get that, two things might happen. Either employees will walk out rather quickly, or - worst - they stay and will only give you the bare minimum of their efforts - living for the weekends - wasting both their own and your time.
It's true that companies aren't obligated to keep employees forever or that they can be let go if both parties want different things ...
... but publicly stating that any employer/employee relationship is "replaceable" without that nuance, is the shortest route towards foundering any hopes to attract potential hires who care about your business at all.
> They don’t complain about business constraints and they put out stellar work.
Given the above, humans will also factor in the moral and ethical side of what they are doing. And they can, will and should criticize those business constraints if those don't align with what they feel is "good" or "morally sound".
Business constraints aren't just limited to implementing some weird feature. That's just the output of a business constraint. Neither are styling rules or automated tests business constraints. Nope. it's far more then that. It's workplace culture as a whole. It's the shared values that are espoused on a day-to-day basis by everyone.
It's normal to have some level of conflict or tension as the net result is an ever-moving compromise.
Expecting that employees will never complain and only put out stellar work pretty much makes any healthy discussion moot. It's a non-argument as "stellar" is only meaningful in the eye of the beholder. All it does is create the perception that employees are seen as automatons.
Again, when employees pick up on this; they will either walk out or - worst - stick around and waste yours and their own time only doing the bare minimum to cash a paycheck.
In the short run, the bottom line of a company may reflect the financial benefits of optimizing for efficiency. But in the long run; not taking the human factor into account isn't sustainable at all. Neither for the employees, nor the business owners.
> Given the above, humans will also factor in the moral and ethical side of what they are doing. And they can, will and should criticize those business constraints if those don't align with what they feel is "good" or "morally sound".
My thought after reading the article was that the author seemed to consider writing good code, maintainable code, and having a strategy prioritizing long term over short term needs as moral imperatives. Or at least the words and terms used were ones I often hear and use when discussing ethics and morals.
Which made me think, do many engineers consider these things as ethical decisions, rather than just business choices?
Personally I enjoy being involved in strategic decisions, both providing input and opinion - but I also see the value in adhering to a strategy once decided even if it isn’t the one I’d advocate for if it was up for discussion. For ethical decisions I’d reason differently - it’s not ok to break laws or destroy lives (etc etc) just because a business decision said so.
I don't think the article's author said this. In my eyes he meant it more like "at least give us SOME breathing room to do our best engineering work!" -- meaning give some time for refactors, for changing tooling, for stepping back for 1-2 months and just looking at the whole thing in general.
Creativity needs time for pondering and reflection. Chasing ruthless and practically impossible deadlines while having to systemically ignore everything that made you a good engineer in the first place makes for a toxic employee<->employer relationship. And one that rarely ends well.
When you only have short term goals, sustainability is doesn't make sense.
- is an IDE open on your desktop right now?
- how many commits have you done this year?
Talking about code and software isn't anywhere near the same as being a programmer. If I am wrong about you, I apologize; you are the exception.
“business people” most often do understand what makes the money flow through their company (and into engineers’ bank accounts) and they typically make decisions in order to maximize good business outcomes. Sure they don’t understand the technical details of an engineer’s work, but the engineers are far from understanding all of the things that must fall into place besides lines of code in order for their paycheck to clear. It’s not always vital to the business to have a good code base. Also, for better or worse, if an engineer is not of the variety I listed above, they are replaceable in the eyes of the business.
(fwiw I’m a director-level engineer so I’m technical but bordering on being a “business person”)