7 ms·

If only managers and CEOs saw it the same way.

by rubicon33 8y ago

winrid 8y ago
At my current company all leadership is in agreement that it is more expensive to deal with bugs in production.
- Frost1x 8y ago
  But CD...agile... It really depends on the scenario. If you can bill those fixes to the client or if you have to eat the cost to make the fixes. Most modern development processes seem to push this model simply because they can essentially pass the costs to the client and charge other or future clients for the improvements.
  - winrid 8y ago
    We charge upfront for someone to use the product and negotiate any feature requests.
WalterBright 8y ago
You'll see it in any piece of software written by any developer who is self-managed. The notion that software quality would greatly improve without managers is a myth.
- andbberger 8y ago
  [citation needed] idk man, my code is pretty damn clean
  - alacombe 8y ago
    Code cleanliness has no correlation with lack of bugs. Also, 1) your sample size is pretty small, and 2) what looks clean to you might very well be despicable to someone else.
    - blunte 8y ago
      And more importantly in this case, the appearance of your code is relatively meaningless compared to you failing to consider all cases of inputs. Honestly, the appearance of code is irrelevant. The goal is to absolutely accurately meet the requirements - the true, actual requirements. It may not be within scope to know all the information you need to know to cover all the cases, and that's certainly a problem. But the cleanliness of your code, assuming it functions correctly, is unimportant to the operation. (It certainly will be a maintenance cost, though.)
    - onemoresoop 8y ago
      The actual argument is that code cleanliness improves readability which in turn makes finding bugs easier and also eases the conceptualizing of what the code does. I'd say it's first line of defense against bugs.. tests could miss bugs too but that doesn't mean we shouldn't test thoroughly
    - andbberger 8y ago
      I guess that was a poorly chosen word on my part then. How about 'elegant'.
      - ncmncm 8y ago
        "Elegant" does't mean "right" either. But with elegant code it is often easier to tell if it's not right, and also how to get it right if it's not. Often that requires making it less elegant, because the real world rarely poses elegant problems. You want to ensure that as much as possible of the necessary inelegance is at the top level, with everything below clean.
  - WalterBright 8y ago
    I think my code is cool, too, until I look at it again 5 years in the future.
    - D-Coder 8y ago
      There's your problem — you're releasing too early. :-)
- ken 8y ago
  We seem to have very different experiences. Every manager I ever had (including one at Boeing) has pushed me to ship software that wasn't at all ready, on the basis that the UI of the prototype looked good.
  - WalterBright 8y ago
    If you were your own manager for your own code, you'd do it to. I'm unaware of any data showing managed software development is buggier than programmers working by themselves, and my experience is it is less buggy. Programmers by default tend to want to work on the fun stuff in a program, and neglect the unfun pedestrian stuff. This is where managers step in to improve things.
  - inflatableDodo 8y ago
    I am terrified these days of showing anything that looks like something that works to a project manager or client, without covering it in warning graphics. Even photoshop mockups of UIs, introduced as, "Here's a photoshop mockup of the UI, what do you think?" will get some people to demand that it be shipped immediately.
    - outworlder 8y ago
      One thing that I've learned (from someone else) is that unfinished software should look unfinished. Even if you have to muck around with CSS, disable some buttons here and there, maybe add something out of place. If the UI looks perfect, then everyone will deem it to be finished, even people who should know better. Yes, I'm advocating knowingly crippling demos. Your master branch may have something prettier, but take a sledgehammer and uglify the bastard before showing to decision makers.
- LordHog 8y ago
  In the various industries I have worked in DO-178B, industrial controls/IEC-61508, and storage the one consistency shared by managers is meeting schedules and milestones. Generally, a manager's insight to development/engineering is for the product to be just good enough. Developers/engineers have a tendency to over engineer the solution. Good peer reviews have the most influence on software quality as does independent testing. Managers rarely have little impact that I have witness over my 25 year career, thus far. For industries that adhere to DO-178B or IEC-61508 guidelines, it is the process that imbues greatly improved quality.
  - ncmncm 8y ago
    I have frequently seen standards, guidelines, and "process" prevent improvements to code. Since change is considered risky, it takes more time and effort to document improvement than the individual change is worth. But software improves, when it does, by a series of small changes, each by itself hardly worth doing, but in sum producing a wholly better product. It is the process that turned lizards into birds.
  - WalterBright 8y ago
    Businesses would not employ expensive managers if the dev teams worked better without them.
  - airbreather 8y ago
    Yep, 61508 is basically a specialized form of IS0 9000 quality management. And independent testing really makes a difference, I am trying to introduce automated testing into my company at the moment, they still spend a month with buttons and lights testing a safety system. I have been getting blank looks when I ask how they test for single scan events like this. But I know of several industrial incidents resulting from common single scan software design failures in safety systems (usually order of execution issues, but sometimes the flitter logic of oneshots is the cuplrit). One single scan incident in particular was from equipment in service for over 10 years, and then the stars suddenly aligned and the resulting software failure event ended up costing a big miner well over a billion dollars.
