Executing Software Engineers for Bugs • Hacker News Board

Re: Executing Software Engineers for Bugs

#71

Post by calinet6 » Mon, Nov 02, 2015, 3:39 PM UTC

p0nce wrote: post #61

calinet6 wrote: post #34

Earlier quoted context omitted.

That's a highly simplistic and incorrect viewpoint—and the correctness of a model is not dependent on popular vote. When looking at increasing quality (essentially, scope) in isolation of systems and the environment in which that quality is created, then the only way to increase quality is to increase cost. That much is true, but it's also incomplete. When looking at and eventually optimizing the whole system—from th…

It's amazing you have to justify this view point. There are books precisely documenting the correlation between quality, speed of execution and lower costs. http://ptgmedia.pearsoncmg.com/images/9780132582209/samplepa...

Exactly. The resistance to change is stunning. It's an ingrained psychology of individuality continuing to dig our management hole for us. Ignore the system at your peril.

Re: Executing Software Engineers for Bugs

#72

Post by calinet6 » Mon, Nov 02, 2015, 3:52 PM UTC

kabdib wrote: post #45

calinet6 wrote: post #34

Earlier quoted context omitted.

That's a highly simplistic and incorrect viewpoint—and the correctness of a model is not dependent on popular vote. When looking at increasing quality (essentially, scope) in isolation of systems and the environment in which that quality is created, then the only way to increase quality is to increase cost. That much is true, but it's also incomplete. When looking at and eventually optimizing the whole system—from th…

If true, this is truly amazing. So here's a quick test: 1. Write a letter outlining the above to a VC. Explain how this works in somewhat more detail; 10-15 pages should get it across. Sure it's work. But you seem resolved, and the reward is great. If you pull this off, not only are you gonna get a Turing award, they're going to mint a whole new award and name it after you. Anyway, give it a decent treatment and mail…

Interesting sarcastic, insulting proposal. I'm tackling just that issue within my own company now, and it's incredibly difficult. I'll explain why.

The main issue is that once you exceed a certain number of developers, the problems become more human than software. It's not the software problem we need to solve, and our solution to the human problem thus far is highly individual and anti-system, riddled with ineffective processes, "communication problems," and "culture issues" that we believe are someone else's problem that we can do very little to fix even as leaders. These are the root cause of quality issues, and without looking at the whole system—and indeed, creating a whole organization capable of looking at the whole system—the quality issues will continue dependably.

The final issue is that when it comes to people problems, everyone has their own beliefs. Ideas are easy—ideas can be explained, processes implemented, software designed—but beliefs are hard. If I were to write to a VC outlining these ideas (which are W. Edwards Deming's ideas circa 1950, Joseph Juran's ideas circa 1980, and Peter Sholtes's ideas continuing into the 90's, and the foundation of the current Lean movement in software, education, manufacturing, and healthcare)‚ what would really change? I can make a convincing argument, but I would be in for a 1-3 year conversation about beliefs about management and people, depending on the person and their adaptability and openness to new ideas. It's much easier to simply do it, and I'm trying to do as much as I can in the context of a growing company at present.

Plus, there are companies who are already into this stuff. Pluralsight integrates Deming's philosophy into their management and onboarding. Check them out.

Someday I will start my own company, and these concepts will be at the foundation. For sure. Until then, I'll try my best to shift some perspectives.

Re: Executing Software Engineers for Bugs

#73

Post by calinet6 » Mon, Nov 02, 2015, 3:58 PM UTC

dllthomas wrote: post #47

calinet6 wrote: post #19

Earlier quoted context omitted.

This is simply false. True systemic quality will lower costs, speed production, and increase value all at once. The reason is that, beyond a certain organizational complexity, we fail at creating the systems necessary to create the positive feedback loops necessary for quality, low cost, and fast execution to flourish naturally. Instead, we live in dysfunctional organizations where the tradeoffs prevail, and we choos…

"True systemic quality will lower costs, speed production, and increase value all at once." When you say "true systemic quality" are you speaking far beyond the scope of what any one company is responsible for? Otherwise, I suspect those replying to you are correct - if bug-free software can be written, quicker and cheaper than software that winds up retaining some bugs, based on work well enough known for 20 years,…

