38 ms·

Is management pressuring you to deliver unfinished code? (2020)

151 points by jasonbourne1901 5y ago

deleted 5y ago
[deleted]
rcarmo 5y ago
This reads a lot like a lean/MVP manifesto. I would say that there is always a pressure to deliver working code, but that “unfinished” should always be in terms of project scope and not in terms of either functionality or reliability. “Code” is the wrong terminology here. It’s OK to not have every feature implemented. But it’s not OK to ship half-baked, untested functionality, no matter what the “code” looks like.
- yakshaving_jgt 5y ago
  Conversely, half-assed is ok if you only need half an ass.
- commandlinefan 5y ago
  > This reads a lot like a lean/MVP manifesto It also reads like the Agile manifesto from 20 years ago, which caused a huge splash when it was first published - before it was misinterpreted by everybody who might have been able to actually apply it to obtain results as "do exactly what you've always been doing (especially in terms of fixing a delivery date long before you describe what the software is supposed to do), but use terminology like 'sprints' and 'standups' to do it".
Guthur 5y ago
One of the problems I have found is that we don't talk the same language when communicating with the business, we use terms like "Technical Debt", "Test Coverage", even "Minimal Viable Product". In my opinion the universal variable across all these is risk, and it's easy for all to grasp what we mean when we say the word "Risk". There is delivery risk, will be get this out in a timely fashion for the market. There is operational risk, will this fall over if we get 10x users or if someone looks at it funny. There is market fit risk, are we building the right thing for the customer. Framing these conversation with the business as functions of risk analysis and management is a fundamental part of leadership in my opinion.
- makeitdouble 5y ago
  I am not versed enough in car things, but it seems to me this would be something maintenance shops nailed down decades ago. How would they convey that your car is lacking maintenance even if you can still drive it to work ? Perhaps we should go with "needs repair" or something like that ? "Risk" feels like insurance territory (which goes along with "there is always some risk"), and a lot of people beautify the notion of taking risks to get higher gains.
  - giansegato 5y ago
    Risk-taking is very cultural dependent, in some contexts people would avoid taking risks as their default option. That said, I feel that car shops just work because, well, it's the law, especially in some countries. In the end "needs repair" is the same as saying "mitigating accident risk".
  - Cthulhu_ 5y ago
    The risk for a shoddy car is that you end up killing someone or get written up and charged with a violation. The risk for shoddy software (in most cases) is that you have an outage and suffer some financial or reputation damage, but that won't put you out of business. There's laws against bad cars, there's no laws against bad software.
    - squiggleblaz 5y ago
      > There's laws against bad cars, there's no laws against bad software. There's often privacy/data protection obligations, but they seem to be impossibly difficult to get the courts to pay attention to. If the average business owner would find themselves in legal shit every time an external party got access to their data (i.e. just being the victim of a ransomware attack puts you at risk of losing your home), they would probably pay more attention.
  - OJFord 5y ago
    And then we can scathingly label the most hated parts 'beyond economical repair'!
jahnu 5y ago
> Unfinished code that is full of race conditions, performance problems, outright bugs and worst of all, poor to non-existent product/market fit. The last one is so different than the rest. Bugs shouldn't even "ship" internally in that they shouldn't really be making it out of feature branches often for some reasonable value of often. But back to the last one, that's something that should be decided with high confidence before the first line of code is written!
- tonyedgecombe 5y ago
  The last one is the hardest to get right in my experience. Sometimes you just won’t know until you start asking people to put their hand in their pocket.
  - Cthulhu_ 5y ago
    I mean there's been a few successful companies like Slack that started off with something completely different before they pivoted. Sometimes market fit takes some experimentation.
