Alarming News: I like Morgan Freeberg. A lot.
American Digest: And I like this from "The Blog That Nobody Reads", because it is -- mostly -- about me. What can I say? I'm on an ego trip today. It won't last.
Anti-Idiotarian Rottweiler: We were following a trackback and thinking "hmmm... this is a bloody excellent post!", and then we realized that it was just part III of, well, three...Damn. I wish I'd written those.
Anti-Idiotarian Rottweiler: ...I just remembered that I found a new blog a short while ago, House of Eratosthenes, that I really like. I like his common sense approach and his curiosity when it comes to why people believe what they believe rather than just what they believe.
Brutally Honest: Morgan Freeberg is brilliant.
Dr. Melissa Clouthier: Morgan Freeberg at House of Eratosthenes (pftthats a mouthful) honors big boned women in skimpy clothing. The picture there is priceless--keep scrolling down.
Exile in Portales: Via Gerard: Morgan Freeberg, a guy with a lot to say. And he speaks The Truth...and it's fascinating stuff. Worth a read, or three. Or six.
Just Muttering: Two nice pieces at House of Eratosthenes, one about a perhaps unintended effect of the Enron mess, and one on the Gore-y environ-movie.
Mein Blogovault: Make "the Blog that No One Reads" one of your daily reads.
The Virginian: I know this post will offend some people, but the author makes some good points.
Poetic Justice: Cletus! Ah gots a laiv one fer yew...
Someone was asking for my critique against Vox’s critique against AGILE.
He dutifully listed the twelve principles:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
…taking particular umbrage against #2, “Welcome changing requirements, even late in development.”
Bullshit. That’s fine in the early stages. In the middle to late stages, this is what is known as “mission creep”.
Quite right. Although, for whatever misgivings I may share about #2, I like #8. Then again, #8 #9 and some others would benefit from more specifics. And then there’s this…
“Business people and developers must work together”…”working software is the primary measure”…”best architectures, requirements and designs emerge from self-organizing teams”…these strike me as heading off in the wrong direction. No, I’m not saying non-working software is the primary measure of progress. I’m concerned about the definition of the requirements, and the apparent contradiction. If the best requirements come from a self-organizing team, why is management involved at all?
AGILE seems to start off with an unwarranted — or, at least, largely unearned — fondness for the process of committee thinking. The manifesto reads as:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
I see no great harm in “individuals and interactions,” but I have seen the harm done, firsthand, through an excessive cultural reliance on these. It doesn’t come about until the very minimum quantity of chat-session required is something way, way up there, to the point that the cubicle-farm starts to become a noisy sort of a place, and nobody bothers to ask: How come that is? Why so much verbiage necessary to convey a single thought? How come all these meetings necessary to accomplish trivial tasks which should have, by now, become routine for us?
When people don’t ask such questions — disasters do follow. And they’re predictable. The methods become inconsistent, as the details morph and change with the mood of the committee or subcommittee, on the day the meeting or cubicle-chat-session happened to have been held. Worse, it often emerges that you can’t use the software that was designed by committee, until you first form a committee of your own and flesh out these (verbal) details about how to run it. “Working software over comprehensive documentation,” it says.
I know the rebuttal already; it’s made of iron. “Nevermind what you may know about software development Morgan K. Freeberg, or your experience or whatever you may have accomplished — the committee said something different from what you said, and you’re not on the committee.” That’s the rebuttal committees always use. Meanwhile, it would not be inaccurate to say AGILE has become something of a pejorative term, would it? Perhaps not among the managers, or the recruiters.
But when the successful job candidate is told “This work environment operates according to AGILE,” what is the first thought? “Oh good, finally we’re going to get something done that works”? Or something else, more like…”Well this is not going to be my best work between womb & tomb, but fuck it I’ve got bills.”
Prager, whom I mentioned a short time ago, is fond of saying “I’d rather have clarity than agreement.” AGILE seems, to me, to have turned this upside-down, seems to be practicing a sort of negative-image, Bizarro-world version of it. They’d rather go consensus-driven and have the agreement, or a sense of it at least.
Leave a Reply
You must be logged in to post a comment.
This sounds like an awful work environment, dude. You have my complete sympathy. I know nothing about software development, but I know committees, and AGILE looks like busywork for the Tracy Flicks.
The purpose for which the committee is formed doesn’t matter. From the first moment of the first meeting, the committee’s primary goal is: Continuing the existence of the committee. This is one of those things that seems incandescently obvious, yet the vast majority of society is oblivious to it. The purpose of the committee is the committee. The union’s main function is the union. The party’s only goal is the party. It’s a feature, not a bug.
Good managers (which, let it be noted, I was not) understand this, and give the committee’s Tracy Flicks (and there’s always at least one) enough committee-propagating make-work to keep them occupied while the foot soldiers get on with the real work. I’m guessing that good software development managers assign their Tracys to be “AGILE compliance officers” to keep them out of the way of the real work as long as possible. Bad managers, I assume, think AGILE is really a thing that’s designed to help production.
- Severian | 05/29/2015 @ 07:32I just had this conversation with several programmers the other day. I believe the fault lies entirely with people who insist on the bureaucracy and not the agility. For example, SCRUM has a whole bunch of negative terms to insult people who don’t ‘toe the line,’ (Scrumbutt, Scrumbum). The original point is lost…a focus on a malleable time-frame to produce the best, most error-free product within a reasonable development time.
- P_Ang | 05/29/2015 @ 08:18Most agile development cycles I’ve been involved in have lost any and all form of “agility.” None are planned in advance with room for the inevitable fatal errors that will ALWAYS appear towards the end of the sprint. Speaking of sprint, nearly every produce nowadays seems to be a sprint from beginning to end. From a Sr. Software Tester point of view I’ve never actually seen or dealt with a number 2, that would probably require a completely new POA/scrum-cycle where I work.
As far as number 8, to me that’s just a PC (re: liberal) buzz-word. There are plenty of liberal devs in the city of Eugene where I work (meaning everyone but me.) Everyone talks about “sustainable development” and “sustainable living”, but I have yet to see any of them stop driving their cars, stop printing pages of documentation, or say “why yes, guess those Repubs are right and the battery pack in my Prius IS worse than a few gallons of gas.”
Sounds like a bunch of talentless cunts scarfing down a bucket of blather and gargling it in order to justify their phony-baloney jobs.
Run out of there as fast as possible and then toss in gasoline bombs until everything inside is charred beyond recognition.
- vanderleun | 05/29/2015 @ 09:23Ah, now Agile Development will solve everything. I wrote the following in my thesis about a buzzword that was popular at the time: “As with most computer buzzwords, there’s less here than meets the eye.”
Which is not to say there’s no substance to Agile Development, just less than advertised. I’ve seen big projects sink because they took the exact opposite approach as “Agile,” holding endless meetings to hammer out requirements, design, etc, but never actually getting down to programming. They used up most of their time with endless meetings, documentation and other trivia, and had nothing to show in the end. Epic failure.
My limited understanding of Agile Development is that it’s a reaction to the kind of disaster described above: get going soon, try to make the software as flexible as possible and always have something that “works.” At the beginning, you can just whip up a basic interface with all the major stuff behind it stubbed out. Even this can help clarify differences in what the customer and the software team envisions as the final product. But if I had to choose a buzzword for this, I think I’d go with Rapid Prototyping.
So some people took a few good insights–get started quickly and try to always have something that “works”; don’t waste too much time up front on meetings; design software to be flexible to accommodate changes in requirements; maintain contact with the customer to ensure that the developing product does not diverge too far from what the customer actually needs–packaged them as a development process, gave it a cool-sounding name and tried to flesh out the whole thing with a set of principles.
Unfortunately, some of the AGILE principles sound like platitudes and others sound like pure BS. For example:
4. Business people and developers must work together daily throughout the project.
This is a sure recipe for wasting all your time in meetings and never getting any work done. Who are these “Business people” anyway, your management or your customers? Either way, “daily” is too often.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Rubbish. You can try to tolerate such things by anticipating the changes and making the software flexible enough to deal with late changes without too much turmoil. But these things should not be “welcome.” Customers should be apprised early and often what the software will do, and be encouraged to request changes as early as possible.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Sometimes, but not always. “Face-to-face” meetings often meander and waste loads of time. Email is often much better because it forces people to focus their questions and ideas in a more concise way. Meetings usually inspire at least one or two filibusters from tangential individuals trying to demonstrate their relevance to the project.
7. Working software is the primary measure of progress.
Meh. I think it’s a good idea to always have something that works at some level. But this idea can easily go too far, with people wasting lots of time packaging minor upgrades into something deliverable.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
Not that I’ve ever seen. IMHO, the best “architectures” and “designs” happen when someone really good is in charge, a wise, benevolent leader who has the authority and respect to stop the bickering and make the tough decisions. You need a person with a lot of experience, excellent judgment and a clear vision of what the final product is and how it should work. What you don’t need is rule-by-committee, “self-organized” or otherwise.
The following are just empty platitudes that express an ideal but offer no advice as to how to achieve said ideal:
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
———–
One more point. The AGILE “manifesto” (a bad sign) says it values Working software over comprehensive documentation.
In light of the fact that the de facto standard is rapidly approaching no documentation at all, this really annoys me. We don’t need additional rationalizations for even less software documentation.
- Gary | 05/31/2015 @ 16:13Interesting topic. I’ve been debating for a day or two if I should write a response merely because there’s so much to respond to. It appears quite a few people who are not very familiar with Agile now making comments and criticisms on how it’s run.
For full disclosure, I’m a certified Scrum Master, and ran SW dev scrums for about 4 years doing Agile. Is Agile for every project? No. There are some fundamental areas where it breaks down, which I’ll get to later. The sheer volume of erroneous statements about how it’s done is stunning. If these are based on someone’s current Agile work then they’re doing a really crappy adaptation of Agile.
I’ll start out with some simple observations, then go through some specific comments and my reaction to them. First off, Agile in NOT consensus based. Anything but. If everything is ‘done by committee’, YOU’RE DOING IT WRONG. Agile has four basic players. The development team (execution), the stakeholders (who made the ‘ask’ for a feature or capability and have a vested interest in the outcome), the Scrum Master (who herds the cats) and the Product Owner. I’ll focus on the Product Owner for a minute.
The Product Owner is just that – they own the outcome. They and they ALONE make all decisions on how it gets done. From stacking priorities, to ruling on disagreements on implementation, the Product Owner is along the lines of Highlanders “There can be only one!” type mantra. Again, if you’re doing it by committee, you’re doing it wrong. The Product Owner decides the priorities for each activity.
The Scrum Master basically ensures that everyone is able to execute, and if they’re somehow ‘blocked’ from working, it’s the Scrum Master’s full time job to unblock the problem.
So in essence, there’s no committee – they can argue amongst themselves for days, but the Product Owner makes a command decision and the Scrum Master enforces that decision.
Now onto some of the comments.
First, the comment about late breaking requirements (which some have attributed as ‘Mission Creep’.) I’ll have to call BS on those comments as well. I fully understand scope creep and avoid it like the plague, but the whole point of AGILE is to be, well, agile. If you’re developing a new product and something in the market gives you a signal that what you have isn’t going to work, or the market has moved to something else, or basically any negative signal from the market – it makes little sense to stand on your model of ‘we can’t change anything, the definition is locked.’ You can explain that to your stakeholders, your shareholders or the unemployment line. This is why the Product Owner (there can be only one!) is so critical, to avoid scope creep instead of consensus driven design.
As for the working SW over documentation, you need both. We merely set up analysis tools such as Coverity, NCover, Bullseye, to collect metrics from the build systems, and part of the definition can (and should) be to have a certain percentage of your lines of code be documented. If the percentage is not met, the code doesn’t get ‘accepted’.
Lastly, on the topic of ‘talking daily to your stakeholders’ that’s got some ring of truth to it – but you don’t need to ‘force’ a daily conversation – basically the stakeholder makes the ‘ask’ of what they want the code to do. If the developer doesn’t confirm what ‘done’ looks like, you’ll have plenty of “That’s not what I wanted” conversations at the end of the sprint, and you’ll end up with developers naturally going to the stakeholders to confirm they’re doing what’s initially envisioned.
Now, onto the bad stuff of scrum. Scrum works well with small scale and simple architectural projects, but fails to scale up in a few areas. One is where you need a large scale architectural foundation, or you need to create Low Level code to talk to HW, or API’s to other components, These things take typically more than a few weeks to develop, and they fail to provide ‘working software’ since they’re skeletal frameworks. The second big problem is when Agile is being run by the SW team but other parts of the org are still on Waterfall models. Conversations will take place like ‘What do you mean you can’t tell me when you’re going to implement feature x? I need to schedule a third party lab to validate this and it will be touted as part of our marketing campaign, and you can’t tell me in the next 9 months when you’re going to have this done?”
Teams I’ve run were initially dragged kicking and screaming, but once you established a strong and consistent process, the groups would warm up to it. The first few sprints are very painful, as too many people are trying to figure out what ‘done’ looks like and once a good process cadence for that has been established it’s far more smooth to get stuff estimated and implemented.
- Wamphyr | 06/01/2015 @ 12:18I think people who are strongly pro-Agile or anti-Agile are guilty of mistaking the outcome for the process. In my experience, good craftsmen produce good products. Bad craftsmen produce bad products.
I worked in an Agile shop for a while and absolutely hated it, but it wasn’t necessarily because of the Agile processes. It was because the people were variously incompetent, demoralized, visionless or actively evil. Process changes can’t fix that.
It was a company that had a great idea thirteen years prior, and had spent the next 12 years fucking it up. All the good people that understood the original code base and the original vision were gone, in many cases driven out by people far less able but politically savvier. It languished under a leadership that changed course every time the wind shifted, trying to chase new fads with the same underlying product, making superficial product renames and redesigns, always trying to fit the same round peg into an ever-more-ridiculous variety of non-round holes, and focusing so much time on those superficial changes and product re-alignments that it neglected to evolve the base code, until one day they were left without a product, without anyone who understood the code, or who had the vision to produce a working product that anyone wanted to buy.
I had started as a PS Engineer, but during my tenure became ad hoc chief architect and developer for several of the company’s major products — sometimes being pressured into the role against my own advice. I am not naive about my limitations. I am a moderately clever utility, glue and API programmer at best. I tinker. Any company that has me doing major development work is a company that has badly lost its way. I probably have the raw talent to be a really excellent core developer, but that isn’t what I’ve spent my career doing and it wasn’t appropriate to be trying to learn that role on the job. I even told them this as best as I could without actually having them fire me. But the reasons I ended up in the role were that I:
A) as a services engineer could produce independently outside of the moribund engineering team/culture (which seemed to just wile away it’s time tinkering around with useless tweaks to shit nobody was ever going to buy)
B) had some idea what the customers wanted (unlike our CTO’s staff, which was constantly building neato patent prototypes, but never generated squat that was marketable).
C) was willing to let them have enough rope to hang themselves. I literally told them on one project, “No. This is too big a deal. It’s a major product offering. Engineering needs to own it. It will be very bad if it is owned by one guy in his home office.” Just do it anyway, they said. And, oh, we need a working prototype to put in front of the customer — a major government agency — in two months, and we already kind of told them it exists and is in development. So I did it. And I’m proud of what I produced, given my own limitations and the time limitations involved. It was a slick piece of design for a major big data project. I presented it to the customer. They liked it. It was supposed to be transitioned to engineering to turn the prototype into a real product. Eleven months later they contact me, panicked. Major customer milestone a month away. Engineering has produced exactly nothing. Can I please head a team to turn my prototype into a releasable product? Fuck. I did it. Got the help of three competent teammates and a project manager. Completely replaced the back end indexing and storage architecture and the front-end web interface in the process. Customer was happy. Customer accepted. The product filled a major, major need and we were at the right time to take advantage of it. Engineering and Product Management completely lost interest in it once the milestone for the one customer was met. A few big names have since dominated the lucrative market.
My remaining tenure was just sullen, apathetic, time-serving. Hey, it was easy money. I got to work from home all the way across the country from the dysfunctional corporate HQ and, since we were bleeding customers and not making new sales, there wasn’t much for a PS engineer to do except play around with new ideas. One of those ideas was my death knell — again they latched onto something another PS engineer and I had prototyped as an entertaining exercise, and decided it was going to be the new flagship product. But I made the mistake of letting myself get transferred to engineering during a corporate shakeup (things were really bad by this point) “temporarily” to finish and transition this project, was shuffled through three different managers within a few months, saw the entire executive team except for one be replaced, and ended up under a megalomaniac asshole who I hated and who hated me because I wouldn’t pretend he was wearing any clothes — he was a fraud and a con artist, his ideas sucked and what he was proposing was guaranteed to doom the company. I was laid off. He was gone within a year after entirely destroying my project and the entire new product development team. The company itself was dead within a year after that.
It was the people. Not the processes.
- cloudbuster | 06/01/2015 @ 21:11I think people who are strongly pro-Agile or anti-Agile are guilty of mistaking the outcome for the process.
Very well put. And to be fair about it, I’m absolutely positive Agile gets a bum rap for a whole lot of stories like this that are partially or wholly outside of Agile.
Thing is, I can only go by what is written in the Agile materials, such as the 12 points of the mission statement, the 4 values, et al; and personal experience. When I get called on the carpet to defend myself on the “charge” that my code doesn’t look like the code that would’ve been written to do the same thing by 5 other guys, or 10, or 20 — yet I’m able to respond with technically sound and precise responses to why I designed the code that way, what problems these design decisions are intended to overcome down the road, why those problems would be (otherwise) likely, and how the design decisions are essentially costless, and when there’s no substantive rebuttal to these statements but I’m still in the wrong — then I know I’m dealing with a bureaucracy, with all of the evils attached to that word. That is proof that, for whatever reason, the environment is one in which the way to survive is to look around, see what everybody else is doing, and copy it. This is not just a detriment against technology, it is its opposite.
You cannot engage in any activity we’re supposed to be describing with the word “technology” when you are prohibited from doing what it entails: Think outside the box, find new ways to achieve equal or superior results, in less time, using fewer resources, or making it cheaper to maintain down the road. And, nevermind whether “we” are already doing it or not. Any process that blocks this, or merely gets in the way of it, becomes a problem before it has any chance of becoming a solution.
You’ve given us a lot of meat to chew here Wamphyr, but this paragraph in particular deserves inspection:
As for the working SW over documentation, you need both. We merely set up analysis tools such as Coverity, NCover, Bullseye, to collect metrics from the build systems, and part of the definition can (and should) be to have a certain percentage of your lines of code be documented. If the percentage is not met, the code doesn’t get ‘accepted’.
I’m inclined to think you’ve been simply managing software development projects competently and then crediting the process brand for the results; here, you are contradicting the Agile statement of values. And this defense misses the point. The phrase “working software over comprehensive documentation” manifests a whole big busy patchwork of misunderstandings and non-understandings. It is a strawman statement: Is there someone, somewhere, standing on a soapbox intoning “comprehensive documentation is more important than software that works”?
“Working software” is just not a good goal. An improperly normalized database that creates all sorts of maintenance time-bombs that will detonate a good deal down the road — works. A file system that should have fault tolerance built into it, but doesn’t — works. Serial-processing programming implemented in a scenario in which parallel-processing was needed — works. “Comprehensive documentation” can have several meanings too, and internal documentation is not what I had in mind. Some of the most influential and beneficial code I’ve written on any project, is the code I wrote when the pressure was on and the timeframe was extremely tight. I managed to do it without creating maintenance problems, but no, it wouldn’t pass the percentage test. If someone’s ass is really on the line and my fix is the only thing that can save them, and it absolutely positively has to be working by morning, then it’s going to have to be good code that I understand front to back, that won’t have to be tweaked over & over again. The internal docs will probably suffer. After all, if they’re there, how do you know they’re correct?
And that last question there is what separates the documentation that is really attached to the ultimate success of a project, from documentation that is not. Documentation in general is not to be trusted if there isn’t some way to validate it, ideally some automated way to validate it. Lacking that, the way humans tend to behave is to get it done now now now, and then after it’s working, task some poor schmuck to write the documentation while the maestro who wrote it — his time is at a premium and he’s spread pretty thin — moves on to the next plum project. If the schmuck is good at being the documentation guy, when he runs into an ambiguity or a question he’ll stop everything until the maestro can come back and clear things up fully and precisely. That usually doesn’t happen. This is not a problem Agile causes, I understand it would be much more accurate to say I’m causing it in the above scenario in which my code saves the day but opts for low-maintenance over high-documentation. But I’d be a lot less frustrated with Agile if it proposed specific solutions to this. They’re not complicated, after all.
Part of the reason Agile gets such a bum rap, ironically, is it raises so many red flags among those who really do take responsibility to make sure things work. There’s a certain mindset to making things work that often gets the practitioner in trouble with others who do not practice the same mindset. And I’m very far from the first to notice that after that, when you ask yourself that question “Well perhaps their mindset, while being different, can also culminate in making things work, I wonder how they practice it and take responsibility for making things work?” — you don’t have to follow the trail very long to discover they’re not doing this. The team working environment is packed full of opportunities for the impractical types, those who do not specialize in making things work (I really hesitate to call them “incompetent” because they’re often not) to hide behind the accomplishments of others; it’s full of temptations to start doing this. To those who’ve seen this happen, it’s already been demonstrated how the Agile literature throws up a lot of indicators that its implementation could make this all more likely.
And after we have a few case studies, it does seem like this is the case. Just pick a five-year stretch from the pre-Agile world, like between 1981 and 1986. Does the industry we’ve seen since 2001 have big, bold innovations to offer, to compare with all the game-changing ideas we saw back then? Has it been generally doing a superior job of tracking today’s limitations on what the customer can do, and turning these limitations into tomorrow’s triumph, tomorrow’s exciting new expanded suite of capabilities? I’d be hard-pressed to answer in the affirmative, even before we factor in the head-count in these huge sprawling campuses with big two- to five-story buildings filled with engineers. Once you do that it’s clear the tech industry has a problem it didn’t have back then, even if it does manage to get something done here & there.
- mkfreeberg | 06/02/2015 @ 04:25