35 ms·

In my experience, deadlines set by higher-ups long removed from (or never having) the technical chops to be determining the deadlines in the first place. VP's a

In my experience, deadlines set by higher-ups long removed from (or never having) the technical chops to be determining the deadlines in the first place. VP's and Directors are often the ones dictating the direction, which is great, but then also introducing deadlines, with helpful input from Directors who ALSO haven't touched code in many years. Generally that results in one of two things: * Product delivered on-time with massive technical debt. * Product delivered late with massive technical debt. Frankly I don't know if adding front-line engineers to the deadline decisions is going to make the issue better or worse, but fundamentally having non-technical or formerly-technical people defining deadlines definitely doesn't work.

3pt14159 8y ago
I'm a software developer, and I know this is a bit heretical to say, but I think sometimes we need to set goals that are overly ambitious so that we can work hard to meet them, even if we end up being late. I've been a contractor to a couple companies that didn't have real goals and there is this kinda easy going attitude that results in many things taking 4x as long as they could and often a lot more office politics as people spend more time jockeying for position than cranking out features or squashing bugs.
- eckza 8y ago
  I disagree. We need to set realistic goals so that we can work hard to meet them. The mindset you are describing is part of the reasons that we have these problems in the first place.
  - 3pt14159 8y ago
    I'm open to having my mind changed, but I've rarely been on projects that ended on time that ended as quickly as they could have.
- sh87 8y ago
  My experience, a ‘my goal’ gets quickly interpreted as ‘you committed to this’. ‘I can try’ projected as ‘You said you will get this done’. I’m all in for trying my level best and I have seen the rare slip ups penalized, criticized and highlighted to such a degree that it is just irrational for any dev to ‘try’ or be ‘ambitious’.
chii 8y ago
In the beginning was the Plan. And then came the Assumptions. And the Assumptions were without form. And darkness was upon the face of the Workers. And they spoke among themselves, saying, "It is a crock of shit, and it stinketh." And the workers went unto their Supervisors and said, "It is a pail of dung, and none may abide the odour thereof." And the Supervisors went unto their Managers, saying, "It is a container of excrement, and it is very strong, such that none may abide by it." And the Managers went unto their Directors, saying, "It is a vessel of fertiliser, and none may abide its strength." And the Directors spoke amongst themselves, saying one to another, "It contains that which aids plant growth, and it is very strong." And the Directors then went onto the Vice Presidents, saying unto them, "It promotes growth and is very powerful." And the Vice Presidents went unto the President, saying unto him, "This new plan will actively promote the growth and vigour of the company; with powerful effects." And the President looked upon the Plan, and saw that it was good. And the Plan became Policy. This is How Shit Happens.
- true_religion 8y ago
  Did you write this yourself? It's very good.
  - dayvough 8y ago
    A quick google sent me here: https://funnyshit.com.au/the_plan.html https://funnyshit.com.au/the_plan.html
  - chii 8y ago
    No, it's an age old poem that was passed around on the internet. I happen to have kept a copy of it, but the authorship has been lost i m afraid.
    - braythwayt 8y ago
      I believe this is a translation from the original Sumerian.
- deleted 8y ago
  [deleted]
equalarrow 8y ago
Even with technical higher-ups, you're not guaranteed a fair fight. I've worked with Engineering VP's/CTO's that are pressured by deadlines and promise unrealistic features. The key element needed in this is a 'leader' that can push back and manage expectations.
ttul 8y ago
Having worked in the trenches as a software engineer and also as a CEO has given me respect for the VP level as well as the engineers. When the VP sets a deadline, it’s driven by the survival of the company - aka release by June or we can’t make our numbers and have to do layoffs. When the engineers push back, they often do so without an appreciation of the business reality, aka those numbers pay their salaries. Engineers hate releasing poor quality products, but the reality is that customers often will buy and use something laden with defects rather than nothing at all. And in any case, after the initial botched release, you can always fix stuff. See Apple.
- luis_espinoza 8y ago
  I agree with you in part. However, engineers are more than capable to also take into account for planning the survival of the company if management provides the proper data to them. I think this is one of the problems, management usually hides information from the people they manage and without that data certainly plans can go in the wrong direction.
