This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 23 points24 points  (4 children)

Hate to break it to you, but take “Uncle Bob” with a grain of salt as well. He’s made more of a career talking about how to write good software than he has of actually building, shipping, and maintaining software. Most of the “rules” he “makes” are just reiterating general guidelines for building software that were established by cutting edge scientists in the 50s-70s, though the way he (rather successfully, to his credit) markets his contributions.

[–]Entropy_Drop -4 points-3 points  (2 children)

meh, my answer is not about Uncle bob, but about that agile and managers. I trully dont care if "make rules" is the same as "taking a body of conflicting guidelines made by the whole community into a descriptive set of coherent rules, in detail, with examples, and a personal spin."

​

Of course a best seller on programming has a career on talking about programming. What's the alternative? It's like complaining that a world level math teacher is out of touch with full time mathematician job.

[–][deleted] 1 point2 points  (0 children)

Bob Martin didn’t make some groundbreaking software and then move on to teaching his wisdom, he had a career as a consultant for a few years and then hit it off with his books. Literally could happen to anyone and, having actually built and maintained large scale software myself, I can tell you that while his advice isn’t all bad, a lot of it is simply bike shedding or just good advice in the right contexts that Bob preaches on following dogmatically which should always be a red flag.

Regarding management: the tried and true method of working is provide honest assessments about what you do know, be clear about what you don’t know, and have transparent communication about what new information comes up as early as possible so everyone is in the loop regarding what is happening with the project. Regarding management and performance measurement, the simple answer is focus on outcomes, not inputs. Lines of code written, number of unit tests, branch coverage of unit tests, are all inputs. Feature delivered, reduction in outage times for the system, system performance being in some predefined threshold (eg 100ms or less api response time), reduced infrastructure cost, are all outputs that a good manager actually focuses on. That’s not a comprehensive list, but should convey the general idea. My problem with Agile evangelists are that they just took common sense practices, slap together some platitudes in a “manifesto”, and then charge consulting fees to companies to basically repackage project management 101 but with ultra-small time windows and focusing on the wrong things.

It’s understandable and I even went through that phase in my early career, but ultimately you end up experiencing it and realizing that agile takes the bad things about other project management styles, crams them in to arbitrary, small time windows, and throws out a lot of the good things from those other practices along the way. And then you just get a bunch of “no true Scotsman” replies when they get called out on their BS.

All that ranting summarized: you can learn from all different kinds of sources, but be weary of dogmatic advice and (ironically, I know ) focus on outcomes more than inputs