[dboreham]

I like this book as a means to present the ways people describe how software is developed. However, as I read I'm itching to annotate it with notes on "what really happens". I've worked in this business for a few decades now, in various locations and various sizes of companies, including a few that are household names. I have NEVER seen software built on the ground in exactly the ways one sees documented (documented anywhere, not just in this book).

A couple of things I don't see mentioned (apologies if they're in there, I haven't read every word):

1. Process does (and should) vary tremendously depending on factors including the organization size, organization maturity, market maturity, experience level of the people involved, budget, etc. The book seems to suggest that there's a one-process-to-rule-them-all.

2. Often there are significant unknowns about a project : unknown technologies, unknown market needs, unknown requirements. Being able to accommodate the unknowns, which can mean not expending effort trying to know something unknowable, is important. The book I think gives an impression of quite confident smooth progress toward project completion that I personally have never observed.

Also: The value of Rubber Chickens is not mentioned...

[dankohn1]

It's taking you so long to fix bugs because you're doing it wrong! You need to use a duck, not a chicken. Even Wikipedia agrees: https://en.wikipedia.org/wiki/Rubber_duck_debugging

[wnoise]

Wikipedia is wrong. You need a stuffed teddy bear. Everyone benefits by consulting the wisdom of the bugbear.

[dkersten]

I just ask my cats for help. They look at me funny as if I'm crazy and then I try again with renewed vigour.

[infogulch]

This thread is bikeshedding about rubber duck debugging. Any more developer memes we can pile on?

[newjersey]

Not so much for debugging but the cat is often an Oracle. I remember Sometimes when I started reading through a section in the documentation (probably the dfdd), the cat would come take a nap on the document (yes I printed it, yes I know if it has changed since because organizational inertia). I took it as a sign to stop.

It helps to take a break sometimes.

[robotresearcher]

Bear lives on a bookshelf at eye-level. Explain bugs to the bear, keeping eye contact, and you will be enlightened. Bear also does architecture design consulting.

[mixmastamyk]

Yes, it does mention these things. Perhaps not early enough? The "really happens"/disasters are towards the end of Part I, and there are few project cartoons giving hints.

There's so much to cover, I started out with the formal stuff first. It seemed like a good order, but perhaps it is a bit off-putting at the beginning of the book.

[Ramiuz]

I'll argue that, as a book for students, it works better in the way of formality and then some informality/real examples/exceptions. it's necessary a base to compare ideas before explaining differences in a model. It becomes easier to understand, and therefore, study.

[p4wnc6]

Why are "really happens" and "disasters" associated together? I assume by "really happens" you mean the ways reality departs from what's in the book -- but when process varies over time, adapts to different personnel, business circumstances, tech capabilities, etc., instead of remaining rigid, like ironically rigid adherence to Agile despite variation in the above-mentioned characteristics, that is what leads to disaster.

I'd see strict adherence to any sort of one-size-fits-all recipe for workflow management as a greater sign of disaster than healthy compromise, accommodation for individual working styles, and respect for the human need for autonomy and self-direction.

[dboreham]

Right. I'm not talking about bad outcomes in the grandparent. Far from it. I'm more interested in the fact that project participants will for example fabricate a fake manifestation of a process (fake[1] project plans, fake task lists, fake design documents) for the benefit of external folks asking them to "follow process". Meanwhile they get on with building the product "The Way we Actually Do it[2]", successfully. This phenomenon can be confusing because outsiders might conclude that the process led to success when in fact it was the presence of people who knew how to build software successfully that led to success and the perception of process was a mirage.

[1] By fake I don't mean fraudulent but rather something that has as its only purpose to meet the needs of the process enforcement. For example a requirements document that nobody reads after it has been written, or a design document written before the manner in which the problem will be solved is well understood (and is therefore never read). Project plans that somehow turn out to have underestimated effort by 3X...

[2] TWWADI(tm)

[p4wnc6]

> This phenomenon can be confusing because outsiders might conclude that the process led to success when in fact it was the presence of people who knew how to build software successfully that led to success and the perception of process was a mirage.

See, I think this is actually intentional. The "process" itself exists to give management a surface area of metrics they can datamine for their own political needs, more or less independent from the actual success of the project or team.

I liken it to creating Dutch books. With each layer of management you go up, the pressure to create Dutch books that provide you with blame insurance and protect your bonus -- crucially, diversified across all different business outcomes -- gets more intense, and the people who pull this off get compensated hugely and can often make leaps into C-level executive teams.

Lower level managers might not consciously know about this, and on one hand may actually think there's some truly redeeming reason to care about the frivolous, irrelevant metrics (e.g. Agile burndown). But the higher up you go, the more directly and unabashedly people openly function honestly -- they know the metrics are bullshit; they know that you know that they know the metrics are bullshit ... they don't care ... they are just getting on with their own business of political games to diversify away bonus risk and arrange for metrics-based blame stories for scapegoats.

It's not that it's confusing where the credit lies. It's that people know the credit does not lie with the formalized process at all but that they need that excuse in order to politically manage how they get their share of the credit.

