One Hacker Way Rational alternative of Agile - Erik Meijer

[@nandodixtorsion]

Erik Meijer is our Spartacus, is time to rise again the fucking Roman Agile Managers!

[@aworden]

Love, love, love this from Erik Meijer. So much of this resonates with me and you had be cracking up at the truth bombs here. I'd only add that a team can't be made of 100% Messi's (or Beckham's). If it was, it would be a field of one-man teams. My own truth-bomb to share as an engineering manager is that it's the manager's job to build and maintain a *team* that's high performing and is focused on delivering the right priorities. The team is more important than any individual developer. That means hiring the right combination of talent for a team, fixing or ousting the bad apples, and creating a (somewhat) level playing field that helps the team perform at their best and deliver the right stuff. It's not a democracy and it's not always fair, but it achieves results and constantly improves. Additionally, you can define and wish for all the right results, but only the journey will actually get you there. You have to focus on the day-to-day environment and activities of the team if you want to achieve objectives. This is where I've seen that OKRs are not sufficient and abused by bureaucrats much like agile has been.

[@edvardm4348]

While I loved the talk, I think theres' maybe one thing Erik didn't think of: he's by far in the .1% tiny tail in normal distribution curve, what it comes to cognitive abilities. Probably pretty much the same with colleagues he has worked with. I mean, if you eat parsers for breakfast and write programming languages for fun, you don't probably need much guidance/holding hands when working in any given company (though tech excellence doesn't automatically imply one has solid understanding in big picture what is important in any given moment). Thus my argument would be that id depends a lot on average level of professionalism your company has, though it's also affected a lot by general culture. Also, if you hire lots of people who expect people to tell them exactly what to do then sure, you need more processes.

[@ChrisAthanas]

Most people in tech likely don’t belong there due to the obvious immense reliance on cargo cult practices like agile

[@FrankZen]

This guy is radical! I love it!

[@bajatoma]

Not doing TDD, but saying that just pushing code in prod and roll back is the way to go is nonsense. Having test cases saves tone of time down the road, when you start modifying code. Run test cases, find what you broke, or not, fix, or move on...

[@foobargorch]

I don't think he's advocating to not write tests at all, but that test driven development is not enough and gives a false sense of security. TDD makes sense but it's not reliable enough on its own, and when people get all OCD about it, it's just an empty ceremony. A production environment will break well tested code eventually, it's just a matter of time, and I think even if you take his advice almost literally, it still often makes sense to employ TDD to fix those bugs.

[@a0flj0]

No serious practitioner of TDD will ever tell you that TDD is a panacea for bad code. The only thing that has a decent chance of getting you to some decently well working code is a healthy pyramid of tests. TDD just gives you the lower part of the pyramid with the smallest cost.

[@foobargorch]

it also has a nice bonus of restricting the search space of what to code to testable APIs =)

[@michaelw9852]

he is so right about wanting to be high all the time. like when i was teen learning c++ an actually making cool things in opengl, it was total flow moment. it was immersive, so much so that i felt video games were disgusting then, you know... industry and jobs happened. fuck agile.

[@marekbanaszkiewicz6338]

Excellent speech. It's good to see Erik in good shape again. Though criticism of TDD is something I can't agree with, in general the clue of this presentation is what I think developers feel in their hearts. Indeed we should write a code and not talk about it. Everyday stand up meetings and calls from managers saying "How are things going?" make me always nervous because I know it is complete waste of time, because finally "code always wins".

[@bool29]

Failing fast and recovering is better than wasting time upfront in preventing failure. You don't need TDD anyway if you are writing code in functional language since pure functions don't have side effects and goal of writing tests is to detect side effects. Even a good modular object oriented solution with clear interface will eliminate side effects so one doesn't need to write silly tests such as adding a user to the database and verify if the user is added by reading from a database. This isn't "agile". If one feels the strong need of writing tests, the number of tests should be minimal and restricted to cover important or core uses cases. Also how many companies do have crisp, quick and granular rollback strategy if something goes wrong? If there is a process in place to revert to old version of the component, module or a feature very quickly, you don't need TDD.

[@Simon-xi8tb]

The problem of TDD is that it's trying to take over DESIGN, you need to think and design first, then write an implementation and tweak it, once you are happy with it, then write test, or even better, let you programs write tests for you.

[@foobargorch]

