I'm a junior developer who just got out of college. I knew the software industry isn't as mature as some other industries, but I kinda thought as a whole we were moving towards a more professionnal, more robust, less amateur industry.
This guy, if I heard correctly, participated in writing the Agile manifesto, which is basically software's 10 commandements written by the Agile gods. In this talk, he basically says :
"Yea actually we were kinda wrong, you shouldn't listen to anyone telling you to do anything, just run free in the jungle and you'll be fine."
So after all those years of trying to find a solution to how to do software correctly, this is his answer? Why would you say something like that?
How do you teach people then? Where can i learn how to do my job correctly? The 4 steps he give cannot be taken seriously...can you imagine medical students being taught "yea just try something and see what happens, hopefully your patient doesn't die and you'll learn something for the next patient."
Welcome to software development, where no one really knows what they are doing, the methodologies don't matter and everyone is wrong! Software is still a mix of art and science, there are a lot of ways to get to the right answer, and it is often very arbitrary and unbounded by physical processes. It might never settle, it might be like all the different methods authors use to write books -- strange rituals and personal patterns... there is no "right" way to author a novel -- might end up being the same with software. The end product is what you will be judged by...
> How do you teach people then?
You can't really, teach to the best of your ability and try to send students out with an ability to learn. It is MORE harmful to PRETEND you know what is going on than to openly admit you don't and are attempting to learn. False knowledge is worse than real confusion.
> Where can i learn how to do my job correctly?
In this field, it is a young and crazy field, maybe you will be the one who pioneers a way to actually do things more consistently... maybe you will just serve up another nonsense silver bullet.
> can you imagine medical students being taught "yea just try something and see what happens, hopefully your patient doesn't die and you'll learn something for the next patient."
Doctors kill patients all the time via mistakes, it is actually one of the leading causes of death in the western world... the half-life of medical knowledge tends to be less than a decade, so a decade out of school, a lot of what they know is wrong, or worse... actively harmful. We turn doctors into gods because it COMFORTS US, not because it has any connection to reality.
it is not a mix of arts and science, it is akin to middle ages styles manufacture. re-inventing the wheel, left and right, hundreds of years away from real engineering. even questionable if something like the freemasons exists yet.
Agile came about somewhat as a reaction to huge processes like waterfall, RUP, etc. that were espoused by many books, conferences, etc. at the time as the best practice and 'right' way to build software. The point being made here is that the same thing is happening to agile now, a cargo cult mentality has set in that software needs to be 'agile' and agile is just buying the right certifications, reading the right books, going to the right conferences, etc. and high quality software will pop out on time at the end of your release. The reality is it's just not that easy to build software, there is no magic book, agile or otherwise, that you can blindly follow and expect good results.
> Where can i learn how to do my job correctly?
That is a really heavy question to answer. I could try give an opinion but I've only been developing software for 10 years. Maybe in another 20 or 30 years I'll have something good to tell you. The fact is you just need to build things for many years and see what succeeds, what fails, and what you can learn from each success and failure.
I have been developing software for almost 30 years now.
Not everything was bad about waterfall, RUP, UML, Booch and related methods.
As not everything is good about every agile variant out there.
The secret, if any, is trying to find a good mix.
Which is very difficult given the constraints in team member skills, what the sales team promises to the customer, what the customer is willing to pay for, and what the managers what to ear and sell to the customers.
Specially when most companies treat developers as replaceable cogs.
Yup. Treat devs like cogs, treat software creation life factory work, then complain about how hard it is to find talent and execute on big projects.
Software is creative work, treat your team like a band. Maybe if you're lucky you can find a replacement for the bass player if he quits, but realistically when your team changes the way you get work done and the kind of work you'll get done will change too.
Your last two sentences really stood out. I don't have nearly as much experience as you do but I've seen the curious cycle of how software becomes so much more than just a process from engineers. Sales, customers, managers, and engineers all seem to influence the software even when they are not supposed to (sales guy who promises the world but realizes we can't deliver or engineer who builds the world but realizes they can't sell).
Developers are treated like robots. Mentally taxing labor like software development is not viewed in the same professional light as lawyers or doctors. The lowest cost seems to prevail and managers and business owners are always on the look out for reducing their overhead cost. Even the most generous and good hearted ex-engineer turned CEO has to view the engineers as a cost overhead. This is why unless a business has monopoly, it cannot invest in engineers, it is constantly looking for a turnover to maintain the low overhead.
The last part really sickens me and especially when people cry why is it so hard to find developers? It's hard when you aren't willing to pay the true cost.
You have to understand that some people make a good amount of money (5 figures or more) speaking at conferences like this. As a result, there's a cottage industry of people trying to declare the "death of {sacred cow}" or "the end of {foundation of the field} as we know it". These are controversial and can result in speaking invitations. Obviously Dave Thomas is a little different, but he's still human. Note the silly pandering to the crowd - he's done this many times and knows how to work an audience.
Now, that said, Agile is fairly new as software engineering goes. It isn't that young of a field.. waterfall put man on the moon, after all. Agile particularly speaks to how one can remain somewhat stable while optimizing for velocity, and is particularly well suited for the type of businesses that have dominated the last 10-15 years: self hosted consumer applications or SaaS. The key to choosing a process is to understand what you are trying to optimize for and what sort of release process your project requires. Agile, for example, might not be the best solution for gamma knife firmware or embedded systems in cars. To give him the benefit of the doubt, perhaps he's reached the age of reflection and trying to emphasize that everyone should step back and consider their goals, and reevaluate their strategies in light of those goals. [edit: and understand a lot of people are lazy and/or risk-averse, and would prefer to think that there is a magic best practice, that if applied hard enough, will work for everything]
I think you might be laboring under some misapprehensions here. Are you aware who Dave Thomas truly is and his relation to "agile"? He's one of the co-signers of the original "agile manifesto". "Agile"is his baby as much as anyone's. And he's here to say that it's being misused and abused. He's not against agility, he's saying that what passes under the "agile" moniker today has very little to do with the original conception.
I was aware of that ("Obviously Dave Thomas is a little different"), and I first read the manifesto a long time ago. I've also used ThoughWork's Mingle, and he's accepted speaking money from one of the absolute worst offenders of get-in-your-way, process-over-progress APM crapware that exists.
I watched the whole video, and I'm not impressed. Same old 'no true Scotsmen' crap that is epidemic to Agile. Yes, in almost 15 years, we are all still failing Agile instead of the other way around. Only now, it's gotten so bad it needs a new name. What he should realize that he doesn't like is complexity. If you have more than a thousand developers working together across multiple related product lines with various marketing, sales, and development dependencies then the 12 original principles and $2 will get you a bottle of soda. He shouldn't be mocking Agile in the Enterprise, he should be trying to figure out what is wrong/missing in Agile that causes it to become so pathological at scale.
As we learned with the Apollo Guidance Computer [0] and Shuttle computer systems development [1], the methodologies were not strictly waterfall. I'd like to do some more research in historical engineering techniques. I am not convinced that waterfall has had a much sway as the industry makes out.
The four steps Dave gives in the video are the observations of someone practiced at distilling heuristics. Experts often speak very few words with very few specifics, for a simple reason. The words they use are weighted with all the meaning of all the things that led to them. For someone with much less experience to discern meaning from them, that person must constantly be examining their own work as they do it, thinking about how it might connect with or diverge from those words.
That's generalization for you, though. It says more, less clearly.
Regarding the Agile Manifesto, he's not said they were wrong, Dave's saying that the main principles of the manifesto are being ignored.
From his blog post:
[quote]
Let’s look again at the four values:
- Individuals and Interactions over Processes and Tools
- Working Software over Comprehensive Documentation
- Customer Collaboration over Contract Negotiation, and
- Responding to Change over Following a Plan
The phrases on the left represent an ideal—given the choice between left and right, those who develop software with agility will favor the left.
Now look at the consultants and vendors who say they’ll get you started with “Agile.” Ask yourself where they are positioned on the left-right axis. My guess is that you’ll find them process and tool heavy, with many suggested work products (consultant-speak for documents to keep managers happy) and considerably more planning than the contents of a whiteboard and some sticky notes.
[/quote]
Dave then goes on to give his heuristic as a replacement for all the consultant BS that emphasizes the very things that are supposed to be less important.
He's really saying pay attention to the requirements, check your progress toward them frequently, and every-so-often, check that they're really still the requirements. As for code structure, technology selection and so on, he as much as came out and said to work with an architect or a master developer to help make those choices correctly.
He was again correct when he said that all of software development practice boiled down to making things that were easier to change over the long run. So when other factors don't rule it out, choose in favor of flexibility.
there are a lot of shops out there that develop and deliver great, working software on a rapid schedule. succesful saas shops come to mind - and even Microsoft has picked up massive steam in that regard.
the really awesome, productive dev teams are too busy to publish talks and whitepapers about their methods - they're 100% tasked with shipping. think about that anytime you see talks and conferences, etc. the best engineers in any industry work in silence.
it's the blow hards and wannabees that end up on stage or writing manifestos :)
I've worked with a bunch of development teams as a product manager and founder over the last decade or so. Whenever the team has come together with the rest of the company and collaborated to come up with a process that works for both them and the business, things have gone pretty smoothly, even though the processes themselves have varied widely from place to place. Whenever any party - developers, executives, product management - has tried to force a methodology without full discussion and buy-in from all parties, it's been a complete disaster.
Because of this, I believe 'doing your job correctly' varies considerably from place to place, depending on the different people you happen to be doing your job with. Learning a specific development methodology is much less important than communicating and working with others to come up with a development methodology well-tailored to the context.
I think with embedded systems that has no physical constraint can be mutable and I think this is why software can get so complicated to put a simple process through. Rather it seems like a collection of developer experiences and practices that are mutually beneficial to the stability of their jobs, if a developer's experience and views negatively impacts their stability or enjoyability of their development job, it is incorrect by whoever is paid the most. Rather when software fail, it's actually because the social dynamics have failed in that environment.
I believe the best place is to work your job, and have the right amount of introspection :)
But what helped me the most with this "how to do software corectly" question, was to realize, that there is many different kinds of software.
If I would attempt an analogy, our industry reminds me of carpentry.
And as a carpenter you might approach differently if working alone, or with coleagues, if renovating or building a house on a green field, if building a garden bike-shed, or working on a river-dam :-)
Meaning there will never be specific 10 commandments applicable for everything.
Sometimes agile will fit your team (heck, my most productive week was spent PAIR PROGRAMMING :P )
I think it depends on what you're working on. If the software is completely designed and the desired outcomes known from the beginning then up front planning and processes are probably helpful. But this is such a small percentage of actual software. In 99% of cases the business itself doesn't know exactly what it wants (even though it might initially think it does) and a lot of the seemingly chaotic ways of approaching software engineering are really just reflecting that.
Learn to do your job correctly by experimenting. Read other people's code. Write other people's code. Learn by doing. Learn by failing.
One of the things that I believe is incredibly important is a feedback cycle. Do a thing. See if it worked. Reflect on what you learned doing that thing.
And most importantly, ignore any feedback that starts with "You're doing it wrong." But listen carefully to anyone who says "Here's how I'd do it."
This is how I learned software development. I wrote crappy things and placed them before people I respected. And these people gave me exactly what I just explained..
You're a junior developer - there are so many people willing to help you out and learn, if you ask.
A flippant or cynical answer might be that you'll still want to know and follow "agile" anyway, if only because 1) it matters from an employment perspective, and 2) so many organizations are just now adopting it.
But you're asking about learning, and from my perspective anyone who is willing to ask incisive questions has the wherewithal to continuously improve and ultimately succeed in his/her field.
Software is still an incredibly immature field. It's been getting better, much better, but it still has an incredibly long way to go. It's worth pointing out that software is also an incredibly difficult field.
In many industries it's impossible to find employees who are master programmers and understand the business domain. So some additional leadership is necessary.
An industry where only the masters can execute reliably is an immature industry. The fact that it's so difficult to convince average software devs/managers/companies of the best way to develop is another indication of immaturity.
I'm a junior developer who just got out of college. I knew the software industry isn't as mature as some other industries, but I kinda thought as a whole we were moving towards a more professionnal, more robust, less amateur industry.
This guy, if I heard correctly, participated in writing the Agile manifesto, which is basically software's 10 commandements written by the Agile gods. In this talk, he basically says : "Yea actually we were kinda wrong, you shouldn't listen to anyone telling you to do anything, just run free in the jungle and you'll be fine."
So after all those years of trying to find a solution to how to do software correctly, this is his answer? Why would you say something like that?
How do you teach people then? Where can i learn how to do my job correctly? The 4 steps he give cannot be taken seriously...can you imagine medical students being taught "yea just try something and see what happens, hopefully your patient doesn't die and you'll learn something for the next patient."