5 ms·

> figure out some way to qualify what makes good software engineering I doubt we'll ever be able to distill it to a formula. People ran successful software pr

by jarrett 13y ago

> figure out some way to qualify what makes good software engineering I doubt we'll ever be able to distill it to a formula. People ran successful software projects decades ago, long before any methodologies were formally described. And they have failing projects now, even when they use a supposedly good formal methodology. Instead of another alternative to waterfall, scrum, or agile, I'd propose the following ingredients for success: Organized people, a good working relationship with plenty of trust, a clear understanding of roles and responsibilities, realistic expectations, and colleagues who honor their agreements with each other. To name a few. All of this is peopleware, not process. Unfortunately, there's no silver bullet to get this stuff right.

fragsworth 13y ago
Agreed. These development processes and methodologies are pretty strange, actually. The confidence expressed by their proponents in the face of failure gives it a very cultish vibe, and I get the sense that they're just making things up for the sake of having "an answer". The best answer is probably to get people who are experienced in similar projects to manage your project, and has little to do with the process they choose to use.
YZF 13y ago
But what about the technical/professional side of things? I know there's no silver bullet but those of us who have been through a few projects have a pretty good idea of what's going to work and what isn't. We can tell, well in advance, what's going to work and what isn't both in terms of the technical approach and the management process. Agree? If that is the case how do we convert that intuition into something that can work in the real world? Is certification the answer? Specialization? How do we recognize excellence?
- hga 13y ago
  Respect, I'd say. But e.g. how many times have you told a superior something like "This won't work because of math" and then been simply ignored? Until, of course, the system/project goes down in flames. We need stature that can get around Pournelle's Iron Law of Bureaucracy: (https://en.wikipedia.org/wiki/Jerry_Pournelle#Iron_Law_of_Bureaucracy https://en.wikipedia.org/wiki/Jerry_Pournelle#Iron_Law_of_Bu...): "In any bureaucracy, the people devoted to the benefit of the bureaucracy itself always get in control and those dedicated to the goals the bureaucracy is supposed to accomplish have less and less influence, and sometimes are eliminated entirely." And this amplified restatement: "...in any bureaucratic organization there will be two kinds of people: those who work to further the actual goals of the organization, and those who work for the organization itself. Examples in education would be teachers who work and sacrifice to teach children, vs. union representatives who work to protect any teacher including the most incompetent. The Iron Law states that in all cases, the second type of person will always gain control of the organization, and will always write the rules under which the organization functions." Lawyers frequently don't get that. Doctors? Not so sure anymore, the same masters of the universe have been revising the way they have to do medicine (e.g. the Obamacare foretaste in the stimulus bill requiring "meaningful use" of Electronic Medical Records). Scratch that, Obama's utter contempt for doctors was strongly on display while he was barnstorming the nation, e.g.: "Right now, doctors a lot of times are forced to make decisions based on the fee payment schedule that’s out there. So if they’re looking and you come in and you’ve got a bad sore throat or your child has a bad sore throat or has repeated sore throats, the doctor may look at the reimbursement system and say to himself, 'You know what? I make a lot more money if I take this kid’s tonsils out.'" Or what about the conceit that a generic MBA can manage anything? MIT considered this the #1 problem for it to address in the '80s.
- phreanix 13y ago
  While recognizing the completely different context, I'd approach it like organized sports management/coaching. There you have disparate members with similar skillsets but different roles that as a whole contribute to one thing: winning. Trust, respect, belief in each other's abilities, and most of all, pushing HARD to accomplish a shared goal and vision. You have a captain who plays, a coach who is trusted completely, and different roles that are recognized as indispensable yet won't work without the others playing their part. Of course not everyone wants to be pushed this hard, wants to be part of something like this, and is paid enough to take the obvious abuse. It's just something nice to fantasize about.
  - jarrett 13y ago
    Exactly. These types of social attributes are necessary for a software project to succeed. The problem, of course, is that you can't devise a system which will reliably organize an arbitrary group of people* into the kind of effective team you describe. * As an example of an "arbitrary group of people," consider the set of contracted engineers, contracted managers, government employees, and insurance company personnel that had to work together on healthcare.gov. These are people who were not previously on a team together, and who cannot be expected to be of a uniformly high quality.
    - phreanix 13y ago
      What if product managers were trained to be more like sports coaches? Motivation, the right game plan, and working hand in hand with other products managers? Doesn't an organization like NASA work somewhat the same way? Different teams tackling different parts of a project and ending up with a rover on Mars?
- jarrett 13y ago
  > We can tell, well in advance, what's going to work and what isn't both in terms of the technical approach and the management process. Agree? Yes, those of with experience can usually spot this stuff early on. But that doesn't mean we're in any position to do anything about it. Most often, software projects come pre-populated with people and institutional cultures. We don't get to pick the people and design the cultures from the ground up. At least not when we're contracting. > If that is the case how do we convert that intuition into something that can work in the real world? If you're building a startup that sells a product, then you hire good people and foster a healthy company culture. You're not beholden to any one outside entity, so you're not forced to import any such entity's preexisting pathologies. If you're contracting? I think you just have to accept that projects will involve destructive people and cultures at times. Sometimes they'll cause projects to fail. In that case, the best you can hope to do is to protect yourself and your reputation.