Unfortunately, I think despite the OP's strong efforts to present the topic in a useful, taxonomic way, the sad thing is that treating formalized process with this degree of veneration at all simply perpetuates the political system that needs inexperienced developers to roll over and play dead to the system.

[ScottBurson]

This phenomenon can be confusing because outsiders might conclude that the process led to success when in fact it was the presence of people who knew how to build software successfully that led to success and the perception of process was a mirage.

My first "favorite" comment!

[mixmastamyk]

Very interesting, but it feels you are going several "derivatives" into the issues, when the book is aimed at the first semester, haha.

[mixmastamyk]

Yes, was just an off the cuff remark, not completely accurate.

The book does take the time to provide alternates at many points. It should explain "what really happens," but it first does that for waterfall, then spiral, and agile, etc. If you are reading the waterfall part, for example, your "really happens" is going to be different if you are currently working under Agile. To avoid info-overload I've tried not to explain everything at once, but of course that means valid points have to wait until later.

[p4wnc6]

+1 million for pointing out that process/workflow can and should vary according to many factors.

Watching an organization stress in vain to assert a one-size-fits-all approach, such as letter-of-the-law Agile, is unpleasant, especially once the political games set in. Even worse to be on the team and actively shunted from being able to do your job because of all the boilerplate, parochial adherence to cargo-cult process.

[mixmastamyk]

It does mention choosing the "right tool/process for the job" about five times, but I will take the idea to first class status under the intro chapter.

[p4wnc6]

I think the point is that people should not start life by constraining their choice to some menu "Agile or Waterfall or ..." -- once you do that you're already dead.

Instead, do whatever works organically for your situation. Don't say to do whichever established, brand-name process (or, worse, some shiny new thing) -- that automatically casts the decision as if it has to be limited to a choice between a few specific (and all bad) options.

To be clear, there's a difference between saying "do whatever works organically based on the human properties of your team and your situation" vs. "do whichever one of these 2 or 3 big box things you can maybe lobby for."

It's like saying, "Here's a first course on how democracy works ... you've got Republicans and Democrats so pick one of them that suits you better." It teaches you to think that democracy (analogue to the ideal of a successful dev process) is intrinsically delimited into certain categories like Republic, Democrat, etc. (analogue to Agile, Waterfall, ...).

I think it's better that young impressionable minds are more open and not made to think in such constrained, delimited ways right from the start (even if real life will beat it into them later on).

[mixmastamyk]

Hmm, doing "whatever works" is fine when you know what the "what" is. The early chapters talk about requirements, design, quality, etc, which is what I'd believe the student needs to understand. Before the discussion happened here, the first mention of waterfall or agile was in chapter 7.

[p4wnc6]

Sometimes you need to spec requirements out carefully. Other times you need to dive in, prototype, make mistakes, and revise. Sometimes you need to research design tradeoffs for a month before beginning a single item of implementation, and absolutely none of that research can fit into anything like a "sprint" structure. Other times you need to neatly divide up a known or perpetual task into points-based subtasks for tracking, planning, and estimation.

All these things vary all the time. When I say "whatever works" what I mean is no one knows what will work for your team. No textbook will know that. It might consist of some composition of management patterns from some books, but often it will not, and you need to develop an eye for deviating from that. There is no recipe. There is no cluster of things that all the good companies had in common -- they all did (and still do) things very differently. Amazon treats people like shit and hammers on them -- and delivers good products. Google forsakes some income opportunities to selectively uphold their "don't be evil" mantra. Apple puts usability ahead of everything. Microsoft puts enterprise saleability ahead of everything.

All these different value systems, management systems, workflow monitoring processes, etc., etc., have places and times when they'll work. If you're stuck thinking in terms of rigid structures, you won't see it, and it truly can make a big difference.

In every job I've ever left from it has been because the process and experience of being managed in that role had led to burnout even after talking openly with managers about what wasn't working. I'm (perhaps foolishly) a very loyal guy. I'd love nothing more to stay at a company for a long time and get in a groove, even if I was leaving money on the table by doing so. But I can't seem to find any organization that values human-affirming management concepts over and above ritualistic adherence to bureaucratic process.

Anyway, I just see a lot of "the road to hell is paved with good intentions" in this. If you are not already familiar, you may enjoy reading Moral Mazes, because I think it's impossible to approach the task of software management without first approaching the generic task of human management and how it fits into bureaucratic machines.

[calferreira]

"In every job I've ever left from it has been because the process and experience of being managed in that role had led to burnout even after talking openly with managers about what wasn't working. I'm (perhaps foolishly) a very loyal guy. I'd love nothing more to stay at a company for a long time and get in a groove, even if I was leaving money on the table by doing so. But I can't seem to find any organization that values human-affirming management concepts over and above ritualistic adherence to bureaucratic process."

1000x this!!! I do exactly the same thing, for example i'm going to leave soon because the development process is so crippled that it just makes me want to cry. I tried to improve it and talk to management but nothing changed. I started to feel a void inside, and i realised that there was nothing i could except leave.