13 ms·

The best programmers I know write good code within the constraints of a fast paced business environment and they are also able to clearly articulate trade offs

The best programmers I know write good code within the constraints of a fast paced business environment and they are also able to clearly articulate trade offs to stakeholders. They don’t complain about business constraints and they put out stellar work. “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”)

xaybey 7y ago
Honest question - is this a part of your hiring pitch? "Our engineers don't complain about business constraints" is a red flag if I ever heard one.
- Hackbraten 7y ago
  Depends. To > clearly articulate trade offs to stakeholders may be the constructive cousin of complaining.
- stiray 7y ago
  ... and is quite a funny statement. If "our" engineers dont "complain", then someone is not listening. Or you have really bad company culture / recruiting / engineering. The DUTY of engineer is to complain to bussiness decisions as they are quite frequent orthagonal to what does make sense to do and in which order. 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.
  - yibg 7y ago
    I think depends on what constitutes the “complaint”. If it’s just a bunch of griping with no suggestion for an alternative it’s not very constructive. Clearly engineers shouldn’t just build whatever they are told, but not caring enough about the business constraints is also bad. Like it or not at most places the software serves the business. Yes you want to engineer things so they are maintainable, performant etc, but if it doesn’t meet the business needs then none of that really matters. I’ve worked with engineers for example that outright refused to build things that are clearly needed by customers, for “technical reasons”. The result, good software that no one used.
    - stiray 7y ago
      On the other side, you have software that doesnt have promised features, is late etc. Bussiness side should always work with engineering side (which is more than not an exception) and the engineering side should never reveal what is possible to marketing (so they sell what they have instead of selling the... clouds... ehm... need better wording... vapors).
    - mschuster91 7y ago
      > Yes you want to engineer things so they are maintainable, performant etc, but if it doesn’t meet the business needs then none of that really matters. I’ve worked with engineers for example that outright refused to build things that are clearly needed by customers, for “technical reasons”. 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".
bcrosby95 7y ago
In my experience, simply doing the work without complaint is one of the most inefficient relationships with a programmer. Sometimes changing a minor business constraint can have an outsized impact on development costs. Oftentimes these decisions are even made by business people that think they are making things easier but are actually doing the exact opposite.
- amelius 7y ago
  Engineers always have to give time estimates for their work. This is their way of complaining.
- legulere 7y ago
  The problem here is that business people don’t understand the details of the business requirements or the model of it in the code.
  - onion2k 7y ago
    If someone doesn't understand something it's because it's either not been explained well enough or that person doesn't have the background necessary to understand it. Either they need more information or they shouldn't be making decisions about it. 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.
    - gen220 7y ago
      I’d put forward that there’s one more possibility: the person’s paycheck is contingent on them not understanding. 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.
harshalizee 7y ago
This sounds exactly like the kind of engineers I never want to work with. That's just a breeding grounds for yes men with zero interest in challenging the status quo. Nothing personal, but you are the type of director I would also not like to work with. Three management style described sounds like a walking, talking red flag.
Tade0 7y ago
I've worked with such people and on applications made by them. 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.
- acephal 7y ago
  This is exactly the situation I'm in at my job and I'm the only developer left from the MVP team, which was headed by a consultant whose scope was supposed to be smaller but convinced management, when they would not budge or listen at all to their in-house leads (I was a junior at the time) on the same issues, that they'd get results if they gave him the project (and a helluva paycheck). To his credit, he helped us put out a decent MVP, but he booked it when the company wouldn't give him an even more insane pay raise to stay on full-time and it turned out the MVP was not scalable and was designed for a different case than the one our company had and so suffered perf issues the moment things got serious. But management was okay with all this cause they got the MVP they wanted to show off to potential acquirers and-lo-behold the company got sold, that management disappeared, and I'm stuck behind walls of intervening actors from addressing fundamental issues in the design
  - Tade0 7y ago
    Interesting. I assume nobody figured that it's high time to rewrite the damn thing?
    - specialist 7y ago
      Every (successful) rewrite I've ever done was in secret. 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).
ichik 7y ago
> “business people” most often do understand what makes the money flow through their company My anecdata for the last 15+ years doesn't support this claim.
- coldcode 7y ago
  Mine goes back almost 4 decades, and understanding the business and tradeoffs is largely hit and miss with executives at all levels (also ran two startups in the days before the web). I've dealt with CEOs who understood everything and those who knew less than nothing; also seen engineers who understood nothing in business or development or both and those with a great deal of knowledge who could suggest changes and improvements that made sense to everyone. But I think the negative versions were far more common than the positive ones in every kind and size of company. 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.
cb504 7y ago
@ismejeff, sorry but you are (probably) a business person. - 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.
thdrdt 7y ago
I think what you mean is: the best programmers I know add value to the company. 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.
CaptArmchair 7y ago
> It’s not always vital to the business to have a good code base. 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.
thomk 7y ago
I would not call it 'complaining' to point out a business constraint, I would call it part of the job. 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.
alexandercrohde 7y ago
>> “business people” ... and they typically make decisions in order to maximize good business outcomes. 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.
deleted 7y ago
[deleted]
nwallin 7y ago
> write good code within the constraints of a fast paced business environment [...] It’s not always vital to the business to have a good code base. 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.
29athrowaway 7y ago
Not every business model is the same. When you only have short term goals, sustainability is doesn't make sense.
specialist 7y ago
I am just a fair programmer. 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 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.