IMHO TDD is actually a great way of doing exactly what advocates, as long as it isn't taken as dogma. It's just one way of thinking through what a piece of code should do, specifically in a way that prioritizes the usage of an API over its implementation. As they say, the dose makes the poison.

[@HermanWillems]

I wanna see you write code for Embedded devices in Hospitals. Oh darn, someone died... quick fix it. Oh another person died. Ohh it's ok. Fuck testing. :) It's ok it fails in production right? I hope you guys can answer this.

[@DuongNhatTan]

For critical systems, the way to go is to apply model checking rather than relying on testing

[@kanji_nakamoto]

Great talk, very inspiring! Had to re-watch this again! Punkbit supports you Erik Meijer! DIY attitude! Dooers do!

[@comarius100]

I work for 20y+ in IT, True Agile is crap crap crap crap, Scrum as well truly agree... I am old school, mission-statement, clear requirements, plan, wbs, rfc, and so on, classic PMP, and works allways.

[@a0flj0]

You can indeed be more productive refining requirements thoroughly before starting to code. Only, you will never be able to move as fast as modern development requires using traditional project management methods. This is not something brought about by nonsensical managers, it's brought about by competitive performance in the marketplace. This is the thing he apparently also doesn't understand - we need a methodology which does not necessarily provide the best quality, but which provides barely acceptable quality at the highest acceptable speed consuming the smallest amount of effort.

[@foobargorch]

While I agree with the general sentiment of cargo cult agile being abusive, most of the code I've seen in my life should have been deleted shortly after it was written. In my estimation, the software industry is dominated by half baked incoherent ideas written by people who have no idea of what they've set out to achieve, let alone how to achieve it. And once you put ideas in writing, especially if it's unexpressive as most programming languages, even more so if there isn't a very strong culture of merciless refactoring and collective code ownership, which is most likely the case given business priorities, deadlines, etc, chances are it will cloud your thinking, and end up being a liability in the long run. More formally, if you only do continuous improvement, the nearest attractor is likely to be a local maxima of some utility function, and chances are the utility function is defined implicitly in terms how the code/project is understood by the people working on it at the time they are working on it. I think this is good advice, but it must be applied responsibly, and I do believe that's his intent with all this hyperbolic language.

[@gavinschuette9826]

ask alan kay

[@Nisstyre56]

To be fair he didn't say anything about keeping the code after you write it.

[@greenspand]

But this has nothing to do with Agile. Agile doesn't check the quality of your code. You and others developers, and tests (hopefully not many but just the right amount), should do the quality part. AGILE in the way it degraded, is really, mostly used as a reporting/ control methodology.

[@TechYourChance]

Outstanding stuff! I kind of wonder whether Erik is consciously and on purpose playing the "tenth man" by making some (or all) of these statements. It looks like he truly attempted to play devil's advocate and criticize as much of today's generally accepted practices as was physically possible in 45 minutes.

[@a0um]

34:35 document on war offers great description of software

[@mhandle109]

Best career advice at 27:10. I wish they had taught that in college,

[@jrgalyen]

mst - rubbish advice. You develop yourself out of a job, yes. Pick up a new job and finish it well. Yes. Doing job after job is called a career. Doesn’t matter if it is the same company or across many companies. College is also becoming less and less important in comparison to abilities.

[@kishalayabhattacharjee9760]

The only person in the software industry to have guts to call out Agile. it is high time people come an speak the truth as to how agile has damaged the software industry and responsible for broken software architecture

[@dwylhq874]

26:53 every company has a cache. after 3 years you should eliminate yourself from the cache as you have stopped learning.

[@kevinleptons8818]

AGREED

[@adud6764]

Now that I think about it, I literally never used this "new windows menu" before.

[@demokraken]

Catholic church was not around for 2k years, they branched from the original church. That's why original is called Orthodox.

[@scriptoso]

Code always win🎉

[@tomamedro9232]

100% correct

[@stefanhoutzager]