- rubicon33 8y ago
  It's the artificial timeline, not the manager. The manager just enforces the artificial timeline. A developer themselves can hold themselves to an artificial timeline. It takes discipline, and patience, to choose quality over speed to market. CEOs and managers almost always prioritize time to market, over quality. That's the problem.
  - WalterBright 8y ago
    Most projects (not just software) never ship unless there's a deadline. For example, how many students complete their term papers weeks before they're due? If there was no due date, how many would ever complete them? I know I never would have learned much of anything in college without deadlines and exams.
    - rubicon33 8y ago
      Of course. I'm not advocating for no deadlines. I'm advocating for flexibility. If your deadline arrives and you can honestly say you've worked hard but haven't met it, consider extending the deadline in the name of quality. Again, this takes discipline. You have to be honest with yourself if you are just moving the deadline back because you were slacking. In my case many times, the deadline was not hit because the scope of the project was underestimated. We were working hard on a new technology stack, but missed the deadline. Rather than delay the product, CEO decided to launch (despite our warnings). Needless to say, the brand suffered. I understand its a tug of war. Managers need to put out something. Engineers are never ready. The art in it all, is finding the balance. Being flexible to listen to your engineers, and knowing them well enough to trust them.
- blunte 8y ago
  Funny you should present it this way. My view is the opposite. As a self-managed, often solo developer, I find that team developers seem sloppy and very willing to choose not to consider the full scope of possibilities because they figure it's not their problem. Many of them work "to spec" and (rightfully?) choose not to consider the bigger picture.
alacombe 8y ago
One the other side, unless you are an artist and not dependant on your software actually being used, you have to get product out at some point. It's easy to demonize CEO and managers. We, as devs, will always find an excuse as to why the software is not ready and QA will always find new things to test to justify not putting the software out.
- Frost1x 8y ago
  It depends on the real world effects of pushing software out. If the side effects are minor and its perfectionism, then sure, push it out ugly. If it's a safety control mechanism for a car or airplane, then perfectionism needs to be applauded over faster time-to-market. If it's another chat application and changes can be easily rolled back, then push it out warts and all.
- Gibbon1 8y ago
  I think that 'can safely ship' is primary feature of any software project. What the means in practice is it puts pressure on new features and 'refactoring'
- airbreather 8y ago
  If you have fully defined what your software will do up front, then you are finished when have made it do what you said it would. Safety critical software is usually designed, built and tested to the V-model. When done properly every piece of logic/code can be traced back to a requirement through all steps and phases of development and testing. There is no "move fast and break things" in the safety instrumented field, the engineering hours per byte/instruction delivered would absolutely flabbergast most software devs, by many orders of magnitude.

If only managers and CEOs saw it the same way.

winrid 8y ago

At my current company all leadership is in agreement that it is more expensive to deal with bugs in production.

Frost1x 8y ago
But CD...agile... It really depends on the scenario. If you can bill those fixes to the client or if you have to eat the cost to make the fixes. Most modern development processes seem to push this model simply because they can essentially pass the costs to the client and charge other or future clients for the improvements.
- winrid 8y ago
  We charge upfront for someone to use the product and negotiate any feature requests.

WalterBright 8y ago

You'll see it in any piece of software written by any developer who is self-managed. The notion that software quality would greatly improve without managers is a myth.

andbberger 8y ago
[citation needed] idk man, my code is pretty damn clean
- alacombe 8y ago
  Code cleanliness has no correlation with lack of bugs. Also, 1) your sample size is pretty small, and 2) what looks clean to you might very well be despicable to someone else.
  - blunte 8y ago
    And more importantly in this case, the appearance of your code is relatively meaningless compared to you failing to consider all cases of inputs. Honestly, the appearance of code is irrelevant. The goal is to absolutely accurately meet the requirements - the true, actual requirements. It may not be within scope to know all the information you need to know to cover all the cases, and that's certainly a problem. But the cleanliness of your code, assuming it functions correctly, is unimportant to the operation. (It certainly will be a maintenance cost, though.)
  - onemoresoop 8y ago
    The actual argument is that code cleanliness improves readability which in turn makes finding bugs easier and also eases the conceptualizing of what the code does. I'd say it's first line of defense against bugs.. tests could miss bugs too but that doesn't mean we shouldn't test thoroughly
  - andbberger 8y ago
    I guess that was a poorly chosen word on my part then. How about 'elegant'.
    - ncmncm 8y ago
      "Elegant" does't mean "right" either. But with elegant code it is often easier to tell if it's not right, and also how to get it right if it's not. Often that requires making it less elegant, because the real world rarely poses elegant problems. You want to ensure that as much as possible of the necessary inelegance is at the top level, with everything below clean.
- WalterBright 8y ago
  I think my code is cool, too, until I look at it again 5 years in the future.
  - D-Coder 8y ago
    There's your problem — you're releasing too early. :-)
ken 8y ago
We seem to have very different experiences. Every manager I ever had (including one at Boeing) has pushed me to ship software that wasn't at all ready, on the basis that the UI of the prototype looked good.
- WalterBright 8y ago
  If you were your own manager for your own code, you'd do it to. I'm unaware of any data showing managed software development is buggier than programmers working by themselves, and my experience is it is less buggy. Programmers by default tend to want to work on the fun stuff in a program, and neglect the unfun pedestrian stuff. This is where managers step in to improve things.