xaybey 7y ago

Honest question - is this a part of your hiring pitch? "Our engineers don't complain about business constraints" is a red flag if I ever heard one.

Hackbraten 7y ago
Depends. To > clearly articulate trade offs to stakeholders may be the constructive cousin of complaining.
stiray 7y ago
... and is quite a funny statement. If "our" engineers dont "complain", then someone is not listening. Or you have really bad company culture / recruiting / engineering. The DUTY of engineer is to complain to bussiness decisions as they are quite frequent orthagonal to what does make sense to do and in which order. 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.
- yibg 7y ago
  I think depends on what constitutes the “complaint”. If it’s just a bunch of griping with no suggestion for an alternative it’s not very constructive. Clearly engineers shouldn’t just build whatever they are told, but not caring enough about the business constraints is also bad. Like it or not at most places the software serves the business. Yes you want to engineer things so they are maintainable, performant etc, but if it doesn’t meet the business needs then none of that really matters. I’ve worked with engineers for example that outright refused to build things that are clearly needed by customers, for “technical reasons”. The result, good software that no one used.
  - stiray 7y ago
    On the other side, you have software that doesnt have promised features, is late etc. Bussiness side should always work with engineering side (which is more than not an exception) and the engineering side should never reveal what is possible to marketing (so they sell what they have instead of selling the... clouds... ehm... need better wording... vapors).
  - mschuster91 7y ago
    > Yes you want to engineer things so they are maintainable, performant etc, but if it doesn’t meet the business needs then none of that really matters. I’ve worked with engineers for example that outright refused to build things that are clearly needed by customers, for “technical reasons”. 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".

bcrosby95 7y ago

In my experience, simply doing the work without complaint is one of the most inefficient relationships with a programmer. Sometimes changing a minor business constraint can have an outsized impact on development costs. Oftentimes these decisions are even made by business people that think they are making things easier but are actually doing the exact opposite.

amelius 7y ago
Engineers always have to give time estimates for their work. This is their way of complaining.
legulere 7y ago
The problem here is that business people don’t understand the details of the business requirements or the model of it in the code.
- onion2k 7y ago
  If someone doesn't understand something it's because it's either not been explained well enough or that person doesn't have the background necessary to understand it. Either they need more information or they shouldn't be making decisions about it. 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.
  - gen220 7y ago
    I’d put forward that there’s one more possibility: the person’s paycheck is contingent on them not understanding. 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.

harshalizee 7y ago

This sounds exactly like the kind of engineers I never want to work with. That's just a breeding grounds for yes men with zero interest in challenging the status quo. Nothing personal, but you are the type of director I would also not like to work with. Three management style described sounds like a walking, talking red flag.

Tade0 7y ago

I've worked with such people and on applications made by them. 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.

acephal 7y ago
This is exactly the situation I'm in at my job and I'm the only developer left from the MVP team, which was headed by a consultant whose scope was supposed to be smaller but convinced management, when they would not budge or listen at all to their in-house leads (I was a junior at the time) on the same issues, that they'd get results if they gave him the project (and a helluva paycheck). To his credit, he helped us put out a decent MVP, but he booked it when the company wouldn't give him an even more insane pay raise to stay on full-time and it turned out the MVP was not scalable and was designed for a different case than the one our company had and so suffered perf issues the moment things got serious. But management was okay with all this cause they got the MVP they wanted to show off to potential acquirers and-lo-behold the company got sold, that management disappeared, and I'm stuck behind walls of intervening actors from addressing fundamental issues in the design
- Tade0 7y ago
  Interesting. I assume nobody figured that it's high time to rewrite the damn thing?
  - specialist 7y ago
    Every (successful) rewrite I've ever done was in secret. 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).

ichik 7y ago

> “business people” most often do understand what makes the money flow through their company My anecdata for the last 15+ years doesn't support this claim.

coldcode 7y ago
Mine goes back almost 4 decades, and understanding the business and tradeoffs is largely hit and miss with executives at all levels (also ran two startups in the days before the web). I've dealt with CEOs who understood everything and those who knew less than nothing; also seen engineers who understood nothing in business or development or both and those with a great deal of knowledge who could suggest changes and improvements that made sense to everyone. But I think the negative versions were far more common than the positive ones in every kind and size of company. 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.

cb504 7y ago

@ismejeff, sorry but you are (probably) a business person. - 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.

thdrdt 7y ago

I think what you mean is: the best programmers I know add value to the company. 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.

CaptArmchair 7y ago

> It’s not always vital to the business to have a good code base. 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.

thomk 7y ago

I would not call it 'complaining' to point out a business constraint, I would call it part of the job. 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.

alexandercrohde 7y ago

>> “business people” ... and they typically make decisions in order to maximize good business outcomes. 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.

deleted 7y ago

[deleted]

nwallin 7y ago

> write good code within the constraints of a fast paced business environment [...] It’s not always vital to the business to have a good code base. 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.

29athrowaway 7y ago

Not every business model is the same. When you only have short term goals, sustainability is doesn't make sense.

specialist 7y ago

I am just a fair programmer. 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 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.