brainwipe 5y ago
This article raises some great points but is still trying to close the stable door after the horse has bolted. If your business is agile, it begins with the style of engagement between you and the customer. Really agile businesses don't deal with absolutes (such as fixed price contracts), instead they accept change at the core. Accounting hate that, so most businesses aren't agile.
phkahler 5y ago
Deliver something the customer wants, make the product better, or figure out why those 2 things are not the priorities. It's usually money or politics.
eric4smith 5y ago
My dad who was a quite successful artist back in the day said something I’ll never forget. “Son, I’d like to work on that painting forever, because for me it’s never finished. But I have to stop and sell it because I have to feed the 3 of you children”. His sole source of income was his art, and we grew up not wanting anything, because he was pragmatic enough to understand at some point he had to ship his art to survive - even if to him, it was not completed. That’s why when I heard Steve Jobs say “real artists ship”… I immediately understood at a visceral level what he meant. And iPhones over the years have had countless bugs.
- djmips 5y ago
  Hmmm, everything has bugs. The iPhone shipped as a great product that customers loved. The point of the article is to release something great that the customers will love. Internally, yes, ship something early and iterate on feedback.
- barbazoo 5y ago
  That's a great lesson your dad taught you there. I wish I had been taught that early on in my career because it applies just as well to an organization.
nlitened 5y ago
> Engineers are problem solvers, and a manager who applies pressure becomes the problem the engineers decide they need to solve. If it is really important to deliver Something™ by the date, engineers will, if enough pressure is applied, deliver unfinished code by that date. Unfinished code that is full of race conditions, performance problems, outright bugs This is wrong. You can and should deliver "by the date", but you should also prioritize ruthlessly, and ship at least the top of most-important-features list with reasonable quality when time runs out. Of course, this implies that both managers and engineers have to understand deeply, what value each feature brings, and communicate among themselves and with their client continuously.
titzer 5y ago
> The top two sources of failure in software development projects are failing to discover what is actually needed and failure to eliminate chaos in the software before delivering it to the customer. The first one is called requirements gathering (the method, requirements engineering). I was wondering how far I was going to have to read to find someone mentioning that. It can be as simple as writing down a list of things the software has to do. It could be one afternoon brainstorming meeting, to start. But we don't even bother. Why? Because this discipline is not engineering, not science, not manufacturing. One my darker days, I think we are just playing in the mud. I am grateful to work on virtual machines and compilers. They at least have functional requirements--an input specification--and a well-specified target machine. The rest in the middle is a fun design exercise, but there is a crucible at the end of the day. If you can't run the programs without bugs, you have failed. That makes it easy to put functional correctness first and performance second, as it should be. We need to find more ways of translating problems into requirements in order to reduce black art to science to practice.
- blacktriangle 5y ago
  I agree it's a bit like playing in the mud, but the more I work the more I suspect that's just accepting reality. Requirements gathering works wonderfully for internal projects with a fixed set of stakeholders and a well defined problem with measurable outcomes. Product development is a whole different world whose outcome is the much more vague "generate profit for the developers". Particularly in the realm of B2B software. You need to find some local minimum that will meet the needs of thousands of organizations in order for development to be worthwhile. You need to get many busy people who don't know you to actually talk to you. You need to talk to multiple different stakeholders within the organization. And even after you group all your stakeholders into some kind of user personas, you still haven't accounted for what the larger organizational behavior will be, as B2B products generally require large-scale buy-in. And at the end of the day, no matter what people say they will do, the true test is when a company actually opens their coffers and pays your invoice. We've arrived down here in the mud through years of experience of doing requirements gathering, building to a spec, and then finding out that we built the wrong thing and nobody will pay us for all our hard work. Sometimes you really do have to build it to see if they will come. And the more formalized (ie expensive) you make the requirements engineering process, the more compelling the iterate and start getting paying customers asap plan becomes.