- inflatableDodo 8y ago
  I am terrified these days of showing anything that looks like something that works to a project manager or client, without covering it in warning graphics. Even photoshop mockups of UIs, introduced as, "Here's a photoshop mockup of the UI, what do you think?" will get some people to demand that it be shipped immediately.
  - outworlder 8y ago
    One thing that I've learned (from someone else) is that unfinished software should look unfinished. Even if you have to muck around with CSS, disable some buttons here and there, maybe add something out of place. If the UI looks perfect, then everyone will deem it to be finished, even people who should know better. Yes, I'm advocating knowingly crippling demos. Your master branch may have something prettier, but take a sledgehammer and uglify the bastard before showing to decision makers.
LordHog 8y ago
In the various industries I have worked in DO-178B, industrial controls/IEC-61508, and storage the one consistency shared by managers is meeting schedules and milestones. Generally, a manager's insight to development/engineering is for the product to be just good enough. Developers/engineers have a tendency to over engineer the solution. Good peer reviews have the most influence on software quality as does independent testing. Managers rarely have little impact that I have witness over my 25 year career, thus far. For industries that adhere to DO-178B or IEC-61508 guidelines, it is the process that imbues greatly improved quality.
- ncmncm 8y ago
  I have frequently seen standards, guidelines, and "process" prevent improvements to code. Since change is considered risky, it takes more time and effort to document improvement than the individual change is worth. But software improves, when it does, by a series of small changes, each by itself hardly worth doing, but in sum producing a wholly better product. It is the process that turned lizards into birds.
- WalterBright 8y ago
  Businesses would not employ expensive managers if the dev teams worked better without them.
- airbreather 8y ago
  Yep, 61508 is basically a specialized form of IS0 9000 quality management. And independent testing really makes a difference, I am trying to introduce automated testing into my company at the moment, they still spend a month with buttons and lights testing a safety system. I have been getting blank looks when I ask how they test for single scan events like this. But I know of several industrial incidents resulting from common single scan software design failures in safety systems (usually order of execution issues, but sometimes the flitter logic of oneshots is the cuplrit). One single scan incident in particular was from equipment in service for over 10 years, and then the stars suddenly aligned and the resulting software failure event ended up costing a big miner well over a billion dollars.
rubicon33 8y ago
It's the artificial timeline, not the manager. The manager just enforces the artificial timeline. A developer themselves can hold themselves to an artificial timeline. It takes discipline, and patience, to choose quality over speed to market. CEOs and managers almost always prioritize time to market, over quality. That's the problem.
- WalterBright 8y ago
  Most projects (not just software) never ship unless there's a deadline. For example, how many students complete their term papers weeks before they're due? If there was no due date, how many would ever complete them? I know I never would have learned much of anything in college without deadlines and exams.
  - rubicon33 8y ago
    Of course. I'm not advocating for no deadlines. I'm advocating for flexibility. If your deadline arrives and you can honestly say you've worked hard but haven't met it, consider extending the deadline in the name of quality. Again, this takes discipline. You have to be honest with yourself if you are just moving the deadline back because you were slacking. In my case many times, the deadline was not hit because the scope of the project was underestimated. We were working hard on a new technology stack, but missed the deadline. Rather than delay the product, CEO decided to launch (despite our warnings). Needless to say, the brand suffered. I understand its a tug of war. Managers need to put out something. Engineers are never ready. The art in it all, is finding the balance. Being flexible to listen to your engineers, and knowing them well enough to trust them.
blunte 8y ago
Funny you should present it this way. My view is the opposite. As a self-managed, often solo developer, I find that team developers seem sloppy and very willing to choose not to consider the full scope of possibilities because they figure it's not their problem. Many of them work "to spec" and (rightfully?) choose not to consider the bigger picture.

alacombe 8y ago

One the other side, unless you are an artist and not dependant on your software actually being used, you have to get product out at some point. It's easy to demonize CEO and managers. We, as devs, will always find an excuse as to why the software is not ready and QA will always find new things to test to justify not putting the software out.

Frost1x 8y ago
It depends on the real world effects of pushing software out. If the side effects are minor and its perfectionism, then sure, push it out ugly. If it's a safety control mechanism for a car or airplane, then perfectionism needs to be applauded over faster time-to-market. If it's another chat application and changes can be easily rolled back, then push it out warts and all.
Gibbon1 8y ago
I think that 'can safely ship' is primary feature of any software project. What the means in practice is it puts pressure on new features and 'refactoring'
airbreather 8y ago
If you have fully defined what your software will do up front, then you are finished when have made it do what you said it would. Safety critical software is usually designed, built and tested to the V-model. When done properly every piece of logic/code can be traced back to a requirement through all steps and phases of development and testing. There is no "move fast and break things" in the safety instrumented field, the engineering hours per byte/instruction delivered would absolutely flabbergast most software devs, by many orders of magnitude.