- jhall1468 8y ago
  That's a fine argument for a bootstrapped startup with one product, but isn't meaningful when talking about the tech titans that suffer from the exact same problems. This is the same type of argument that makes short-term profit take precedence over long-term success. Why in the world are we getting a deadline of 4 months? You, as an executive, had to know burn rate was blowing through cash a lot earlier than that. Engineers hate releasing poor quality products because we know we'll eventually have to fix them and we will likely be given almost no leeway time-wise to fix the actual debt, as time will always favor ugly hacks that "work" over well-written code that prevents the problem in the future.
  - dredmorbius 8y ago
    Maybe they're all teetering on the edge of viability?
  - ThrowawayR2 8y ago
    > the tech titans that suffer from the exact same problems The tech titans aren't monoliths with a collective hive-mind. Each business unit and team is responsible for projecting revenue targets and then hitting them, same as any other kind of business. And, yes, if the business unit managers fail to hit their financial goals too many times, their project will be cut and the team reassigned or laid off, same as a startup running out of financial runway.
hliyan 8y ago
Director who still writes code here. You're correct, but there is a vicious cycle here: when a project is delivered late, some managers respond (incorrectly) by artificially tightening the next deadline, hoping that when the team invariably slip, it'll at least get delivered by the original deadline. This never happens. The team does hasty planning and dives into implementation as soon as possible (to save time) and ends up delivering even later. What worked for us is what's basically mentioned in the article: taking a more structured, slightly painstaking approach to estimation. It's more tedious than gut feel story point estimation, but a lot less painful towards the end of the project.
gonzo41 8y ago
Software is up there as the most complex thing ever created. People have been putting up houses for thousands of years, And modern big bridges for hundreds. Big software is ~40-60 years old. Its hard to have rules of thumb and best practice that will deliver the 'on time outcome'. Give it another 100 years. Most dev work right now is still just attempting to deliver correct software. let alone on time or on budget.
- dredmorbius 8y ago
  The Linux kernel is several times more complex than the Space shuttle. Order of magnitude as I recall.
  - CamTin 8y ago
    Much harder to step the shuttle through a debugger though.
    - dredmorbius 8y ago
      Also, generally, much less need. The Shuttle is a physical system, and can be directly observed and components either individually (unit) or collectively (integration) tested. "Debuggers" are the monitoring, telemetry, sensing, and forensics equipment, data, and processes applied to each test, launch, and component. We have debuggers because code is otherwise a black box. Debuggers are a visualisation technology.
- markkanof 8y ago
  In addition, as requirements get more complex and users expect more polished products, we end up relying on more and more open source/reusable infrastructure and libraries. Those tools allow us to not reinvent the wheel and accomplish more in the same amount of time, but they also add to the complexity of any software system. House building has become somewhat more complicated over the years as building codes are made stricter and new techniques are developed, but for the most part it is just a switch to a new way of doing things vs. in the software world where we will continue to pile on more and more levels of abstraction, but can't reasonably expect to have at least some kind of understanding of the underlying layers.

3pt14159 8y ago

I'm a software developer, and I know this is a bit heretical to say, but I think sometimes we need to set goals that are overly ambitious so that we can work hard to meet them, even if we end up being late. I've been a contractor to a couple companies that didn't have real goals and there is this kinda easy going attitude that results in many things taking 4x as long as they could and often a lot more office politics as people spend more time jockeying for position than cranking out features or squashing bugs.

eckza 8y ago
I disagree. We need to set realistic goals so that we can work hard to meet them. The mindset you are describing is part of the reasons that we have these problems in the first place.
- 3pt14159 8y ago
  I'm open to having my mind changed, but I've rarely been on projects that ended on time that ended as quickly as they could have.
sh87 8y ago
My experience, a ‘my goal’ gets quickly interpreted as ‘you committed to this’. ‘I can try’ projected as ‘You said you will get this done’. I’m all in for trying my level best and I have seen the rare slip ups penalized, criticized and highlighted to such a degree that it is just irrational for any dev to ‘try’ or be ‘ambitious’.

chii 8y ago

In the beginning was the Plan. And then came the Assumptions. And the Assumptions were without form. And darkness was upon the face of the Workers. And they spoke among themselves, saying, "It is a crock of shit, and it stinketh." And the workers went unto their Supervisors and said, "It is a pail of dung, and none may abide the odour thereof." And the Supervisors went unto their Managers, saying, "It is a container of excrement, and it is very strong, such that none may abide by it." And the Managers went unto their Directors, saying, "It is a vessel of fertiliser, and none may abide its strength." And the Directors spoke amongst themselves, saying one to another, "It contains that which aids plant growth, and it is very strong." And the Directors then went onto the Vice Presidents, saying unto them, "It promotes growth and is very powerful." And the Vice Presidents went unto the President, saying unto him, "This new plan will actively promote the growth and vigour of the company; with powerful effects." And the President looked upon the Plan, and saw that it was good. And the Plan became Policy. This is How Shit Happens.