by jarrett 13y ago

fragsworth 13y ago

Agreed. These development processes and methodologies are pretty strange, actually. The confidence expressed by their proponents in the face of failure gives it a very cultish vibe, and I get the sense that they're just making things up for the sake of having "an answer". The best answer is probably to get people who are experienced in similar projects to manage your project, and has little to do with the process they choose to use.

YZF 13y ago

But what about the technical/professional side of things? I know there's no silver bullet but those of us who have been through a few projects have a pretty good idea of what's going to work and what isn't. We can tell, well in advance, what's going to work and what isn't both in terms of the technical approach and the management process. Agree? If that is the case how do we convert that intuition into something that can work in the real world? Is certification the answer? Specialization? How do we recognize excellence?

hga 13y ago
Respect, I'd say. But e.g. how many times have you told a superior something like "This won't work because of math" and then been simply ignored? Until, of course, the system/project goes down in flames. We need stature that can get around Pournelle's Iron Law of Bureaucracy: (https://en.wikipedia.org/wiki/Jerry_Pournelle#Iron_Law_of_Bureaucracy https://en.wikipedia.org/wiki/Jerry_Pournelle#Iron_Law_of_Bu...): "In any bureaucracy, the people devoted to the benefit of the bureaucracy itself always get in control and those dedicated to the goals the bureaucracy is supposed to accomplish have less and less influence, and sometimes are eliminated entirely." And this amplified restatement: "...in any bureaucratic organization there will be two kinds of people: those who work to further the actual goals of the organization, and those who work for the organization itself. Examples in education would be teachers who work and sacrifice to teach children, vs. union representatives who work to protect any teacher including the most incompetent. The Iron Law states that in all cases, the second type of person will always gain control of the organization, and will always write the rules under which the organization functions." Lawyers frequently don't get that. Doctors? Not so sure anymore, the same masters of the universe have been revising the way they have to do medicine (e.g. the Obamacare foretaste in the stimulus bill requiring "meaningful use" of Electronic Medical Records). Scratch that, Obama's utter contempt for doctors was strongly on display while he was barnstorming the nation, e.g.: "Right now, doctors a lot of times are forced to make decisions based on the fee payment schedule that’s out there. So if they’re looking and you come in and you’ve got a bad sore throat or your child has a bad sore throat or has repeated sore throats, the doctor may look at the reimbursement system and say to himself, 'You know what? I make a lot more money if I take this kid’s tonsils out.'" Or what about the conceit that a generic MBA can manage anything? MIT considered this the #1 problem for it to address in the '80s.
phreanix 13y ago
While recognizing the completely different context, I'd approach it like organized sports management/coaching. There you have disparate members with similar skillsets but different roles that as a whole contribute to one thing: winning. Trust, respect, belief in each other's abilities, and most of all, pushing HARD to accomplish a shared goal and vision. You have a captain who plays, a coach who is trusted completely, and different roles that are recognized as indispensable yet won't work without the others playing their part. Of course not everyone wants to be pushed this hard, wants to be part of something like this, and is paid enough to take the obvious abuse. It's just something nice to fantasize about.
- jarrett 13y ago
  Exactly. These types of social attributes are necessary for a software project to succeed. The problem, of course, is that you can't devise a system which will reliably organize an arbitrary group of people* into the kind of effective team you describe. * As an example of an "arbitrary group of people," consider the set of contracted engineers, contracted managers, government employees, and insurance company personnel that had to work together on healthcare.gov. These are people who were not previously on a team together, and who cannot be expected to be of a uniformly high quality.
  - phreanix 13y ago
    What if product managers were trained to be more like sports coaches? Motivation, the right game plan, and working hand in hand with other products managers? Doesn't an organization like NASA work somewhat the same way? Different teams tackling different parts of a project and ending up with a rover on Mars?
jarrett 13y ago
> We can tell, well in advance, what's going to work and what isn't both in terms of the technical approach and the management process. Agree? Yes, those of with experience can usually spot this stuff early on. But that doesn't mean we're in any position to do anything about it. Most often, software projects come pre-populated with people and institutional cultures. We don't get to pick the people and design the cultures from the ground up. At least not when we're contracting. > If that is the case how do we convert that intuition into something that can work in the real world? If you're building a startup that sells a product, then you hire good people and foster a healthy company culture. You're not beholden to any one outside entity, so you're not forced to import any such entity's preexisting pathologies. If you're contracting? I think you just have to accept that projects will involve destructive people and cultures at times. Sometimes they'll cause projects to fail. In that case, the best you can hope to do is to protect yourself and your reputation.