Writing a good technical book is hard work with uncertain rewards, and the very real possibilities for loss for those involved, so how do some publishers seem to be able to have so many titles? Is the model reliant on a few bestsellers to keep the rest going? Would love to know how it really works...
In the meantime, I still love these books, still buy them (I have this one), and hope they don't go away.
Well, it stands to reason that the majority of the titles don't return their costs, like in the publishing and music worlds. It's the few blockbusters that effectively subsidize everybody else, though no one seems to be able to identify them in advance. I don't have specific knowledge of the technical publishing industry, to be sure.
I have just bought a "Learning GROWS" book from the Pragmatic Programmer online store, and have hired a consultant to educate (inculcate?) the team on the new methodology.
We even are using one of the new open source libraries that tests and enforces the process, it is called 'poison ivy' - it hurts, like all good software engineering processes do!
Edit: do the downvoters disagree? We don't think there will be books, courses, tools for this new methodology?
We're not humor impaired, there's just a higher bar. Otherwise it becomes like every other internet forum ever: dominated by one-liner meme-based reply-chains that drown out the real conversation.
If there's a solution to this problem, I don't know what it is. Trying to replace an underfunded monoculture with severely underfunded diverse implementations may not even work and may actually reduce security.
The article starts with the current note - agile as it was preached was never actually achieved, and most companies and practioners are doing it "wrong" (for varying degrees of wrong).
But then it goes downhill with proposing yet another model that will people will try to adopt verbatim, and again, experience failure to implement.
Software is hard, people are hard, so the idea should be to have as little process as possible. Most of it exists as arse-covering material anyway.
What really killed agile fwiw, where the consultants, going from development team to team, peddling false hope, snake oil, and tedious time zapping process that people learnt to game rather than actually deliver.
Of course, someone will pop up saying agile is awesome, they love the daily scrums, the project is fab, the sky is blue, etc. Question is: can it be better?
In my experience, the people who say agile is awesome would likely say any process is awesome. Because the true awesomeness they are experiencing comes from being on a good team. After wading through years and years of agile, even working for a major agile tool maker for a while, I've come to the conclusion what process you choose isn't that important. Get a good, passionate, driven team together, and they'll figure out how to kick ass. Without that ingredient, nothing else matters.
> In my experience, the people who say agile is awesome would likely say any process is awesome. In my experience, the people who say agile is awesome would likely say any process is awesome.
Agile is awesome because its not a process, but a set of principles which addresses exactly the problem that context-blind adoption of processes creates that makes good teams mediocre and bad teams worse.
Most of the processes sold in a context-blind manner as "Agile" suck, but they are a recreation of exactly what the Agile Manifesto was a reaction against.
That's true in theory but rarely in reality. The reality is Agile is a process, often a rigid one. I find good teams resist bad process, and mold process to their needs. For teams that do that, whether they are "agile" or not largely becomes irrelevant. I will admit I have found through lots of experience that the "agile movement" is silly at best, so I'm perhaps a bit biased.
> The reality is Agile is a process, often a rigid one.
No, the reality is that Agile is not a process, though there are a number of different processes sold as "Agile". (The most common now seems to be Scrum as defined in the Scrum guide and a number of variants on it; for a while XP was somewhat prominent as well.)
> find good teams resist bad process, and mold process to their needs. For teams that do that, whether they are "agile" or not largely becomes irrelevant.
Teams that do that are Agile: that's exactly and all of what the Agile Manifesto says.
> I will admit I have found through lots of experience that the "agile movement" is silly at best, so I'm perhaps a bit biased.
The thing is the "Agile movement" consists of two separate and opposed forces: one (and the origin of "Agile") is people promoting exactly the behavior you mention characterizes good teams, the second (and the thing you seem to have a problem with) is people using the name that the first group came up with to promote exactly what the first group is reacting against -- rigid, context-blind adoption of externally-developed process (largely as a reaction against the threat posed by the good ideas of the first to the second groups pre-existing business of selling rigid, context-blind processes.)
But the reality is almost everyone who "does agile" has rigidly adopted scrum, xp, kanban, etc. That is the reality most of us face. Just because a group got together 14 years ago and created a hypothetical scenario that essentially no one follows doesn't seem all that relevant to me.
And at the same time, the fact that a good, adaptive team that figures out what works for them is what you and the original group deem to be "agile" simply reinforces that the whole thing is ridiculous to me. Why did we need a name and a manifesto for that?
The end reality is we have an entire industry built around that stupid manifesto. Sure, it's not what they wanted, but it's what we all got. We would have been better off without it.
> And at the same time, the fact that a good, adaptive team that figures out what works for them is what you and the original group deem to be "agile" simply reinforces that the whole thing is ridiculous to me. Why did we need a name and a manifesto for that?
Because while there are lots of people who won't understand that with an explanation, and some people who get it intuitively and don't need an explanation even with all the noise from people selling one true way, there's also lots of people in the middle who benefit from people selling there one-size fits all approaches not being the only voice in the marketplace of ideas.
> The end reality is we have an entire industry built around that stupid manifesto
No, we have an industry that existed long before the manifesto built around selling canned, context-blind process and jumping on anything even mildly popular to sell it that, predictably, when the manifesto calling for exactly the opposite of what that industry sold became popular, jumped on that to sell exactly the same thing they'd always been selling.
> We would have been better off without it.
No, I think that there are lots of people who have learned something from the Agile Manifesto, writings actually addressing how to implement its principles that don't amount to context-blind process, and related movements (Lean software development, etc.) and applied the ideas to improve teams and make software in a better way.
Most developers -- before and after the manifesto -- work in places where management is operated with shallow knowledge and poor respect for their staff and buying whatever consultants are selling in terms of process, sure, but that's not the fault of the Agile Manifesto
You do make some good points. Perhaps my frustration at the Agile Manifesto is misplaced. I'd still argue that the canned processes that emerged due to the creation of the Agile manifesto are amongst the worst ones available, but for sure I have no real proof for that other than my own personal experience.
^ this. Agile is only a set of principles set out to help write flexible software. It in no way made the actual writing of software, the gathering of requirements, the effort of design, easier; it simply gave us a process to follow that could potentially help avoid tedious re-writes. At the end of the day it's up to the people to put in the effort to make good software
Agile does not give us a process, because Agile is not a process (it is a set of principles that can be applied to evaluate processes in the context of a particular team, but its 100% not a process.)
Software is hard, people are hard, so the idea should be to have as little process as possible. Most of it exists as arse-covering material anyway.
People are soft and squishy. Too much rigid process pevents taking advantage of that squishiness. A complete lack of process will result in those squishy humans just producing a gooey puddle.
For every piece of process:
* what problem does it solve?
* what side-effects does it have?
* are the side-effects good or bad, and how much so?
* are there alternative solutions with better side-effects?
> agile as it was preached was never actually achieved, and most companies and practioners are doing it "wrong" (for varying degrees of wrong).
You know Scientology, Amway and most other cult-like phenomena say the same thing: It's never the "system" that's wrong, if it's not working it means you're doing something wrong. You missed something, you didn't try it hard enough, you didn't do it like X, Y, Z.
Two problems for me:
[1] What bothers me is that people writing the manifesto admit that they are wrong, and they start the whole thing in the same way all over again. All over again!
[2] I have also seen practitioners and consultants that never did a single-frickin-project in their short lifetime, but preaching success. That's how you get wrong - theory and practice are often 2 very different things. And when the shit hits the fan, people say "you are doing the agile wrong". Alright.. teach me master, and admit how wrong you were 14 years ago.
p.s. Apologies for the rant.
What really "killed" Agile are two things: the absence of good guidance on how to apply Agile principles as opposed to canned methodologies, and the fact that most people don't have the skill to apply the principles without guidance.
There is some good guidance it there, but you have to get outside of the Agile "brand" for most of it, since much of the work on evaluating methods and other aspects of higher-level metamethodology that fits in with Agile principles is associated with "Lean" rather than "Agile".
Software is hard, people are hard, so the idea should be to have as little process as possible. Most of it exists as arse-covering material anyway.
This depends on the environment. Working for a consulting company, where time spent on the project is billed to a customer and the project has a fixed budget, Process is needed to make sure the project is estimated and executed properly, and the arse-covering helps to guarantee that you get paid when the customer makes changes mid-way through that increase the project costs.
It would be fantastic to work on projects with open-ended budgets and collaboration with customers to figure out what the software should be as it's being developed, but in the real world I don't think that is often possible. It's not just consultant/client relationships; even in big companies where IT is given a budget from upper management you have the same situation. Management won't approve a budget without a detailed description of the deliverable, and IT can't exceed the budget or deliver something other than what was promised.
Waterfall, for all of its drawbacks, handles this situation well. The problem is that no one wants to pay for all of the paperwork and management overhead it requires to function properly.
Someone pointed this out to me long ago, and I've yet to see anything that disagrees with it:
Every time you see someone succeeding at Scrum, it's because they're also doing most of XP.
Maybe we need to go back to our roots. I know that several elements of XP have only recently clicked for me and I feel foolish for having taken so long (but nearly everybody I know is still struggling with those aspects too, so I'm in great company). And I was exposed to XP in '99, which means it took me 15 years.
> Most of it exists as arse-covering material anyway.
I think bean counter types throughout the business world truly believe there must be some secret fairy dust you can use to transform mid/low competency people into high competency people, and dysfunctional teams into highly functional teams. It's about wages. It's essentially a delusion that you can take cheap, socially lower status people and substitute for more expensive people as long as you have the right fairy dust.
The mentality works to a degree for certain disciplines. It works with McDonalds employees. You can apply management theory and systems to an infantry brigade and get good results from lower grade enlisted men.
The model simply does not map over to the "creative" professions and crafts. But managerial types are often averse to the idea that software engineering is a proper profession on par with their own, not commodity, and must command high pay. They prefer to keep seeking the right fairy dust.
The faux crowdrage these days is depressing. I suppose it is the modern version of the crowd gathering to watch a stoning, hanging or other public spectacle from the middle ages.
It really is, and I do think most of the time it's the crowd being manipulated into a rage. When you see in the news someone demanding an apology from someone else or from a corporation, online shaming and crowd morality is what makes these demands effective.
Someone made the point yesterday, a good point I think, that the Go and Rust crowd would be better served by showing positive blogs and examples (i.e. Here is how to build a small app) rather than ones that serve only to whine and complain and bemoan C/C++.
You don't win friends by criticism.
As a seasoned C++ programmer, I am interested in Go and Rust, but not because a few ardent posters told me I have to.
> that the Go and Rust crowd would be better served by showing positive blogs and examples
Are we reading the same Hacker News? The community practically fellates itself over these two languages with any project/blog in the title containing Go or Rust shooting up to the front page.
If you simply search "Rust" on HN search, the first 4 pages all contain positive blogs and examples, with 200+ points and 100+ comments, and the first negative one on page 4 being "Author of “Unix in Rust” Abandons Rust in Favour of Nim"[1].
If you aren't seeing the "positive" stuff I'd have to say its because you don't want to see them. Even more strange you say that the Go crowd just whines and complains about C/C++ when the community has given up trying to be a replacement for C++ years ago and has embraced the "I need compiled Python" crowd.[2]
Each of these have been at the top of HN on the day of publication, they've been relatively hard to miss. None of them bemoan C++. In fact, they cite C++ as inspiration.
I refuse to consider it a test, thank you, because I'd end up failing it. I was genuinely curious when I asked the grandparent poster where he was seeing people whine about C++, because I just haven't seen them. And I'm a moderator of /r/rust, so I like to think that I see every Rust-related blog post that springs forth from the bowels of the internet.
In the course of researching this comment I ranked the top-rated posts on the subreddit over the past month, and not only did I not find any that were bashing C++, but the fourth-highest-rated post is actually a criticism of Rust by a Boost developer: https://plus.google.com/+nialldouglas/posts/AXFJRSM8u2t
So I ask again: who is going around unjustly denouncing C++ in Rust's name? I ask because I want to stop them!
In the meantime, I still love these books, still buy them (I have this one), and hope they don't go away.