Refreshing talk, a rant from the heart. For those interested here's a small other rant on TDD: dlinsin.blogspot.nl/2008/06/nothing-wrong-with-tdd-right.html TDD- what is this supposed to deliver again? Oh yeah, that's right, code quality.... "This code has been tested...." The problem is of course that even the most simple program has so many possible states that a computer the size of the universe composed of gates the size of atoms which in turn switch states at the speed of light couldn't compute all the possible states of that program so that you can say you've tested it. So what does TDD do? Why it tests the subset of data that the programmer determines, through experience and intuition, are likely to to cause trouble - corner cases, pathological input etc. And this is different from what programmers have always done ... how again? In know I should know the answer to this b/c TDD priests have been preaching for years now, but I just can't remember it. The fact is, TDD promises something undeliverable- throughly tested code. What it relies on is exactly what it denies the sufficiency of - a programmer's analytic understanding of the code and ability to understand, without testing, what a program will do. That understanding is just how the data that is unit tested is selected from the universe of data which could be selected. But as I said, this is just what programmers have always done. Like it or not, the best and ONLY reason programs work as expected is because there's an experienced developer sitting there who understands how it works. I know there's a level of management that hates to hear that, because it immediately implies a dependency upon individual developers. TDD found its most sympathetic hearing in the corner offices because it promises to increase the interchangeability of developers. A best interpretation is TDD attempts to capture best practices of good developers, and a more realistic interpretation is it churns out a deaf mockery of those practices and imposes a leaden, mechanical and pointless exercise of busy work and wasted time. TDD is a kind of false assurance or hand-holding for people who are afraid of their code base. At some point, corporations will learn that there IS a talent market worth paying a lot of money to participate in, but its not at the CEO level- it's at the level of the individual developer. Writing code is not flipping burgers and the interchangeable "labor" model that applies to McDonald's isn't going to fly in IT.

[@axelvanhooren6325]

As if everything revolve around developers ... And Agile is turning IT more than 50 years back ... It undermines credibility of IT. After Agile, who will still believe IT?

[@greenspand]

So true. Living the SAFE nightmare right now.

[@erionomeri007]

Just because there will be bugs in production it does not mean you don’t do your best attempt to test stuff, and what better way to gain speed than by automating the testing. Most of this talk is just emotional.

[@1videoshow]

Stand up?! We need a new "shut up method for managers"!

[@otmanighoulassen6177]

Amen to that

[@JKBockstael]

That wild prediction at 18:56 didn't age well

[@a0flj0]

Where's the empirical proof that hierarchical systems work? Armies are anthological examples of doing things in the most stupid way. Also, most wars are won on logistics (something the Chinese already knew four millennia ago, he fails to know it today), not by employing lots of heroes. Heroes are for show, not for efficient production.

[@elodens4]

Heirarchies are not all or nothing. While they can become corrupt and disregulated, sustainable heirarchies are based on competence. Simple empirical proof of this is that a 4 yr old is not doing your job because you are better at it than a 4 yr old. This is a heirarchy. Heroes are personifications of virtues and values that make up what it means to be competent +. It's not about the literal, it's about having idealised versions of who we could be that point us towards certain behaviours and away from other behaviours. The "hero" of logistics, the "hero" of martial combat, the "hero" of discipline, the "hero" of strategy etc. This is why polytheism was practiced by humans for the vast majority of known history. It's these 'heroic' behaviours that allow us to bear the burden of suffering e.g. the demands of life or work. For example, for the Romans, masters of logistics, this was partly embodied in the "roman way" of severitas, veritas, industria etc. "Moribus antiquis res stat Romana virisque." - "The Roman state stands on ancient customs and heroes".

[@kefsound]

@@elodens4 "sustainable heirarchies are based on competence". That's not hierarchy. That's influence based on competence.

[@elodens4]

@@kefsound "That's not an apple, it's a fruit that's red". ok bud

[@a0um]

37:49 creativity book

[@LoganVenter]

Windows 8.1 was the best tablet OS I've ever had.

[@amenostalgique]

Burnout over 9000

[@greenspand]

FP should be enough to have good code and viable projects.

[@kefsound]

"hardware people are not as smart as us" is the opposite of true

[@jjurksztowicz]

He was definitely being sarcastic, he has a lot of respect for hardware people.

[@kdhlkjhdlk]

Chefs and Plumbers work for themselves. I don't. They can pay for the fucking license.

[@OhMeadhbh]

very clearly mr. meijer does not understand how modern militaries work.

[@chaouanabil3087]

I like this ma, but for this talk, you can escape everything and go to this kzbin.info/www/bejne/aKaTpIGIhJKEgbM, it resumes what he wants to say. but yes agile has been used badly. agile is about developers, not managers, it is from developers to developers, then managers. I think he is wrong about TDD, TDD is about code not tests and it doesn't replace manual tests.

[@Saschaborg]

Genious. Not perfect, but genious.

[@jacekjacenty]