commandlinefan 5y ago
As Dilbert says: "Our boss can't judge the quality of our work, but he knows when it's late".
- barbazoo 5y ago
  And just like Scott Adams is so wrong about many things he says, Dilbert is wrong here or at least short sighted too. While you notice immediately that something is on time, you'll also notice really quickly that something is of bad quality, unreliable, inconsistent, low performant, etc which translates in whoever the customer is to be very unhappy very quickly. There needs to be a well-informed balance. I know you were just posting a funny Dilbert quote but I don't respect Scott Adams anymore so I was triggered, please accept my apologies.
  - vegetablepotpie 5y ago
    I can see that you have not been exposed to the magic of bureaucratic indifference. If you release a really shitty product, and your customer doesn’t have choice (has no competitor, made a large upfront payment, has fallen into vendor lock-in, etc), you don’t have to respond. You can translate an unhappy customer into a compliant one by putting up barriers to the reporting and documentation of the issue. Make automated resolutions that don’t quite fit the situation, put the issue into a ticketing system that never addresses the issue, give employees roles that either overlap with each other or don’t intersect at all over the customers issue, etc. These are the situations that Scott Adams parodies with Dilbert.
  - lnanek2 5y ago
    > While you notice immediately that something is on time, you'll also notice really quickly that something is of bad quality, unreliable, inconsistent, low performant, etc Not in my experience. Our team has a couple core perf metrics that are alarmed, like page load and missed frames, but it's easy to do really bad things that won't trigger the alarms. Or do them such that the automated tests are using different content for the pages they test than the real users who will see the commits weeks later. E.g. someone commits a change to feature x that locks up the screen, but the test user pool never uses feature X, or never puts content into it and just sees the empty state screen. Quite common for developers here to write stuff that works for 99% of users, but falls over otherwise as well. Like today I fixed an issue where tapping a button on one screen to go to another really fast, like under 1 second, crashes because of a race condition. Testers aren't going to notice that. It just shows up in the company's overall crash rate which is spread across 4000 developers. Automatic UI tests caught it, but the responsible team had just filed the crash stack trace JIRA into their backlog and left it to sit for months. Similarly, today, we had a production issue because someone wrote some code that only works for certain users who had already accepted a certain terms of service screen. Shipping a feature is rewarded heavily. Not screwing up the app for edge cases and perf and people who have to implement the next feature after you? Good test coverage? Not at all. If you dare to give an estimate that includes full test coverage, PMs will just take you off the project and pick a developer who doesn't do that.
javier10e6 5y ago
Not to be thrown into semantics but... Scope vs. Goal The goal defines the scope. If the goal does not change, neither the scope. When the goal includes a date...the scope has no way to adjust because scope refers, simply put, to a to-do list. A poorly conceived date does not change the scope, it cuts short the to-do list. How long does it take to a Nascar Team to win the Indy 500? 500 miles as fast as humanly possible.
Havoc 5y ago
Half finished work they would never do su
nine_zeros 5y ago
A rational manager would scope projects with their technical leaders AND senior engineers who will ultimately execute. This scoping must happen before selling the project and also constantly throughout the lifecycle of the project. Then, the rational manager would also manage expectations with other stakeholders, not committing to things they cannot see the end to. But most managers are not rational and do the complete opposite. They want to "appear" amazing managers to other stakeholders while simultaneously bringing their "ego" in discussions with team leads and senior engineers. Nobody is happy with such managers. I think a better org structure would be managers reporting to senior engineers instead of senior engineers reporting to managers. Senior engineers are responsible for the implementation. Managers merely act as assistants delivering messages everywhere.
keynesyoudigit 5y ago
As a Dev this looks like such a wonderful approach to me, but how do you get the customer on board with this? How do you get a nervous customer that doesn't trust you yet to enthusiastically work with you figure out what they want?
H8crilA 5y ago
Here's a question: why do you, as an engineer, care? You're just an employee, it is the upper management's role to make sure your company moves forward, maintains the trust of clients, has reliable enough solutions. If they decide to sacrifice quality for speed that's their problem/decision. Really. You were hired to provide technical solutions within specs, and if specs require fast completion more than quality then that's probably what you should deliver. Then watch it blow up, or maybe it will actually be good enough.
- haolez 5y ago
  True, but the "be good enough" will probably be updated on what "good enough" is after you deliver your first impossible project. It'll eventually catch up, but that's just how bad executives and bad companies manage.
- dkdk8283 5y ago
  You care if you work in security, and ops but perhaps to a lesser extent.
- 3pt14159 5y ago
  I'm honest about delivery dates, but I do deeply care about getting a project across the line on time. Not just because it gets me cooler, more demanding projects with larger compensation, also for its own sake. It's fun to win, especially when the timeline isn't arbitrary and you can pull it off.