No, absolutely not. I'm talking about the system of a single company; its customers, inputs, processes and people, and finally outputs.

What do you think is the scope any one company is responsible for? Is there something about the quality of their output that they are not responsible for?

I'm not saying bug-free software is the goal, and maybe I'm too far off on a tangent to still be relevant to this conversation—just trying to get across that bugs come from somewhere, you should think about what all that "somewhere" is by looking at the complex system surrounding it, and you should not punish your developers or put them under the metaphorical bridge to hold them accountable for not producing bugs. That is ridiculous and ignorant of the system, and the system between and around people—not the individuals themselves—are where bugs come from.

Re: Executing Software Engineers for Bugs

#74

Post by dllthomas » Mon, Nov 02, 2015, 5:12 PM UTC

calinet6 wrote: post #73

dllthomas wrote: post #47

Earlier quoted context omitted.

"True systemic quality will lower costs, speed production, and increase value all at once." When you say "true systemic quality" are you speaking far beyond the scope of what any one company is responsible for? Otherwise, I suspect those replying to you are correct - if bug-free software can be written, quicker and cheaper than software that winds up retaining some bugs, based on work well enough known for 20 years,…

No, absolutely not. I'm talking about the system of a single company; its customers, inputs, processes and people, and finally outputs. What do you think is the scope any one company is responsible for? Is there something about the quality of their output that they are not responsible for? I'm not saying bug-free software is the goal, and maybe I'm too far off on a tangent to still be relevant to this conversation—ju…

"What do you think is the scope any one company is responsible for? Is there something about the quality of their output that they are not responsible for?"

They are not responsible for the output of other companies. My question was whether you were speaking to what one company could do, or what was prevalent in the development ecosystem. It seems that you were speaking to the former.

I certainly don't hold a position that there are no gains to be had focusing on the system. I do think it is most reasonable to say we don't know how to attain them in a way that acheives quality (or specifically lack of defects) at the level envisioned up-thread. The ways we do already know to attain that level of quality do impose substantial cost.

(And for the record, I certainly agree that individual punishment of developers is unlikely to get us to any better place.)

Re: Executing Software Engineers for Bugs

#75

Post by JoeAltmaier » Mon, Nov 02, 2015, 5:25 PM UTC

linuxkerneldev wrote: post #42

This author's first sentence is: "There is an apocryphal tale I've heard many times about how, in Ancient Rome (or, in some tellings, Greece), the engineers responsible for the construction of an arch were required to stand underneath it as the final wooden supports were taken out." This story is derived from Law #229 of the Code of Hammurabi (of Babylon). Babylon was not part of Greece, but it was very briefly part…

My Dad told the tale of a farmer coming to the repair shop with a tractor gas tank needing repair. The mechanic refused. The farmer insisted he'd cleaned the tank; no danger of explosion while it was being welded. The mechanic replied "Ok, I'll weld it, if you hold it while I'm doing that." The farmer left.

Re: Executing Software Engineers for Bugs

#76

Post by Kalium » Mon, Nov 02, 2015, 5:43 PM UTC

TheSpiceIsLife wrote: post #65

Kalium wrote: post #53

Earlier quoted context omitted.

If anything, with the advent of bootcamps, software engineering is moving away from formal education and into trade schooling. Personally, I think this is a step backwards for the discipline.

I resent a little bit. I'm a boiler-maker / welder by trade (metal fabrication). My trade certificate actually says "Engineering Tradesperson". I operate a laser cutter, and have written scripts to automate some of my computer related tasks, and have a rudimentary understanding of Python. I've also worked at an ISP in NetOps doing physical security and infrastructure. I live in Australia so I can only speak for the s…

Please accept my apologies.

With the current state of bootcamps in the US, I feel it's a stretch to call them formal education. They are at best short training programs. There's no accreditation, no accrediting body, and no real quality control beyond the press. That the field has few widely accepted standards does not help matters.

Personally, I suspect that the advent of bootcamps in the US is a fad driven by the explosion of the tech sector and the amount of time it takes to train a computer scientist. I suspect that in ten years, they will be much less popular as people who only know Ruby or PHP drop out of the field. It's hard to have a multi-decade long career in computing if you don't actually understand computers.

Re: Executing Software Engineers for Bugs

#77

