Heh, classic response. Whenever your project fails, your coach tells you it's your fault because you didn't do real Agile. Same with OOP, whenever your code inevitably becomes a tangled mess of classes, you will have all sorts of gurus making metric shit tons of money from books and consulting telling you you didn't do real OOP.
Guys, please, can you just admit there is no recipe for success (rhetorical question, of course you can't, that's where you money comes from, maybe you even believe your own bullshit)? There is no real Agile and OOP and other crap that I forget, they're just buzzwords that, when applied long or hard enough, produce shit. If you had kept you project to an absolute minimal level of Agile and OOP, it would probably still be alive and kicking. But you didn't, because you jumped on the bandwagon, you used religiously whatever was popular.
Agile, done right ...
Yeah, heard that a thousand times before. Sadly, younger developers fall for this all the time, so shit grows exponentially. I'm aware my opinion has always been in minority but whatever.
I have done it right. It worked well for me. I've been on happy teams that produced good code: high quality, high test coverage, good for users. We did technical work that I'm still proud of. And we believe that was true because we paid careful attention to how we were working and improved it continuously, using a lot of techniques from the Agile movement.
I grant that there's no one right way. There are many, and they depend on circumstances. I certainly grant that there are an ocean of idiots selling bullshit. But you're throwing the baby out with the bathwater.
There are better and worse ways to make software. Teams can reflect on how they work and get better over time. Those teams can recognize patterns, and other teams can benefit from learning about those patterns and trying them out in their environment. And that's how things like Extreme Programming came to be: teams experimenting and sharing what they'd learned with other people who wanted to get better. That was exactly what the early Agile movement was.
Piss all over that if you like. But you'll be missing out.
I've been on teams that have agile it right. Some have failed and some succeeded. I've been on teams that practiced chaos driven development. Some of those succeeded and some of those failed.
My opinion (not "theory") is that teams are not interchangeable. Companies are not interchangeable. Industries are not interchangeable. What works for one team may not work for another. What works for a 10 man startup is not going to work for a 200,000 person company. What works for a web app company is not going to work for a video game company. But, Agile and Scrum have been shoehorned into every tech company I can see no matter how inappropriate it may be for that particular team, company or industry.
Your question prompted me to consider a thought experiment. Let's assume that management techniques are completely ineffective and the deciding factor in whether a project ships and is successful or not lies entirely with the programmers and designers. Now, let's take it one step further and say that most management techniques actually reduce the likelihood a product ships and is successful. Do you think that would stop management from trying to exert control over something that is completely out of their control? Do you think that would stop management from thinking that their input is actually making things better when in fact their input is making things worse? Managers are ultimately responsible for producing results, but they have no direct control over those results. Most humans, when put in that situation, will try to do something, anything, to make it feel like they have some control over the situation. Even if it makes that situation worse. Finally,what if what I have described above isn't actually a thought exercise, but a fairly good description of what is happening in the real world right now. Would we be able to tell?
Managers in large companies will push anything in a top-down fashion. Before, they pushed waterfall. Now, they are pushing something they call Agile. (They do, I don't.) In 5 years, the consultant-managerial complex will push something else. I agree that is bad. [1]
But the top-down thing is explicitly not what the Agile movement was about. As the early Extreme Programming community would say, "By-the-book Extreme Programming is where we suggest you start, but it's definitely not where you should end up." The notion was always that teams would take time every iteration to look at how they were working and improve it to match local conditions.
So the way to think about it isn't in terms of manager interventions. It's in terms of those non-interchangeable teams experimenting and then sharing what they've learned with other teams. Teams will learn things! Some of those things will apply to other teams. A few will apply widely. And that's exactly how the good Agile teams work today. They may start from some recommended set of practices, just like any novice does while learning things. But they are supposed to evolve from there to match local talent and conditions.
Not so weird at all. Codebase and process don't matter to a customer, all they see and judge is the end product. Sometimes even the end product doesn't matter, as the likes of Google can put much more money into ads and marketing than you.
There might be a correlation between what people do and how the project goes if you're NASA or BMW. But for 99% of the software world, nobody cares if you have the most hacky codebase ever as long as it does what it's supposed to do and doesn't have too many bugs.
The customers don't care how the programmers work as long as they get good results. But the people on the team should really care. And if they do, they should a) experiment, and b) exchange ideas with other teams.
Well, I don't know if that's fair: most of the places I've worked at that claim to use "Agile" methods were participating in a kind of Cargo Cult. In other words, they thought they were jumping on the popular bandwagon, but if you examine what they did and compare it to what the Agile et. al. stuff was supposed to be, it's not that.
I don't know how one does real OOP, but I know what C++ OOP looks like when used long enough.
1) Architecture. Architecture trumps everything. Even though "favor composition over inheritance" has been repeated for a very long time, some people just didn't get the memo, and you'll encounter mind-boggling inheritance hierarchies (sometimes even template inheritance, to make it fun) with more levels than circles of hell.
2) Class-itis. Everything must be a class, and free-floating functions are seen as coming straight from The call of Cthulhu. Most people are more concerned with the way the class will look and fit in the existing architecture than if the desired functionality is achieved.
3) Code reuse mania. If you write the same line of code in two different places, some people's palms start sweating. More than two identical lines in two different places and you'll have people screaming to move the coded to another place and share it, irrespective of whether it is beneficial or not.
4) God objects. When people just can't take it anymore and simply jam yet another object in the God object. Yes, I know a lot of people from the cult of OOP will tell you this is an anti-pattern, and I agree, but it happens. And when they unravel the God object, an even bigger mess emerges most of the time.
I don't know, I'm probably forgetting a dozen other manifestations of OOP.
You know what "you're not doing real Agile/OOP" sounds like? "You're not doing real communism". And we never will.
Comments
Heh, classic response. Whenever your project fails, your coach tells you it's your fault because you didn't do real Agile. Same with OOP, whenever your code inevitably becomes a tangled mess of classes, you will have all sorts of gurus making metric shit tons of money from books and consulting telling you you didn't do real OOP.
Guys, please, can you just admit there is no recipe for success (rhetorical question, of course you can't, that's where you money comes from, maybe you even believe your own bullshit)? There is no real Agile and OOP and other crap that I forget, they're just buzzwords that, when applied long or hard enough, produce shit. If you had kept you project to an absolute minimal level of Agile and OOP, it would probably still be alive and kicking. But you didn't, because you jumped on the bandwagon, you used religiously whatever was popular.
Yeah, heard that a thousand times before. Sadly, younger developers fall for this all the time, so shit grows exponentially. I'm aware my opinion has always been in minority but whatever.
I have done it right. It worked well for me. I've been on happy teams that produced good code: high quality, high test coverage, good for users. We did technical work that I'm still proud of. And we believe that was true because we paid careful attention to how we were working and improved it continuously, using a lot of techniques from the Agile movement.
I grant that there's no one right way. There are many, and they depend on circumstances. I certainly grant that there are an ocean of idiots selling bullshit. But you're throwing the baby out with the bathwater.
There are better and worse ways to make software. Teams can reflect on how they work and get better over time. Those teams can recognize patterns, and other teams can benefit from learning about those patterns and trying them out in their environment. And that's how things like Extreme Programming came to be: teams experimenting and sharing what they'd learned with other people who wanted to get better. That was exactly what the early Agile movement was.
Piss all over that if you like. But you'll be missing out.
I've been on teams that have agile it right. Some have failed and some succeeded. I've been on teams that practiced chaos driven development. Some of those succeeded and some of those failed.
Did you drink any kool-aid on the way in?
Your theory is that software is totally random? There's no correlation between what people do and how the project goes?
That is a really weird theory for a programmer to have about anything, let alone what he's chosen to spent 80,000 hours doing.
My opinion (not "theory") is that teams are not interchangeable. Companies are not interchangeable. Industries are not interchangeable. What works for one team may not work for another. What works for a 10 man startup is not going to work for a 200,000 person company. What works for a web app company is not going to work for a video game company. But, Agile and Scrum have been shoehorned into every tech company I can see no matter how inappropriate it may be for that particular team, company or industry.
Your question prompted me to consider a thought experiment. Let's assume that management techniques are completely ineffective and the deciding factor in whether a project ships and is successful or not lies entirely with the programmers and designers. Now, let's take it one step further and say that most management techniques actually reduce the likelihood a product ships and is successful. Do you think that would stop management from trying to exert control over something that is completely out of their control? Do you think that would stop management from thinking that their input is actually making things better when in fact their input is making things worse? Managers are ultimately responsible for producing results, but they have no direct control over those results. Most humans, when put in that situation, will try to do something, anything, to make it feel like they have some control over the situation. Even if it makes that situation worse. Finally,what if what I have described above isn't actually a thought exercise, but a fairly good description of what is happening in the real world right now. Would we be able to tell?
Food for thought.
Managers in large companies will push anything in a top-down fashion. Before, they pushed waterfall. Now, they are pushing something they call Agile. (They do, I don't.) In 5 years, the consultant-managerial complex will push something else. I agree that is bad. [1]
But the top-down thing is explicitly not what the Agile movement was about. As the early Extreme Programming community would say, "By-the-book Extreme Programming is where we suggest you start, but it's definitely not where you should end up." The notion was always that teams would take time every iteration to look at how they were working and improve it to match local conditions.
That was definitely true even at the beginning; "self-organizing teams" was one of the principles from 2001: http://agilemanifesto.org/principles.html
So the way to think about it isn't in terms of manager interventions. It's in terms of those non-interchangeable teams experimenting and then sharing what they've learned with other teams. Teams will learn things! Some of those things will apply to other teams. A few will apply widely. And that's exactly how the good Agile teams work today. They may start from some recommended set of practices, just like any novice does while learning things. But they are supposed to evolve from there to match local talent and conditions.
[1] I've written more about that here: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
Not so weird at all. Codebase and process don't matter to a customer, all they see and judge is the end product. Sometimes even the end product doesn't matter, as the likes of Google can put much more money into ads and marketing than you.
There might be a correlation between what people do and how the project goes if you're NASA or BMW. But for 99% of the software world, nobody cares if you have the most hacky codebase ever as long as it does what it's supposed to do and doesn't have too many bugs.
The customers don't care how the programmers work as long as they get good results. But the people on the team should really care. And if they do, they should a) experiment, and b) exchange ideas with other teams.
Pretty sure that's a big part of the problem Agile and other approaches to software development try to address.
I totally agree (well I do think OOP is less of a snake oil than Agile).
There is absolutely nothing wrong with the Agile Manifesto, but this can not be said of the industry that was created on the back of it.
Well, I don't know if that's fair: most of the places I've worked at that claim to use "Agile" methods were participating in a kind of Cargo Cult. In other words, they thought they were jumping on the popular bandwagon, but if you examine what they did and compare it to what the Agile et. al. stuff was supposed to be, it's not that.
So what you're saying is that they didn't do real Agile, right?
Well no. If you make a pancake and pour chocolate sauce on it you can call it "cake" but it's not cake.
No true Scotsman would have misunderstood me.
How does one do "real OOP"? Or "real FP"?
I don't know how one does real OOP, but I know what C++ OOP looks like when used long enough.
1) Architecture. Architecture trumps everything. Even though "favor composition over inheritance" has been repeated for a very long time, some people just didn't get the memo, and you'll encounter mind-boggling inheritance hierarchies (sometimes even template inheritance, to make it fun) with more levels than circles of hell.
2) Class-itis. Everything must be a class, and free-floating functions are seen as coming straight from The call of Cthulhu. Most people are more concerned with the way the class will look and fit in the existing architecture than if the desired functionality is achieved.
3) Code reuse mania. If you write the same line of code in two different places, some people's palms start sweating. More than two identical lines in two different places and you'll have people screaming to move the coded to another place and share it, irrespective of whether it is beneficial or not.
4) God objects. When people just can't take it anymore and simply jam yet another object in the God object. Yes, I know a lot of people from the cult of OOP will tell you this is an anti-pattern, and I agree, but it happens. And when they unravel the God object, an even bigger mess emerges most of the time.
I don't know, I'm probably forgetting a dozen other manifestations of OOP.
You know what "you're not doing real Agile/OOP" sounds like? "You're not doing real communism". And we never will.
For "real OOP," use a lot of names from the "Design Patterns" book, reference the SOLID principles, and sketch out the design in UML.