- astockwell 5y ago
  This _should_ be true, but isn't always, if you're at a company (or just have a manager) who will let the mess/blame fall onto your shoulders. That being said, if you're at said company/have said manager, you should get a new job. I hear the market is hot.
- ep103 5y ago
  https://en.wikipedia.org/wiki/Arete https://en.wikipedia.org/wiki/Arete
- 35fbe7d3d5b9 5y ago
archeantus 5y ago
I loved the build up in this article, but the solution left me wanting more. My org suffers from the disease of Date Driven Development, but just telling my boss to let us work until it is done simply means we will never ship because it will never be done. Literally the list of new feature requests from product is a mile long. So where do you draw the line? And once you draw the line, how can you justify pushing off on everything else that needs to get done while you are hardening and making sure that what you have decided to ship is actually ready to go? The problem statement resonates with me, but I’d love more help on the solution. What is a viable way to get out of date driven development? Please help!
- jbuhbjlnjbn 5y ago
  Simple: differentiate between basic feature maturity and additional optional features. You release a working product, then you add working functionality over time. This is what the successful software companies do today anyways.
- Jtsummers 5y ago
  Take an incremental approach. Establish the core needs, what must be shipped as a basic system, and ship it. Then extend over a series of iterations where you incorporate more needs and wants. You won't totally avoid the deadline, but you will mitigate one of the deadline problems: All-or-nothing. If you establish a deadline 1-3 years from now it is expected the entire system will be finished on that date. Well what if it's not? Establish quarterly releases (or more often, especially if you can work with the team deploying the system like if you're an internal dev shop) and aim for a first release in a few months that hits the essentials. Everything else is an extension, you may still take 1-3 years (or longer) but you'll be releasing and getting value from the system right away. I've even done this with safety critical real-time systems in my work. We built what was necessary for flight test, but not desirable for operations (missed a few needs, a lot of wants). By the time the plane was rolling off the factory floor for release to airlines, we had all the needs covered and most of the wants. The rest of the wants were covered in the next year or so as well as some newly discovered needs. But if we'd waited to have everything done, the plane wouldn't have been delivered to customers for several more years (because flight testing would have been delayed by about 3 years).

deleted 5y ago

[deleted]

This reads a lot like a lean/MVP manifesto. I would say that there is always a pressure to deliver working code, but that “unfinished” should always be in terms of project scope and not in terms of either functionality or reliability. “Code” is the wrong terminology here. It’s OK to not have every feature implemented. But it’s not OK to ship half-baked, untested functionality, no matter what the “code” looks like.

yakshaving_jgt 5y ago
Conversely, half-assed is ok if you only need half an ass.
commandlinefan 5y ago
> This reads a lot like a lean/MVP manifesto It also reads like the Agile manifesto from 20 years ago, which caused a huge splash when it was first published - before it was misinterpreted by everybody who might have been able to actually apply it to obtain results as "do exactly what you've always been doing (especially in terms of fixing a delivery date long before you describe what the software is supposed to do), but use terminology like 'sprints' and 'standups' to do it".

Guthur 5y ago

One of the problems I have found is that we don't talk the same language when communicating with the business, we use terms like "Technical Debt", "Test Coverage", even "Minimal Viable Product". In my opinion the universal variable across all these is risk, and it's easy for all to grasp what we mean when we say the word "Risk". There is delivery risk, will be get this out in a timely fashion for the market. There is operational risk, will this fall over if we get 10x users or if someone looks at it funny. There is market fit risk, are we building the right thing for the customer. Framing these conversation with the business as functions of risk analysis and management is a fundamental part of leadership in my opinion.

makeitdouble 5y ago
I am not versed enough in car things, but it seems to me this would be something maintenance shops nailed down decades ago. How would they convey that your car is lacking maintenance even if you can still drive it to work ? Perhaps we should go with "needs repair" or something like that ? "Risk" feels like insurance territory (which goes along with "there is always some risk"), and a lot of people beautify the notion of taking risks to get higher gains.
- giansegato 5y ago
  Risk-taking is very cultural dependent, in some contexts people would avoid taking risks as their default option. That said, I feel that car shops just work because, well, it's the law, especially in some countries. In the end "needs repair" is the same as saying "mitigating accident risk".
- Cthulhu_ 5y ago
  The risk for a shoddy car is that you end up killing someone or get written up and charged with a violation. The risk for shoddy software (in most cases) is that you have an outage and suffer some financial or reputation damage, but that won't put you out of business. There's laws against bad cars, there's no laws against bad software.
  - squiggleblaz 5y ago
    > There's laws against bad cars, there's no laws against bad software. There's often privacy/data protection obligations, but they seem to be impossibly difficult to get the courts to pay attention to. If the average business owner would find themselves in legal shit every time an external party got access to their data (i.e. just being the victim of a ransomware attack puts you at risk of losing your home), they would probably pay more attention.
- OJFord 5y ago
  And then we can scathingly label the most hated parts 'beyond economical repair'!

jahnu 5y ago

> Unfinished code that is full of race conditions, performance problems, outright bugs and worst of all, poor to non-existent product/market fit. The last one is so different than the rest. Bugs shouldn't even "ship" internally in that they shouldn't really be making it out of feature branches often for some reasonable value of often. But back to the last one, that's something that should be decided with high confidence before the first line of code is written!

tonyedgecombe 5y ago
The last one is the hardest to get right in my experience. Sometimes you just won’t know until you start asking people to put their hand in their pocket.
- Cthulhu_ 5y ago
  I mean there's been a few successful companies like Slack that started off with something completely different before they pivoted. Sometimes market fit takes some experimentation.

brainwipe 5y ago

This article raises some great points but is still trying to close the stable door after the horse has bolted. If your business is agile, it begins with the style of engagement between you and the customer. Really agile businesses don't deal with absolutes (such as fixed price contracts), instead they accept change at the core. Accounting hate that, so most businesses aren't agile.

phkahler 5y ago

Deliver something the customer wants, make the product better, or figure out why those 2 things are not the priorities. It's usually money or politics.

eric4smith 5y ago

My dad who was a quite successful artist back in the day said something I’ll never forget. “Son, I’d like to work on that painting forever, because for me it’s never finished. But I have to stop and sell it because I have to feed the 3 of you children”. His sole source of income was his art, and we grew up not wanting anything, because he was pragmatic enough to understand at some point he had to ship his art to survive - even if to him, it was not completed. That’s why when I heard Steve Jobs say “real artists ship”… I immediately understood at a visceral level what he meant. And iPhones over the years have had countless bugs.

djmips 5y ago
Hmmm, everything has bugs. The iPhone shipped as a great product that customers loved. The point of the article is to release something great that the customers will love. Internally, yes, ship something early and iterate on feedback.
barbazoo 5y ago
That's a great lesson your dad taught you there. I wish I had been taught that early on in my career because it applies just as well to an organization.

nlitened 5y ago

> Engineers are problem solvers, and a manager who applies pressure becomes the problem the engineers decide they need to solve. If it is really important to deliver Something™ by the date, engineers will, if enough pressure is applied, deliver unfinished code by that date. Unfinished code that is full of race conditions, performance problems, outright bugs This is wrong. You can and should deliver "by the date", but you should also prioritize ruthlessly, and ship at least the top of most-important-features list with reasonable quality when time runs out. Of course, this implies that both managers and engineers have to understand deeply, what value each feature brings, and communicate among themselves and with their client continuously.

titzer 5y ago

> The top two sources of failure in software development projects are failing to discover what is actually needed and failure to eliminate chaos in the software before delivering it to the customer. The first one is called requirements gathering (the method, requirements engineering). I was wondering how far I was going to have to read to find someone mentioning that. It can be as simple as writing down a list of things the software has to do. It could be one afternoon brainstorming meeting, to start. But we don't even bother. Why? Because this discipline is not engineering, not science, not manufacturing. One my darker days, I think we are just playing in the mud. I am grateful to work on virtual machines and compilers. They at least have functional requirements--an input specification--and a well-specified target machine. The rest in the middle is a fun design exercise, but there is a crucible at the end of the day. If you can't run the programs without bugs, you have failed. That makes it easy to put functional correctness first and performance second, as it should be. We need to find more ways of translating problems into requirements in order to reduce black art to science to practice.

blacktriangle 5y ago
I agree it's a bit like playing in the mud, but the more I work the more I suspect that's just accepting reality. Requirements gathering works wonderfully for internal projects with a fixed set of stakeholders and a well defined problem with measurable outcomes. Product development is a whole different world whose outcome is the much more vague "generate profit for the developers". Particularly in the realm of B2B software. You need to find some local minimum that will meet the needs of thousands of organizations in order for development to be worthwhile. You need to get many busy people who don't know you to actually talk to you. You need to talk to multiple different stakeholders within the organization. And even after you group all your stakeholders into some kind of user personas, you still haven't accounted for what the larger organizational behavior will be, as B2B products generally require large-scale buy-in. And at the end of the day, no matter what people say they will do, the true test is when a company actually opens their coffers and pays your invoice. We've arrived down here in the mud through years of experience of doing requirements gathering, building to a spec, and then finding out that we built the wrong thing and nobody will pay us for all our hard work. Sometimes you really do have to build it to see if they will come. And the more formalized (ie expensive) you make the requirements engineering process, the more compelling the iterate and start getting paying customers asap plan becomes.

commandlinefan 5y ago

As Dilbert says: "Our boss can't judge the quality of our work, but he knows when it's late".

barbazoo 5y ago
And just like Scott Adams is so wrong about many things he says, Dilbert is wrong here or at least short sighted too. While you notice immediately that something is on time, you'll also notice really quickly that something is of bad quality, unreliable, inconsistent, low performant, etc which translates in whoever the customer is to be very unhappy very quickly. There needs to be a well-informed balance. I know you were just posting a funny Dilbert quote but I don't respect Scott Adams anymore so I was triggered, please accept my apologies.
- vegetablepotpie 5y ago
  I can see that you have not been exposed to the magic of bureaucratic indifference. If you release a really shitty product, and your customer doesn’t have choice (has no competitor, made a large upfront payment, has fallen into vendor lock-in, etc), you don’t have to respond. You can translate an unhappy customer into a compliant one by putting up barriers to the reporting and documentation of the issue. Make automated resolutions that don’t quite fit the situation, put the issue into a ticketing system that never addresses the issue, give employees roles that either overlap with each other or don’t intersect at all over the customers issue, etc. These are the situations that Scott Adams parodies with Dilbert.
- lnanek2 5y ago
  > While you notice immediately that something is on time, you'll also notice really quickly that something is of bad quality, unreliable, inconsistent, low performant, etc Not in my experience. Our team has a couple core perf metrics that are alarmed, like page load and missed frames, but it's easy to do really bad things that won't trigger the alarms. Or do them such that the automated tests are using different content for the pages they test than the real users who will see the commits weeks later. E.g. someone commits a change to feature x that locks up the screen, but the test user pool never uses feature X, or never puts content into it and just sees the empty state screen. Quite common for developers here to write stuff that works for 99% of users, but falls over otherwise as well. Like today I fixed an issue where tapping a button on one screen to go to another really fast, like under 1 second, crashes because of a race condition. Testers aren't going to notice that. It just shows up in the company's overall crash rate which is spread across 4000 developers. Automatic UI tests caught it, but the responsible team had just filed the crash stack trace JIRA into their backlog and left it to sit for months. Similarly, today, we had a production issue because someone wrote some code that only works for certain users who had already accepted a certain terms of service screen. Shipping a feature is rewarded heavily. Not screwing up the app for edge cases and perf and people who have to implement the next feature after you? Good test coverage? Not at all. If you dare to give an estimate that includes full test coverage, PMs will just take you off the project and pick a developer who doesn't do that.

javier10e6 5y ago

Not to be thrown into semantics but... Scope vs. Goal The goal defines the scope. If the goal does not change, neither the scope. When the goal includes a date...the scope has no way to adjust because scope refers, simply put, to a to-do list. A poorly conceived date does not change the scope, it cuts short the to-do list. How long does it take to a Nascar Team to win the Indy 500? 500 miles as fast as humanly possible.

Havoc 5y ago

Half finished work they would never do su

nine_zeros 5y ago

A rational manager would scope projects with their technical leaders AND senior engineers who will ultimately execute. This scoping must happen before selling the project and also constantly throughout the lifecycle of the project. Then, the rational manager would also manage expectations with other stakeholders, not committing to things they cannot see the end to. But most managers are not rational and do the complete opposite. They want to "appear" amazing managers to other stakeholders while simultaneously bringing their "ego" in discussions with team leads and senior engineers. Nobody is happy with such managers. I think a better org structure would be managers reporting to senior engineers instead of senior engineers reporting to managers. Senior engineers are responsible for the implementation. Managers merely act as assistants delivering messages everywhere.

keynesyoudigit 5y ago

As a Dev this looks like such a wonderful approach to me, but how do you get the customer on board with this? How do you get a nervous customer that doesn't trust you yet to enthusiastically work with you figure out what they want?

H8crilA 5y ago

Here's a question: why do you, as an engineer, care? You're just an employee, it is the upper management's role to make sure your company moves forward, maintains the trust of clients, has reliable enough solutions. If they decide to sacrifice quality for speed that's their problem/decision. Really. You were hired to provide technical solutions within specs, and if specs require fast completion more than quality then that's probably what you should deliver. Then watch it blow up, or maybe it will actually be good enough.

haolez 5y ago
True, but the "be good enough" will probably be updated on what "good enough" is after you deliver your first impossible project. It'll eventually catch up, but that's just how bad executives and bad companies manage.
dkdk8283 5y ago
You care if you work in security, and ops but perhaps to a lesser extent.
3pt14159 5y ago
I'm honest about delivery dates, but I do deeply care about getting a project across the line on time. Not just because it gets me cooler, more demanding projects with larger compensation, also for its own sake. It's fun to win, especially when the timeline isn't arbitrary and you can pull it off.
astockwell 5y ago
This _should_ be true, but isn't always, if you're at a company (or just have a manager) who will let the mess/blame fall onto your shoulders. That being said, if you're at said company/have said manager, you should get a new job. I hear the market is hot.
ep103 5y ago
https://en.wikipedia.org/wiki/Arete https://en.wikipedia.org/wiki/Arete
35fbe7d3d5b9 5y ago

archeantus 5y ago

I loved the build up in this article, but the solution left me wanting more. My org suffers from the disease of Date Driven Development, but just telling my boss to let us work until it is done simply means we will never ship because it will never be done. Literally the list of new feature requests from product is a mile long. So where do you draw the line? And once you draw the line, how can you justify pushing off on everything else that needs to get done while you are hardening and making sure that what you have decided to ship is actually ready to go? The problem statement resonates with me, but I’d love more help on the solution. What is a viable way to get out of date driven development? Please help!

jbuhbjlnjbn 5y ago
Simple: differentiate between basic feature maturity and additional optional features. You release a working product, then you add working functionality over time. This is what the successful software companies do today anyways.
Jtsummers 5y ago
Take an incremental approach. Establish the core needs, what must be shipped as a basic system, and ship it. Then extend over a series of iterations where you incorporate more needs and wants. You won't totally avoid the deadline, but you will mitigate one of the deadline problems: All-or-nothing. If you establish a deadline 1-3 years from now it is expected the entire system will be finished on that date. Well what if it's not? Establish quarterly releases (or more often, especially if you can work with the team deploying the system like if you're an internal dev shop) and aim for a first release in a few months that hits the essentials. Everything else is an extension, you may still take 1-3 years (or longer) but you'll be releasing and getting value from the system right away. I've even done this with safety critical real-time systems in my work. We built what was necessary for flight test, but not desirable for operations (missed a few needs, a lot of wants). By the time the plane was rolling off the factory floor for release to airlines, we had all the needs covered and most of the wants. The rest of the wants were covered in the next year or so as well as some newly discovered needs. But if we'd waited to have everything done, the plane wouldn't have been delivered to customers for several more years (because flight testing would have been delayed by about 3 years).