Post by kabdib » Mon, Nov 02, 2015, 5:50 PM UTC

calinet6 wrote: post #72

kabdib wrote: post #45

Earlier quoted context omitted.

If true, this is truly amazing. So here's a quick test: 1. Write a letter outlining the above to a VC. Explain how this works in somewhat more detail; 10-15 pages should get it across. Sure it's work. But you seem resolved, and the reward is great. If you pull this off, not only are you gonna get a Turing award, they're going to mint a whole new award and name it after you. Anyway, give it a decent treatment and mail…

Interesting sarcastic, insulting proposal. I'm tackling just that issue within my own company now, and it's incredibly difficult. I'll explain why. The main issue is that once you exceed a certain number of developers, the problems become more human than software. It's not the software problem we need to solve, and our solution to the human problem thus far is highly individual and anti-system, riddled with ineffecti…

As a boots-on-the-ground guy, it was intended to be a little rattling.

I've seen soooo many smake oil proposals, and wishy-washy garbage that amounted to "just do a better job", and I've kicked out a couple of consultants who wanted money (and one wanted a process patent!) for a scheme that amounted to "track team member progress on a whiteboard in your common area". Too many people with not enough background (or bad motives) think they have the answer.

So, I'm jaded. And allergic to rhetoric, because so much of it over the past 30-40 years has been vacuous bullshit.

This stuff is hard, no fooling. And rhetoric won't solve it. I'm happy you're actually doing something about it, and realize that it's difficult, and I honestly hope that you do well.

Re: Executing Software Engineers for Bugs

#78

Post by calinet6 » Mon, Nov 02, 2015, 6:06 PM UTC

kabdib wrote: post #77

calinet6 wrote: post #72

Earlier quoted context omitted.

Interesting sarcastic, insulting proposal. I'm tackling just that issue within my own company now, and it's incredibly difficult. I'll explain why. The main issue is that once you exceed a certain number of developers, the problems become more human than software. It's not the software problem we need to solve, and our solution to the human problem thus far is highly individual and anti-system, riddled with ineffecti…

As a boots-on-the-ground guy, it was intended to be a little rattling. I've seen soooo many smake oil proposals, and wishy-washy garbage that amounted to "just do a better job", and I've kicked out a couple of consultants who wanted money (and one wanted a process patent!) for a scheme that amounted to "track team member progress on a whiteboard in your common area". Too many people with not enough background (or bad…

Hey, I appreciate this response. It's easy to become jaded. I'm often jaded too, and it takes everything I can muster to keep trying to improve things. Some days it's all I can do just to do my job and shut up the systems thinking part of my brain that wants to look outside it.

There are a lot of great ideas out there. What matters is what we do. Good luck, I wish you the best as well.

For what it's worth, this stuff is really great, and a good mental model for the reality of organizations. I highly recommend Peter Scholtes' book, The Leader's Handbook.

Re: Executing Software Engineers for Bugs

#79

Post by calinet6 » Mon, Nov 02, 2015, 6:17 PM UTC

rootlocus wrote: post #67

WildUtah wrote: post #14

"Executing Software Engineers for Bugs" Never have I been prouder to be a plain old programmer. Those software engineers, architects, systems analysts, and data scientists can keep the capital punishment for themselves.

You don't need a title to take responsibility.

The idea that "taking responsibility" is how we prevent bugs is what's wrong in the first place.

Quality is systemic, and has its roots across the organization.

Re: Executing Software Engineers for Bugs

#80

Post by EdSharkey » Mon, Nov 02, 2015, 6:50 PM UTC

calinet6 wrote: post #69

EdSharkey wrote: post #59

Earlier quoted context omitted.

For all you detractors, here's my story, maybe it will help you believe that quality is possible in our industry. I have been doing professional software development since 1997, and from then until two years ago, I have been a developer on waterfall and scrummerfall projects. There have been deathmarches aplenty and lots of failures small and large with some heroic successes here and there. Overall, I'd say the perfo…

Thank you. It is incredible how much resistance there is to the idea that quality is a positive feedback loop of value -- not simply a cost.

Is it incredible? Software development is such a young discipline. It's no surprise to me that the vast majority of actors are winging it here. I have a lot of sympathy for your detractors.

Keep on fighting for quality, it's worth battling over and teaching others about.