If you follow much of Erik's advice you will make yourself unemployable. It doesn't matter who is right about programming. In the end, the opinion of a person who pays your wages or your PM counts. Lots of companies have been doing it wrong, but they are still in business and ship products that work. Having said the above I have watched the video again 4 months later and I agree with Erik to much greater extent than before. I guess the people who condemn him should rethink their views every couple of months

[@17plus9]

Well, good luck with corporate evil.

[@dwylhq874]

30:50 "TDD crap" ... sorry you lost me there. Not writing tests is the excuse of mediocre developers who think that just because their code works _now_ it will always work in the future and will never need to be updated/improved or maintained. BS.

[@asdqwe4427]

Who the fuck has an hour long stand-up? In my team we are seven and it takes 10 minutes.

[@RedDevilSabbir]

LOL yeah

[@dvatanin]

10 minutes x 7 people = 70 man-minutes. I think that's what he means.

[@asdqwe4427]

dvatanin Ah, perhaps I didn't get it. I still think it's rather cheap and useful. But it did now that you guys clarified it make me think twice before getting long winded at stand up meetings.

[@a0flj0]

True. But this hour pays off, if it saves maybe 10 minutes of digging around why something else doesn't work, where it is available, whether it's done or not, per developer.

[@aylictal]

Throw stuff into production who cares? Is that what you expect with your bank statement when you go to see it? Is that what kind of software you want your doctor to use while he is treating you? LMAO

[@ramone138]

Damn, I want my 45 minutes of my life back.

[@straighter7032]

What is this? Talks about empiricsm, but doesn‘t show any research/proof. Talks about feedback loops, but forgets to say that any agile process puts a high emphasis on short feedback cycles (in contrast to sind old process models). Criticizes TDD, says we should test in production (LOL) and also praises Bertrand Meyer (THE design by contract advocate) in the same talk. Sit down and think before you talk!

[@jrgalyen]

This whole speech is so generic. No talk of domain driven practices, and agile being a hashtag and not a process. Search agile and you find hundreds of topics, one or more of which may or may not fit your domain. scrum, lean, ... are worthless in one area. and valuable in another. Continuous improvement and feedback loops. Processes. Scrum. Process. Tired of hearing about agile as a process. What we need are less opinions. And simple facts guided by the various domains (business logic, user needs, and such). And scenarios where topics tagged by agile works well. The whole point of domain driven software is to not care about what is not important or applicable. And focus on what is important. Since topics tagged under agile doesn’t fit your domain, quit talking about it.

[@radimkeseg]

PERFORMANCE very arrogant performance, might be good for stand up comedian performance with lots of populism, there it might win some award, but constructively it is hard to agree with most of the things, lots of pitches and manipulation phrases FACTS some hints are interesting and we can take some of these even from this rude speech, however there is no holy bible of software development, we have to be smart enough to adjust and improve our ways of development, we can take inspiration in multiple concepts and fit these to our needs based on the type of software we do, it will be different for start-ups, for huge companies or different segments such as gaming, finance, IT monitoring, production lines, medical .... TAKE AWAY I have to admit this speech showed/uncovered peculiar aspects of how some people can intercept ways of development methodologies such as agile

[@jansamohyl7983]

I think he was just fired from MS Research, that's why he is angry. Even though I disagree with some parts of it (like his position on open source), I like the fact that he is being honest with his rant. And about Agile he is pretty much correct - there is indeed no evidence for that new methodology.

[@stemphonyx85]

Not really true. There are studies behind it and most of the stuff that he says in this video, are actually done if you have an agile mentality. The problem that he describe are simply the humanisation of a theory. Subtle management is mainly happening in big companies, unfortunately. The small companies I have been in, are actually encouraging disagreement and me, as agile coach, encourage constructive feedbacks. I have heard many time people complaining like Mr Meijer and as Agile coach I encourage them to propose better ways of doing things. However, if this end up in a person that always does whatever he think it's best just because he think that's the only way of doing something, that's a problem. A team is made of people collaborating with each other. Having experienced people that act as heroes sometime can be extremely dangerous. For example: doi.org/10.1016/j.infsof.2008.01.006 just search online and find your sources of studies and data.

[@Hartformer2]

He left Microsoft a long time ago to build his own software company.

[@jakubsokoowski5603]

Entirely pointless drivel. Regardless of methodology good engineers will build good solutions and bad engineer will build bad solutions.

[@a0flj0]

What a pile of crap! Focus on form, instead of content, and you can paint anything black.