true_religion 8y ago
Did you write this yourself? It's very good.
- dayvough 8y ago
  A quick google sent me here: https://funnyshit.com.au/the_plan.html https://funnyshit.com.au/the_plan.html
- chii 8y ago
  No, it's an age old poem that was passed around on the internet. I happen to have kept a copy of it, but the authorship has been lost i m afraid.
  - braythwayt 8y ago
    I believe this is a translation from the original Sumerian.
deleted 8y ago
[deleted]

equalarrow 8y ago

Even with technical higher-ups, you're not guaranteed a fair fight. I've worked with Engineering VP's/CTO's that are pressured by deadlines and promise unrealistic features. The key element needed in this is a 'leader' that can push back and manage expectations.

ttul 8y ago

Having worked in the trenches as a software engineer and also as a CEO has given me respect for the VP level as well as the engineers. When the VP sets a deadline, it’s driven by the survival of the company - aka release by June or we can’t make our numbers and have to do layoffs. When the engineers push back, they often do so without an appreciation of the business reality, aka those numbers pay their salaries. Engineers hate releasing poor quality products, but the reality is that customers often will buy and use something laden with defects rather than nothing at all. And in any case, after the initial botched release, you can always fix stuff. See Apple.

luis_espinoza 8y ago
I agree with you in part. However, engineers are more than capable to also take into account for planning the survival of the company if management provides the proper data to them. I think this is one of the problems, management usually hides information from the people they manage and without that data certainly plans can go in the wrong direction.
jhall1468 8y ago
That's a fine argument for a bootstrapped startup with one product, but isn't meaningful when talking about the tech titans that suffer from the exact same problems. This is the same type of argument that makes short-term profit take precedence over long-term success. Why in the world are we getting a deadline of 4 months? You, as an executive, had to know burn rate was blowing through cash a lot earlier than that. Engineers hate releasing poor quality products because we know we'll eventually have to fix them and we will likely be given almost no leeway time-wise to fix the actual debt, as time will always favor ugly hacks that "work" over well-written code that prevents the problem in the future.
- dredmorbius 8y ago
  Maybe they're all teetering on the edge of viability?
- ThrowawayR2 8y ago
  > the tech titans that suffer from the exact same problems The tech titans aren't monoliths with a collective hive-mind. Each business unit and team is responsible for projecting revenue targets and then hitting them, same as any other kind of business. And, yes, if the business unit managers fail to hit their financial goals too many times, their project will be cut and the team reassigned or laid off, same as a startup running out of financial runway.

hliyan 8y ago

Director who still writes code here. You're correct, but there is a vicious cycle here: when a project is delivered late, some managers respond (incorrectly) by artificially tightening the next deadline, hoping that when the team invariably slip, it'll at least get delivered by the original deadline. This never happens. The team does hasty planning and dives into implementation as soon as possible (to save time) and ends up delivering even later. What worked for us is what's basically mentioned in the article: taking a more structured, slightly painstaking approach to estimation. It's more tedious than gut feel story point estimation, but a lot less painful towards the end of the project.

gonzo41 8y ago

Software is up there as the most complex thing ever created. People have been putting up houses for thousands of years, And modern big bridges for hundreds. Big software is ~40-60 years old. Its hard to have rules of thumb and best practice that will deliver the 'on time outcome'. Give it another 100 years. Most dev work right now is still just attempting to deliver correct software. let alone on time or on budget.

dredmorbius 8y ago
The Linux kernel is several times more complex than the Space shuttle. Order of magnitude as I recall.
- CamTin 8y ago
  Much harder to step the shuttle through a debugger though.
  - dredmorbius 8y ago
    Also, generally, much less need. The Shuttle is a physical system, and can be directly observed and components either individually (unit) or collectively (integration) tested. "Debuggers" are the monitoring, telemetry, sensing, and forensics equipment, data, and processes applied to each test, launch, and component. We have debuggers because code is otherwise a black box. Debuggers are a visualisation technology.
markkanof 8y ago
In addition, as requirements get more complex and users expect more polished products, we end up relying on more and more open source/reusable infrastructure and libraries. Those tools allow us to not reinvent the wheel and accomplish more in the same amount of time, but they also add to the complexity of any software system. House building has become somewhat more complicated over the years as building codes are made stricter and new techniques are developed, but for the most part it is just a switch to a new way of doing things vs. in the software world where we will continue to pile on more and more levels of abstraction, but can't reasonably expect to have at least some kind of understanding of the underlying layers.