I understand the outcry over the heavy processes, but I think there are a lot of confusing statements here.
The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology. "Fix a 60-day timeframe and do whatever fits" is a method. The truth is, everyone needs to be organized somehow, and this is why we invent methodologies, frameworks, processes - call it whatever you want - but we all need some form of organization.
The problem is that some methodologies (Scrum, etc.) are heavily abused and transformed into management frameworks, which is the opposite of why they were created in the first place. But do you know how Agile was invented? It was a group of software developers, tired of heavy management processes, who came together to decide how to make their processes lightweight. Less is more.
Just as one example:
> "We don’t do Figma mocks. We don’t write PRDs. We don’t really have a design system. We don’t do agile.".
Well, right from the Agile manifesto:
> "Working software over pointless documentation."
So it sounds like we've come full circle. That's really a pity. I wonder how we can break the cycle. I also think we should take a look at the original ideas in the old-school methodologies (Agile, etc.) because they’re not bad, just abused. They were created 20 years ago by people who were in the same situation we are in now, so there's a lot of wisdom there that shouldn't be outright rejected.
Agile and Scrum was great when it was introduced bottom-up and then accepted top-down.
"We're all adults here, we don't need these rules" was a wide spread sentiment, yet work was horribly inefficient. I remember projects where we would discover every 3 weeks, during a Jour Fixe, that the pieces we built did not fit together.
The Daily was fantastic because it was lightweight and short, but very frequent, so that communication flowed freely.
The Retro was the catch-all meeting to bring up stuff (People forgot just how big the obstacles were back then - I remember having to wait 12 weeks for a config change that allowed my app to connect to the database).
Recognising that one person who always tried to bring everyone together, calling them a Scrum Master and making room for them to do these tasks was a no-brainer.
The top-down recognition was useful - not only did projects go noticeably better, managers could also boast that they, too, are now doing this new Agile thing! And they didn't even need to do something!
That was all before Scrum of Scrums, SAFe, LeSS, you name it.
As you said, we've come full circle in many aspects. It's ironic.
Sorry for a bit of a blunt comment following -- but your rose-tinted view of even the original Agile / Scrum ticked me off. I have to push back here, severely so.
> The Daily was fantastic because it was lightweight and short, but very frequent, so that communication flowed freely.
You should qualify your statements with "for me" and "for our project" because dailies have not been a net positive over my 23 years long career. Yes, not even once. I can't remember a single time I enjoyed them, nor a single time they ever helped me with anything at all related to work.
I am not introverted, nor autistic (though I very likely have ADHD). I am quite outgoing in fact, yet I will hate the dailies until my grave.
The only thing they achieved was put some juniors back on track because when they get blocked they also close up and don't talk to anyone (for whatever reasons that I'll never understand apparently), and give excuse to introverted people to open up a little and have some casual chat. I am not against the latter but I dislike work meetings being hijacked and turned into half therapy sessions.
I've suggested to them to do periodic screen-share pair-developing sessions, they did it, they absolutely loved it and kept doing it even after I left, and us who didn't want to do casual chats in supposed work meetings enjoyed the work meetings slightly more. Everybody won.
> The Retro was the catch-all meeting to bring up stuff (People forgot just how big the obstacles were back then - I remember having to wait 12 weeks for a config change that allowed my app to connect to the database).
And again, please add "for me" and "for our project". Retrospectives have been used in my career, without failure, without a single exception, to slap developers into rushing even more. That's what all managers I was ever under viewed them as: an opportunity to "correct velocity".
Masters whipping up the slaves because they don't pick cotton quick enough. Try and sugarcoat it as much as you like -- it's that and it was always that, and the people in power will always try to swing everything in that direction. It's who they are. It's what they are.
> Recognising that one person who always tried to bring everyone together, calling them a Scrum Master and making room for them to do these tasks was a no-brainer.
Really cute, until you had my life and career and saw the "scrum masters" being one of the managers cousins who saw an opportunity to give them income while pretending they are useful.
In my defense, I never witnessed a managerial system that helped me, so bear with me here.
> "We're all adults here, we don't need these rules" was a wide spread sentiment, yet work was horribly inefficient.
And for the third time: maybe in your teams. I worked in no less than 6 teams that did this very, very well. To the point of us not needing a manager because I and one other guy (we were 7 in total) basically said "OK, things A / B / C are more or less done but we still need X and Y; me and Joel are busy with infra stuff, anybody wants to pick those up?" and somebody always stepped up.
Is that what a scrum master is supposed to be doing? I've never seen it though. But we managed to distribute load and responsibility between ourselves pretty well.
Predictably, that team was eventually disbanded because we had actual power during the executive meetings (me and the other guy attended them). Nobody likes programmers who can push back in an informed manner that ruins the CEO's prepared graphs and slides. Who wants their beautiful illusions shattered by facts? Not these "adults" for sure.
And yes all of us left shortly after. And yes 3 out of the 7 of us were called back some months later to fix the messes of the others. We beat the code back into shape in less than a month, charged them triple and laughed our way to the bank.
---
Bigger point is: we all know the beautiful theory. But there are people out there who don't like it and want to skew the practices to what serves their interests, not yours and not mine.
Glad that you had such a positive experience. Really. But you should be more objective and remind yourself that you are very likely privileged. Most of us are not.
Sorry for not having made this clearer, I assumed it was obvious that I was sharing my own experiences, which is why I didn't prepend "..for me" or "..in my experience" anywhere. Reading through my post I do think it's sufficiently obvious, as I am specifically mentioning how I remember certain projects.
Looking through your counterpoints I think I need to emphasise my opening sentence a bit more strongly: It was fantastic _when it was introduced bottom-up_.
This is important, because the ceremonies were all engineering-driven and managers usually not present. So there was no rushing and "whipping" during the retros, there was no scrum master being the manager and everyone wanted to be done with the daily quickly, and so on.
> Really. But you should be more objective and remind yourself that you are very likely privileged. Most of us are not.
I have suffered all the bad parts of Agile much like everybody else, and a lot of what you say sounds painfully familiar. This doesn't invalidate my main point though.
> [...] over my 23 years long career.
Just as an aside, the first Scrum guide came out in 2010, and this is what in my memory created the widespread usage of Agile in general and this flavour of Agile specifically. This matches my memory that the best experiences I have made with Scrum all happened between ~2011 and ~2014.
> I have suffered all the bad parts of Agile much like everybody else, and a lot of what you say sounds painfully familiar. This doesn't invalidate my main point though.
Agreed, and apologies for the assumption. I got a little bit pissed, not at you though. :)
> Just as an aside, the first Scrum guide came out in 2010, and this is what in my memory created the widespread usage of Agile in general and this flavour of Agile specifically. This matches my memory that the best experiences I have made with Scrum all happened between ~2011 and ~2014.
Oh I know, but I believe both you and I witnessed a lot of similar techniques during our careers. At one point they just figured they'll give them a lot of names.
> Sorry for not having made this clearer, I assumed it was obvious that I was sharing my own experiences, which is why I didn't prepend "..for me" or "..in my experience" anywhere.
Yeah I know I was a bit difficult here, my idea was to bring visibility to our different bubbles. I've heard positive stories about Scrum / Agile many times but I am yet to live in one. :(
Sounds like you worked in some dysfunctional places. If things worked that bad on the communication/management level, I'm not sure any system really had a chance of working well. If you get an experience like "to slap developers into rushing even more." then the problem seems to be somewhere else and I'm not sure we can judge agile itself from this.
I've never seen a perfect place, but I'm sorry you had experiences like that. There really are places which function better and actually do friendly cooperation across levels.
> If you get an experience like "to slap developers into rushing even more." then the problem seems to be somewhere else and I'm not sure we can judge agile itself from this.
Oh, absolutely. Agreed. That's why I left several places during the course of the last 10-ish years.
> I've never seen a perfect place, but I'm sorry you had experiences like that. There really are places which function better and actually do friendly cooperation across levels.
Well, I just recently finished a limited term contract and started looking for a full-time employment (contracting is exhausting). Shout if you have anything. :) I mellowed out quite a lot in the last years and my comment above is just a triggered reaction.
Regional work culture is a thing and it took me a long time to start looking outside of that bubble. I was pretty stupid when it comes to work negotiations and people abused that.
Secondly, I don't think you'll find many programmers praising Scrum.
But, think what you will. I'm absolutely the villain, congratulations, you cracked the code.
Same here. Daily stand ups (no matter if they last 5 min. or 20) have not being useful for me any single time. They are used by managers to force us to show what we have been doing the day before. No more, no less. If I ever get stuck with something, I go and ask for help to my colleagues; I update the corresponding Jira ticket status and whatever is needed to keep my work visible.
Same for retros or any other kind of ceremony. They are just for managers.
> Retrospectives have been used in my career, without failure, without a single exception, to slap developers into rushing even more. That's what all managers
Dude, no. Kick managers out of the retro. The retro is a place for uncomfortable candor between peers, not another place for your manager to hold court. They need to leave the room while you decide what’s a problem, and what is not a problem (yet). Once you have a plan on the table you can bring the boss back in to discuss the redacted summary of the meeting and any proposals that require their assistance.
They didn’t work for you because you’ve done them wrong at every single place. I’ve had to fight twice to do it right, but we won both times via solidarity.
I haven't "done" anything. They were forced on me.
I get what you're saying and with time I started fighting for something 90% the same as you are describing. But most of the time I had no choice. It was "our way or the highway".
And since I was financially and career-wise extremely stupid for most of my life and career... yeah. I worked with idiots and slave-drivers.
I am looking to finally change that by changing the way I conduct myself. You hiring? Yeah, I didn't make myself an excellent advertisement with my original comment but at least people will know where I stand.
I've met some pretty obnoxious and difficult programmers but statistically most managers I ever met were difficult.
So yep, agreed with your point.
Problem with hiring good people is that you also have to give them the space and time to show their talents. Shoving them into meetings mostly aimed at people who are bad at communication and/or are junior in terms of abilities is the best way to destroy their motivation.
> The problem is that some methodologies (Scrum, etc.) are heavily abused and transformed into management frameworks, which is the opposite of why they were created in the first place.
At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand.
Any quality work, gain in efficiencies, improvement potential, etc will be hindered by the desire to apply blindly and without creativity any given thought framework.
management is very creative, they just sometimes don't realize that agile is not a management process, it's an engineering process. it's an easy mistake to make because they want to measure engineering output somehow and introduce measurements which cause decoherence of the engineering process state if I may use a quantum analogy instead of a car one.
IOW they're trying to do their jobs (manage employees) but engineering is a high trust profession and some managers just don't have the trust (not to say that all engineers have the integrity...)
That’s because Scrum is so easy to turn into a management process. It makes more sense to them than all the other forms of Agile combined. So like children reaching for candy instead of vegetables, or who will only eat carrots as a vegetable, you have to work to make them reach for something else, otherwise they will be unhealthy.
What you described, I wouldn't accept generally under my definition of creativity.
In order for creativity to be such it must ultimately deliver value; managers "doing their job" in ways which hinder instead of supporting engineers is not creative, it's disruptive.
> agile is not a management process, it's an engineering process
That's interesting - I've always thought of it slightly more broadly as a team-running process. You don't have to be doing engineering to do it; you might be building a website in Wix. You just need to iterate and inspect. What do you think?
> At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand.
I think most commenters on HN understand this.
But then what problem does capital-A Agile solve? It was meant to surface problems faster and empower people in teams, and benefit the customer, avoiding waste and nasty surprises. Yet we've seen enough horror stories in these past decades to understand Agile (Scrum et al) can fail just just as often and is as prone to mismanagement and meddling as the methods it was meant to replace.
It takes a strong team (leadership and stakeholders included) to make Agile work and reap its benefits. But such a strong team will probably work well with whatever methodology -- strong teams are effective regardless.
What about average teams, which Agile was supposed to be helping? In my experience, they'll fail just as often.
A method that works for a team of focused superheroes is not really applicable to the general population of developers.
Capital-A Agile is for companies that want the benefits of agile (higher velocity) but don’t want to trust their employees or make any meaningful changes in how the management team operates (micromanagement, committing to rigid feature scopes on rigid schedules).
Obviously this doesn’t increase work but companies get to say they are “agile” and the management team gets to keep doing all the counterproductive management they were doing before. No hard conversations about changing how management operates or unpredictable things like giving engineers autonomy.
This sounds cynical on its face but it is my experience as well. Management does not actually trust engineers to provide value without close oversight (sometimes with good reason!), so any framework that purports to give engineers more autonomy will eventually be subverted by the management. And since management always has more power than line engineering, they always win.
The only way for "true" agile to really take root would be for management to trust engineering to add more value on their own than when being micromanaged. That's a tall order, and gets much taller in larger organizations.
Agile is not there for higher velocity! It is sold to management that way often, but intrinsically - no.
Agile though is meant to reduce waste. In other words, you don't march faster, but are supposed to spend more time marching in the right direction. (I personally loathe agile and find it intrinsically broken.. I just find it kind of funny that a process oriented around dynamic environments is supposed to give predictability and speed, when it gives neither. If anything, a lack of predictability since direction can change)
I think there's some truth that process slows down development. (Full disclosure, I work for a company in the same space as these folks.)
I love a provocative essay as much as the next person.
But the authors are in a relatively new, smaller company focusing on devtools[0]. This has a couple of ramifications related to process need:
- they are the customer to a great extent, so they don't need to involve external customers to discover what is needed.
- they are fast followers (an OSS WorkOS competitor[1]), so can rely on product need discovery from other competitors. That's not a bad thing (I've done the same!), but it isn't sustainable forever.
- they have a small team, which means everyone has autonomy and knowledge.
- at the size of 2, they don't have other departments with schedules and deadlines and goals. Process is critical to getting input and coordinating across departments to achieve company goals.
All of these factors mean process is an impediment without any benefit.
Not every company is like this company. Not every dev team is like this dev team. My opinion is that this company in three years won't be like this company is now.
I'd wager that in 3 years, if ssoready is successful, there'll be process. It'll be an impediment but a necessary one, as the attributes they currently have won't be enough to keep delivering.
Happy to bet on that if either Ned or Ulysse is reading :)
Every team has process. It doesn't matter if it's documented or not, or whether improvements (or impediments) are intentional or not. Every team has their process.
Source: Identifying teams' principles and practices is one of the tools I use.
Agile, in practice, has turned into "disorganized waterfall." Witness absurdities like the existence of the "Agile Gantt Chart for Jira." The reason Waterfall, or modern Agile, are the way they are, is that they are systems that allows the smallest possible number of people to take responsibility, while allowing everyone to perform accountability. Basically nobody wants to lay it on the line and say to the CTO, "I'm going to make this project succeed." Much easier to say, "we're using best practices and modern processes."
This is a consequence of failing to train managers, especially in the moral dimension of management, which is entirely about accepting responsibility, and of promoting into management individuals who are not prepared to do so.
It turns out for large cross-team initiatives, organizing the work is as hard as doing it.
I like the example of internationalization. You need involvement from all parts of the product to release it - you rarely can sell a half-internationalized product. You need to work with external teams of translators who need to be fed the work in a consistent interface. There will be pieces of the work that nobody is going to forsee (e.g. pulling text from the database) that will be surfaced and handled consistently.
So, to get it out, you need to have each team prioritize the work. You effectively need a deadline, or the work will never happen. (The work is valuable for the company, but does not drive any individual team's customers.) You will have dependencies: Team A has to address part of the work before team B can. And you need a way for teams to report that they are done so that it can be reviewed for consistency across the product.
This is a bad fit for most agile methodologies, but you're not going to take everyone out of it temporarily and then go back in. So you have to accommodate a project within your system.
But these exceptions become more and more common as your company gets bigger and bigger. The only truth that I can find is that the only way to stay agile is to stay small: small teams naturally do the things that are agile.
The Agile manifesto is great. It is simple, straightforward, and most importantly, it clearly defines itself as a statement of opinion, with a counterpart to each of its value. And yet so many people do exactly what the manifesto tells them not do to. Why? Just why? It is as if a clothing brand has "beach and sun over mountain and snow" as its value and people go to ski with them and complain that they get cold.
Agile is not on size fits all, sometimes you need comprehensive documentation for instance. In this case, just don't do Agile, the manifesto is really explicit in that it is not the right methodology for you. But for some reason, Agile is fashionable, so you take it anyways and try reshape it into the V-model you should have used in the first place and get the worst of both.
> And yet so many people do exactly what the manifesto tells them not do to. Why? Just why?
The manager on the top says "do Agile" because his friends say that this is now the cool thing. The managers on the bottom have no idea what it means, so they do some random thing and call it "Agile", and report job done. The manager on the top is happy and gives them a small bonus.
And as managers circulate across companies, they keep introducing the "random thing we did at my previous job and called it Agile" as the one true Agile, so the whole randomness converges to one specific version (with Jira and long meetings and other stuff).
Much of this has, I think, to do with mutuality. If person A and person B need to work together both need to change their preferred way of working to accommodate each other. In larger groups there is a problem if one person gets to decide on too much and does not have to take other people seriously.
And that usually breaks, as another reply said, when the manager of the two people delegates responsibility for the problem getting solved to one of those two people instead of keeping it for themselves.
If you have a boss who cares whether the task gets done, you can’t make excuses about how it violates your moat to have to do it. Shut up and help your coworker. Now. Or you’re on PIP.
The coworker who isn’t getting useful collaboration gets blamed for their soft skills, when it’s the boss’s soft skills that should have reigned over both.
Take a hopelessly disorganized team, apply any, literally any, management framework on top of that team and productivity will increase.
Since management frameworks do not contain intrinsic fixpoints, keep applying the framework and things will halt to a stop, because whole effort will be spent serving the framework. Ditch the framework, start doing random stuff and productivity will magically increase.
All developers know all the wisdom. Everyone who had a manager knows the problems in any process.
The only ones who seem to not know or see or understand the problems are various layers of management. This is weird because ostensibly that is their one job.
I can understand how a junior manager who only worked one year in the industry can get fooled into believing in the rigid processes with pointless artifacts.
But if you worked building software for five or even two or three years, I cannot possibly imagine how one goes about their day managing a software project in this fantasy land.
By “manager” I mean all the chickens that decide how the pigs work, and all the chicken in pigs clothing. I do not mean all kinds of management.
We never went anywhere. I had such high hopes for the agile manifesto when I first read it in 1999. "Whew," I though, "finally, they realize that software can't be managed like an automobile assembly line." Nope, they just rebranded the "manage software like an automobile assembly line" methodology as... AGILE! Don't get me wrong - the signatories on the agile manifesto did seem to understand how to realistically plan and manage software. Nobody else who read it and had any position of authority seemed to.
There is no breaking cycles. Humanity is on an approximately periodic 20-year oscillation around the mean. Just look at programming languages, ai cycles, web iterations, etc.
It's just human nature - we deplore the tools our parents used.
However, as long as that mean drifts in the right direction!
I can't even imagine how Scrum could ever align with the Agile values for it to be abused and transformed. IMO, that part is impossible, and Scrum was always a "bad-management by the numbers" framework.
Anyway, I've hear phrases like your example since some time around 2001. Agile was practically born with a parasitic consulting market intent on having the one true way to do it, and that way being what middle-managers adept of micro-managing want it to be. In fact, I think those consultants were the ones that pushed the word around, without them we wouldn't even have heard of the manifesto.
That's to say that, yeah, I do agree with your comment, but the actual problem is deeper, and harder to fix. Scrum and bad processes are just symptoms here.
"Hire former software engineers at management positions" would be the answer, but of course there are various factors that makes it difficult to do so.
In theory, management should be held accountable for getting in a way, but it is not possible either because of the nature of software development: one cannot really measure productivity because it is to a more-or-less large extent a research activity.
I think probably the best option is to introduce some more democracy (or rather "technocracy" in the literal sense, "power to those who build") in the mix: management evaluated and chosen by the engineers. Call me communist all you want...
I didn't take the article as a "lack of organization" is best. I took the overall theme as that most methodologies are a distraction to what is most important, building things.
The fundamental issue, I think, is that there is a strong tendency for management to value process (measurable) over progress (often seems like nothing for weeks or months and then bam out of “nowhere” revolutionary new features.
Agile, scrum, etc al are supposed to be guidelines for engineering teams to maintain coherence on progress, but they describe a process, so inevitably management either interjects in the process, tries to use it as a handle to control the process, or pulls engineers out of the project to “manage” the process… all at the expense of progress.
Management can’t see progress, but they can see process. So naturally, they become focused on what they can see, and conflate the process for progress.
I think the issue with Agile was that it was named. After something is named and codified it becomes a thing and everyone can mangle the thing to fit their desires until it becomes antithesis of the initial intents.
This guy doesn't name or codify his approach. So it's fine, there are only intents, there's barely anything to mangle.
> But do you know how Agile was invented? It was a group of software developers, tired of heavy management processes, who came together to decide how to make their processes lightweight.
Agile is agile the same way the People’s Democratic Republic of Korea is a democracy. And like most dictatorships with these names, I’m sure they also have a founding myth that claims a genuine concern for Democracy and the People.
Software developers are concerned with developing software. The people with the time and energy to develop and sell methodologies like Agile are not in the business of developing software; they’re in the business of selling methodologies. Maybe they’re consultants trying to sell clients on the methodology as a selling point for their consultancy (much of Agile seems geared to this), or maybe they’re trying to train people to be Certified Scrum Masters or whatever. Either way, you can’t actually sell people a methodology that boils down to reducing methodology because then you have nothing to sell.
I know I sound cynical, but the reality is that human behavior is driven by incentives and anyone who genuinely cared about making processes lightweight has little incentive to hang around the Agile scene fighting with the grifters.
In my experience, to successfully reduce process, you need to have really good people.
That usually means a heterogeneous mix of skilled, smart, experienced, and creative people that work well as a team, and teams like that, don’t come easily.
People (and teams) are really important, and I believe it’s a mistake to think of them as some kind of interchangeable modules (as is the norm in the tech industry, these days).
So good management is critical. Keeping staff for long periods of time is also critical. If you have a lot of turnover, you need process to regulate the churn. Long-term employees don’t need to be told what to do, in triplicate, every day. They Just Know, and that “tribal knowledge” is the real key. Also, people that have worked together for a long time have significantly reduced communication overhead. A lot of stuff doesn’t need to be said or written down.
This goes double, when working at scale.
All that said, I used to work for a corporation that treated Process as a religion.
They make really, really good stuff (at scale), but the overhead can be unbearable.
They still make good stuff, though, and I haven’t seen anything close, come from less process-driven outfits. Their competitors have just as much process.
I wrote a piece called “Concrete Galoshes”[0], some time ago, that talks about this.
That's the thing all these "easy bake recipe for success" blog posts miss: it's all about the people. I've been in companies with the exact same processes and wildly different outcomes because staff was more competent (which includes soft skills) and experienced.
But that is anathema to tech companies that think having the right X (agile, Spotify guilds, kanban, etc.) will fix everything because that's what they sell to end users.
These rigid processes and ceremonies are the mcdonalds approach. You can get a group of unskilled randos and produce passable slop (e.g. MS Teams). The problem is that people with actual skill suffocate in such an environment.
If you have a crappy team and only light processes, you get garbage.
If you have a crappy team and heavy processes, you get barely passable results.
If you have a good team and only light processes, you get great results.
If you have a good team and heavy processes, you get barely passable results.
It's worth bearing in mind that as much as we don't like it, a lot of the time the goal is passable slop. Mcdonalds is doing well, and they arent focussing on increasing the quality of their slop unless theres some public outcry.
I once read a comment, here, that said, "If the code quality on your MVP doesn't physically disgust you, you're probably focusing on code quality too much."
I think that sort of sums up the zeitgeist. I'm also not a fan of the MVP Model. I don't think it results in good work.
I was extremely fortunate, and managed a team of really experienced and good developers.
Unfortunately, the company I worked for, worshipped Process, so, as their manager, I spent a great deal of time, shielding them from that overhead. This did not always win me praise from my managers.
But we got pretty damn good work done. Sadly, it was "engine" code, and was often shipped in "passable" UX.
Kind of like dropping an F1 engine into a beater Chevy Vega.
That does raise the question of what those tech companies' motivation really are though.
The processes you described would work really well if the goal is to meet a hiring target and ship just enough product that marketing and sales can run with it.
If they don't necessarily care about quality of end product or quality of the engineering that went into, throwing heavy process at the team may get them there just fine. That heavy process may even work better for them if the goal is more managerial control to meet sales and marketing deadlines.
Agile Manifesto was invented by consultants / contractors to make better products for their customers at a good price, not by ivory tower engineers building Platonically ideal software.
Largely agree. Heavy process is a tool to help less skilled people have output more comparable to more skilled people. But it comes at a cost of making more skilled people less productive. If you can hire small numbers of highly skilled people you can accomplish a lot with little process. Sadly at some scale “hire only really skilled people” becomes basically impossible and process needs to be more heavy to account for that.
Scrum seems to be more about helping a manager of less skilled/experienced people get more output from them.
As people become more familiar with agile processes in general (we all say we are “doing scrum” but we are also doing more than half of XP - otherwise a scrum doesn’t work at all) those gains diminish and I think among us we can agree they go negative.
This. If you have good people, it really doesn't matter what process you use. If you don't have good people, well, it really doesn't matter then, either...
This is very true, and I second the importance of long tenure. There is no substitute for it; it helps with product experience, personal relationships, and organizational knowledge.
> In my experience, to successfully reduce process, you need to have really good people.
Yes, but...
Don't all of these Agile methodologies predicate their success on having at least a decent proportion of really good people (including stakeholders!) in the team?
Normally, I ignore obvious troll comments, but I do have respect for your expertise, so I'd like to ask for some enlightenment. If I'm wrong, the only way to find out, is to ask how.
Good stuff in here, but be cautioned that the author doesn’t mention their customers are engineers until a bit later in. Which gives a lot more leeway in allowing engineers to make a majority of decisions.
In a more complex domain, like maybe selling private securities, collaboration isn’t slow, it helps us not get fined millions of dollars by the SEC.
Personally, I also love minimalist process and likewise believe “methodology” is bullshit, but I caution you, the reader, to consider the specifics of the context you’re working in.
For me, that means that almost everything goes figma first. Engineers + product work together to build a figma, which allows other parties to see what we’re building and contribute in a tangible and useful way.
I'm in a large corp as bridge between development and the business. What i do is minimize process on the dev side, and maximize it on the org side. On the dev side my only ask is predictability, which is hard enough already, but is so important for communication. On the org side, i overengineered process. It focusses on value, and helps to keep chaos away from the developers.
Most domains lie somewhere between serving engineers and doing something really complex and sensitive. It's always a nice goal for your engineers to gain significant proficiency in the product domain, so they don't have to defer all decisions to other people. It's a "cache miss" equivalent in product development process.
You can still have domain experts collaborate directly with engineers instead of adding a middleman in the form of a product manager.
The more I work, the more I'm convinced that product management is not truly a profession but rather a way for non-technical people to insert themselves into a profitable industry.
This might make sense from a high level, but again, the devil is in the details.
Realistically you do need someone (vendor or not) to translate 1000's of pages of legal jargon into actual product decisions. There's a tipping point where paying an engineer $x or $y to do that themselves (if they even have the skill to interpret it) is waste of talent.
The point of a product manager is to make a lot of decisions that don't have a clear answer. "Should we use websockets or REST for our chat client?" - easy technical call. "Which market segment should we target with our features?" - not so technical.
There are plenty of technical decisions that don't have a clear answer (e.g. which of 1000 web frameworks should we use?), and plenty of product decisions that do. The separation between roles has nothing to do with clarity but with the (sometimes fuzzy) difference between technical decisions and product decisions.
You're right that decisions regarding frameworks are often made for largely arational reasons, but I'm baffled by the claim that these are not technical decisions (unless you're just joking?). If they're not, does that mean that in your model it's the PM who decides which web framework and database the team uses?
In any case, even if my example were a bad example for some reason, there are definitely lots of technical decisions that are fuzzy. How could there not be?
While the domain of e.g. private securities may be complex, this usually isn't the main problem for developers; I'd argue this article isn't about legal requirements and the like so much, but about the actual implementation thereof. In the case of a complex domain, stick to writing the requirements and don't try and invent new things or what-ifs, because those may end up causing those legal issues.
That said, the reality is that a lot of developers are also expected to be domain experts and work independently, including knowing a lot of the legal requirements. More in my field, that's stuff like GDPR and A11y compliance (WCAG 2.2 level AA will be a legal requirement for most companies come 2025, see the European Accessibility Act [0])
>I'd argue this article isn't about legal requirements and the like so much
Yes, it fails to address that other businesses face additional complexity and constraints that they don't have and then broadly over-prescribed their principles.
I'm genuinely curious how you're separating "legal requirements" from "implementation" (of either product, or process). When you build things, you have constraints, and you have to respect those constraints, or you built something lousy. If understanding those constraints is part of the building process, then trying to find the fastest way to incorporate those constraints into the product while minimizing time this blocks product development (and thus, velocity), seems like the obvious thing to optimize for. So I don't understand how you're trying to separate those (and to to be overly clear, I'm asking out of genuine curiosity to understand your point better).
> Engineers + product work together to build a figma
I'm not going to tell you that what works for you doesn't work for you, but just to contribute another perspective, elaborate Figma mockups are a bit of a red flag for me. They show that a significant amount of time has been invested in a high-fidelity design of a complex UI that has never once been used do to any actual work. It's impossible to know if a UI is any good if you haven't used it in anger. A rough functional prototype might take longer to make (and, crucially, doesn't look as good in company-internal slide presentations), but it's vastly more valuable IMHO.
That’s a good point. The figmas we build are not high fidelity. But they’re more than wireframes. The point is to get everyone on the same page conceptually as to what is going to be built, but the details are still left as an iterative process for the engineer implementing.
The point of the figma is to answer the question “what visuals will help ops, legal, and engineers be on the same page when discussing” and NOT “the button should be 48px down”. UX specific “extras” like confirmation modals, etc. are never added because that doesn’t answer the first question.
The missing context here is that their company looks to be a very small team - 5 employees according to LinkedIn.
Any process or methodology, or lack of, will work for a small sized company. At that size you get things done by just talking with each other. That doesn't scale to companies with hundreds or thousands of employees where multiple teams that you've never interacted with before may be involved in a project. These "throw out the processes and methodologies" articles are always written by people at small companies. Once they grow, they'll implement the same processes that everyone else uses to solve the problem of becoming too chaotic.
> Most companies assign requirements, assert a deadline, and treat quality as an output. We tend to do the opposite. Given a standard of quality, what can we ship in 60 days?
They're absolutely describing Shape Up, but without agreeing on what the valuable things are to build - apparently engineers can figure all that out by themselves. I have my doubts.
Although not exactly the same, this is very reminiscent of Spolsky's "Big Macs vs. The Naked Chef" (2001) [0] where he explained:
> What’s the moral of the story? Beware of Methodologies. They are a great way to bring everyone up to a dismal, but passable, level of performance, but at the same time, they are aggravating to more talented people who chafe at the restrictions that are placed on them. It’s pretty obvious to me that a talented chef is not going to be happy making burgers at McDonald’s, precisely because of McDonald’s rules. So why do IT consultants brag so much about their methodologies? (Beats me.)
I really enjoyed this. I try to run my team similarly.
Where I disagree slightly is vendors. If the need filled by the vendor is well-defined and low-complexity, sure, I'll go for it. Otherwise, I'm doing it in-house nine times out of ten.
Where this starts to get tricky is when some worthy competitors emerge, utilizing your foundation to scale quicker and more effectively. Then you might wish you had hired more people earlier. But overall, I think starting from this perspective is a lot safer than the opposite.
> Our customers are engineers, so we generally expect that our engineers can handle product, design, and all the rest. We don’t need to have a whole committee weighing in.
This is the reason you have the luxury of this approach, engineers tend not to care as much about the "little things", but average users, especially enterprise users, rely heavily on the little pieces of experience that make tech palatable to them.
Sounds like this company is small. The processes the author discards have their place. His article more or less sounds like “our customers want a small hole dug, we don’t need to a whole excavator for that - just shovels”.
The reason larger companies write prds, figma mocks, etc is to get alignment across more people that are detached from your individual thing
At a small company you don’t need that. Everyone is working on one main work stream
At larger companies, there’s hundreds or thousands of important projects at one time and lots of supporting teams for those. Everyone has their own shit to worry about and can’t possibly remember all the context on your projects, so you make it clear as possible to quickly bring disassociated people up to speed on why it’s important and what you need from them
It also helps disassociated leadership buy into your ideas. A picture is worth a thousand words.
Up to a point, sure. But it's definitely a field full of "unknown unknowns", and I don't envy them. That said, good architecture and principles are important, which is why for example *nix has a better security track record than older Windows versions.
That's a good point. I imagine this advice would be actively bad advice for building more complicated things (e.g. an IDE, perhaps a game, a turbotax alternative).
Part of the skill of engineering is knowing when you need to do upfront engineering and when you can just throw some code at the wall.
This works if a project is doable with a small team of smart/experienced people -- if it isn't then the methodologies become important
On any sufficiently complex piece of engineering -- using vendors to accelerate progress works until it doesn't -- there is usually a point very early in a product lifecycle where that starts to constrain progress/agility or limit feature development ... then there is another point later where it starts to bite financially ... then a point where the vendor gets acquired or ceases supporting it
> Most companies assign requirements, assert a deadline, and treat quality as an output. We tend to do the opposite. Given a standard of quality, what can we ship in 60 days?
Also, work tends to expand to occupy alloted time. That is, if you tell someone they have 60 days to finish a task that could be done in a week, most often than not people will use 60 days.
So by not limiting what should be done in 60 days, they are more likely to avoid this pitfall.
> That is, if you tell someone they have 60 days to finish a task that could be done in a week, most often than not people will use 60 days.
This happens in mostly too situations:
- the person has absolutely no stakes in the game, and you are the only one caring whether it takes 60 days or not. Typically if you are paying them based on their hours worked as a contractor.
- The person understands that the task or the deadline is bullshit and nothing will important will happen whether it's finished in 60 days or not.
I've found that people who do this have just told your company they are not worth the money to employ them, and they go in the next downsize. If the sixty days is enforced by being the actual deadline, all the important steps (documentation, testing, future-proofing, extensibility, simplicity of design, etc.) should be done, along with a new set of custom tools to make the same type of job take a week next time it is asked for. By somebody else if necessary. Ironically (?) the best developers build their own redundancy into their work. I developed in a way that allowed another person to get up to speed and take over my work. It informs good design, coding and documentation. I kept that job for over twenty years with several downsizing episodes. Sorry this sounds like gloating, but it was a technique that worked, so I thought I'd share.
RE "small problems": I would be very curious to know what the top 3 principles are for this team. What are the three things that _never_ fall into small problems? Security was mentioned, but what else is their non negotiable?
To be honest I have a hard time squaring "security is important" with "we write idiot mode code all the time" and "we don't write design docs". I do believe some people can just naturally, from the ether, pull out things that are designed "correctly" from the outset. But my impression is that if you're caring about security, then you need to have some established patterns for how to deal with stuff.
Not talking about SOLID so much as just, on an API design level, having things that are hard to mis-use and the like. And seems hard to land on that without some levels of discussion. But maybe the small team is actually micro-iterating at such a level that this does not matter!
It doesn't explain _why_ simple implementation is more important than having a simple interface, but it just makes an observation that simple implementation usually wins.
In my experiments simple implementation won for velocity, because quite often I need to change small parts in all the implementation no matter how modular / reusable code I'm trying to write.
As my velocity increases testing becomes more important as well (especially integration testing), as there are more features interacting in a small amount of code.
My friends and I believe these are more people-problem than anything else. If we iterate at solving that people-problem as much as possible; introduction of patterns, processes, etc., will eventually lead to better work results.
For instance, even if a team has the best-intentioned tools such as Project Management, CRM, Wiki, Documentation, etc., if the teams do not use them well, they are always bad tools.
Separating toolings (including all of the methodologies) from the ways and the culture of how a team works will be more beneficial to the team and, hence, benefit the company.
Generally I agree with this for 90% of startups. If it's a solved problem, you should not be doing it. Don't reinvent wheels just pick wheels off the street and use them. Then an axel then a frame, etc etc until you've got something that moves because it's literally held together by zipties.
The key is that a number of people are willing to pay you for the moving ziptie vehicle because it solves their particular problem - whatever it is.
Most recently I tried Cursor app. it helps me be a faster coder and uses something i already know - i really like it (except that they shit all over the hotkey bindings).
Ouch. I guess you never did one of those "we brought large-software-X, and are in 2/3 of the way to implement it; we just need you to plug you in-house software-Y to it" projects, where you end up reimplementing every single feature from X into Y and make people give-up on the brought software before the vendor finishes installing it or allows you to see the documentation on how to plug anything into it.
Those are so common that I think they are the majoritarian way any large software is brought.
The biggest midwit vibe is throwing everything out when the pendulum swings to no process mode and then adding a whole bunch of process/methodology when that doesn't work.
They seem to really prioritize “just works”. I am currently reviewing a PR that assembles some code as a string, using a CSV with carefully named columns. It does, in fact , work on the example CSV. I would invite this team to approve and support that for me over the next 5 years.
Absolutely on point and matches my experience (20+ years in software). The hard part is not software delivery; the hard part is stopping all the unnecessary technology and process and people inexorably creeping into everything everywhere.
Who does this apply to? Idiot mode doesn't make sense in the long run, does it mean they skip tests? Do they only build fragile stuff? Is there API easy to work with?
Idiot mode just means that if the job is to turn some bits into some other bits, you just write a function to do that.
You don't make a whole business taxonomy in a UML class diagram first or worry about the single responsibility of the function or whatever.
Here we go again. The golden rule I've come to realise is that people don't like what they don't understand. It's made very clear this person doesn't like methodologies.
I don't get the use of midwit meme here. Either you're implying that you're preaching the the choir, in which case it's just an echo chamber, or you're calling your audience idiots. Neither outcome is great.
There's always a balance. Being overly orthodox about methodology is suboptimal, yet equally, having no guard rails when people need them is equally as bad. Going around expecting everyone to work exactly how you work is not the reality and tends to lead you down one path.
> Given a standard of quality, what can we ship in 60 days?
Others have said it, this is a methodology, and quite an aggressive one that causes a lot of questions to be asked, and if you don't, you'll end up in a mess. It requires planning, discussion, size estimation, design, maybe even prioritization (if you have two things that each take 45 days, one needs cutting and a 15 day one needs picking up, or you need to cut the scope down to 30 days each, and so on).
I get it, people are bored of being managed to an inch of their lives, but I'm going to be contrarian here:
We need to grow up as an industry a bit on this one.
If you walk onto a construction site, you will see methodologies. The methods you see will not be the same ones as you might have used to build a lego house, or even a sandcastle on a beach. There will be Gaant charts, and project managers, and discussions, and plans, and estimates, and meetings. They do all that, because they don't want the building to fall down. These methods give us some assurances that the right things are happening in the right order and at the end, the building will function as designed and not kill anyone.
When you walk into Airbus (let's leave Boeing to one side on this one), they aren't sat around making paper planes or models like they did when they were kids. They're not throwing designs together as they feel like it: there are methods, projects, and people to co-ordinate them. They do this because they want to be sure that the aircraft they build do not fall apart, even in marginal conditions they could have accounted for.
Yet, for some reason, perhaps because its an industry where people first get involved in coding as a hobby, or for personal fulfillment, or some other personal reason, we seem to reject all this.
We all want to be left alone, artisans in our attics, cutting the code we want to cut, for the features we think are needed, the way we want to build them, because we're special, and managers "don't understand".
Perhaps even worse, many people really learn the fundamentals of the industry from academic applied mathematicians, who think the work is thinking alone in an office, writing a paper and occasionally teaching people - this isn't how software is built in industry. We have much to learn from professors of computer science, but we should not model our work behavior on their work behavior.
The software we build can really hurt people. We owe it to others that we actually engineer it, not just hack it. Our software can easily do a bad enough job that the company - or customers' companies - fail and people lose their jobs. In some cases, failing to ship on time, or to a good enough quality might lead to even bigger consequences, up to and including death.
There is an entire subsection of the industry pointing out the security risks created by software badly designed and badly built, due to a lack of engineering talent and appropriate oversight. We should all want to fix that, and I don't believe letting engineers sit in corner ignoring basic engineering best practices is going to be a successful path to that outcome.
We need to be more like the construction sites, the aircraft builders, the ship yards submarines get built in, the real grown-up engineering disciplines. We need to come down from our little pillars and talk to people about what needs doing, and by when, and then have adult conversations about constraints and risks.
Nobody wants everyone in meetings all day. Perhaps those conversations are weighted more heavily towards more senior engineers, which is what happens in most industries outside of software. Nobody wants to be micro-managed, but at the same time it is reasonable for the people paying you many multiples of the national median salary to ask you what it is you're doing right now, if you're blocked, and what you plan to work on next - and make suggestions about changing that plan if the company paying you needs you to change that plan.
I agree that the agile certifications need to go - or radically change - and that engineers need to be trusted more, but trust is earned. The constant push back on anything that looks like reasonable organization to any other industry or to any manager, makes the industry as a whole - and those who shout the most about the pain of it all - lose trust in the eyes of the people who we need to invest in it.
We just need to grow up, stop pretending that what worked when we were making sandcastles works for employers, and look to successful engineering disciplines away from software and learn from them.
But most software out there is built with heavy processes? SAFe and all that nonsense, and everyone agrees the output is complete garbage. The software that is lauded and praised tends to be made by small teams of highly skilled engineers, stuff like EmberGen.
To me what this says is that software is not, at all, like other engineering disciplines. Software developers aren't like masons, we're not just mixing cement, there's more to it than that. You can add more masons to a construction work and it will most likely go faster. Add more devs to a project and most likely it'll go slower.
Everybody uses methodology and processes, being it explicit or implicit, cool or not, written or tribal-transmited.
We tend to go to the other side of the pendulum when something disgusts us but there's no single company without it's own methodology. Even the most "we're code punks" expect their team to work in some specific way.
"Extremes are bullshit". And some articles nonsense.
While I can get behind a lot of points in this post like "what can we do well in 60 days?" and "some problems aren't important," I shudder a little when I see that headline, when I note that the company provides SSO for enterprises, and when I then wonder about their test and QA pipeline.
I understand the outcry over the heavy processes, but I think there are a lot of confusing statements here.
The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology. "Fix a 60-day timeframe and do whatever fits" is a method. The truth is, everyone needs to be organized somehow, and this is why we invent methodologies, frameworks, processes - call it whatever you want - but we all need some form of organization.
The problem is that some methodologies (Scrum, etc.) are heavily abused and transformed into management frameworks, which is the opposite of why they were created in the first place. But do you know how Agile was invented? It was a group of software developers, tired of heavy management processes, who came together to decide how to make their processes lightweight. Less is more.
Just as one example: > "We don’t do Figma mocks. We don’t write PRDs. We don’t really have a design system. We don’t do agile.". Well, right from the Agile manifesto: > "Working software over pointless documentation."
So it sounds like we've come full circle. That's really a pity. I wonder how we can break the cycle. I also think we should take a look at the original ideas in the old-school methodologies (Agile, etc.) because they’re not bad, just abused. They were created 20 years ago by people who were in the same situation we are in now, so there's a lot of wisdom there that shouldn't be outright rejected.
Agile and Scrum was great when it was introduced bottom-up and then accepted top-down.
"We're all adults here, we don't need these rules" was a wide spread sentiment, yet work was horribly inefficient. I remember projects where we would discover every 3 weeks, during a Jour Fixe, that the pieces we built did not fit together.
The Daily was fantastic because it was lightweight and short, but very frequent, so that communication flowed freely. The Retro was the catch-all meeting to bring up stuff (People forgot just how big the obstacles were back then - I remember having to wait 12 weeks for a config change that allowed my app to connect to the database). Recognising that one person who always tried to bring everyone together, calling them a Scrum Master and making room for them to do these tasks was a no-brainer.
The top-down recognition was useful - not only did projects go noticeably better, managers could also boast that they, too, are now doing this new Agile thing! And they didn't even need to do something!
That was all before Scrum of Scrums, SAFe, LeSS, you name it.
As you said, we've come full circle in many aspects. It's ironic.
Sorry for a bit of a blunt comment following -- but your rose-tinted view of even the original Agile / Scrum ticked me off. I have to push back here, severely so.
> The Daily was fantastic because it was lightweight and short, but very frequent, so that communication flowed freely.
You should qualify your statements with "for me" and "for our project" because dailies have not been a net positive over my 23 years long career. Yes, not even once. I can't remember a single time I enjoyed them, nor a single time they ever helped me with anything at all related to work.
I am not introverted, nor autistic (though I very likely have ADHD). I am quite outgoing in fact, yet I will hate the dailies until my grave.
The only thing they achieved was put some juniors back on track because when they get blocked they also close up and don't talk to anyone (for whatever reasons that I'll never understand apparently), and give excuse to introverted people to open up a little and have some casual chat. I am not against the latter but I dislike work meetings being hijacked and turned into half therapy sessions.
I've suggested to them to do periodic screen-share pair-developing sessions, they did it, they absolutely loved it and kept doing it even after I left, and us who didn't want to do casual chats in supposed work meetings enjoyed the work meetings slightly more. Everybody won.
> The Retro was the catch-all meeting to bring up stuff (People forgot just how big the obstacles were back then - I remember having to wait 12 weeks for a config change that allowed my app to connect to the database).
And again, please add "for me" and "for our project". Retrospectives have been used in my career, without failure, without a single exception, to slap developers into rushing even more. That's what all managers I was ever under viewed them as: an opportunity to "correct velocity".
Masters whipping up the slaves because they don't pick cotton quick enough. Try and sugarcoat it as much as you like -- it's that and it was always that, and the people in power will always try to swing everything in that direction. It's who they are. It's what they are.
> Recognising that one person who always tried to bring everyone together, calling them a Scrum Master and making room for them to do these tasks was a no-brainer.
Really cute, until you had my life and career and saw the "scrum masters" being one of the managers cousins who saw an opportunity to give them income while pretending they are useful.
In my defense, I never witnessed a managerial system that helped me, so bear with me here.
> "We're all adults here, we don't need these rules" was a wide spread sentiment, yet work was horribly inefficient.
And for the third time: maybe in your teams. I worked in no less than 6 teams that did this very, very well. To the point of us not needing a manager because I and one other guy (we were 7 in total) basically said "OK, things A / B / C are more or less done but we still need X and Y; me and Joel are busy with infra stuff, anybody wants to pick those up?" and somebody always stepped up.
Is that what a scrum master is supposed to be doing? I've never seen it though. But we managed to distribute load and responsibility between ourselves pretty well.
Predictably, that team was eventually disbanded because we had actual power during the executive meetings (me and the other guy attended them). Nobody likes programmers who can push back in an informed manner that ruins the CEO's prepared graphs and slides. Who wants their beautiful illusions shattered by facts? Not these "adults" for sure.
And yes all of us left shortly after. And yes 3 out of the 7 of us were called back some months later to fix the messes of the others. We beat the code back into shape in less than a month, charged them triple and laughed our way to the bank.
---
Bigger point is: we all know the beautiful theory. But there are people out there who don't like it and want to skew the practices to what serves their interests, not yours and not mine.
Glad that you had such a positive experience. Really. But you should be more objective and remind yourself that you are very likely privileged. Most of us are not.
Sorry for not having made this clearer, I assumed it was obvious that I was sharing my own experiences, which is why I didn't prepend "..for me" or "..in my experience" anywhere. Reading through my post I do think it's sufficiently obvious, as I am specifically mentioning how I remember certain projects.
Looking through your counterpoints I think I need to emphasise my opening sentence a bit more strongly: It was fantastic _when it was introduced bottom-up_. This is important, because the ceremonies were all engineering-driven and managers usually not present. So there was no rushing and "whipping" during the retros, there was no scrum master being the manager and everyone wanted to be done with the daily quickly, and so on.
> Really. But you should be more objective and remind yourself that you are very likely privileged. Most of us are not.
I have suffered all the bad parts of Agile much like everybody else, and a lot of what you say sounds painfully familiar. This doesn't invalidate my main point though.
> [...] over my 23 years long career.
Just as an aside, the first Scrum guide came out in 2010, and this is what in my memory created the widespread usage of Agile in general and this flavour of Agile specifically. This matches my memory that the best experiences I have made with Scrum all happened between ~2011 and ~2014.
> I have suffered all the bad parts of Agile much like everybody else, and a lot of what you say sounds painfully familiar. This doesn't invalidate my main point though.
Agreed, and apologies for the assumption. I got a little bit pissed, not at you though. :)
> Just as an aside, the first Scrum guide came out in 2010, and this is what in my memory created the widespread usage of Agile in general and this flavour of Agile specifically. This matches my memory that the best experiences I have made with Scrum all happened between ~2011 and ~2014.
Oh I know, but I believe both you and I witnessed a lot of similar techniques during our careers. At one point they just figured they'll give them a lot of names.
> Sorry for not having made this clearer, I assumed it was obvious that I was sharing my own experiences, which is why I didn't prepend "..for me" or "..in my experience" anywhere.
Yeah I know I was a bit difficult here, my idea was to bring visibility to our different bubbles. I've heard positive stories about Scrum / Agile many times but I am yet to live in one. :(
Sounds like you worked in some dysfunctional places. If things worked that bad on the communication/management level, I'm not sure any system really had a chance of working well. If you get an experience like "to slap developers into rushing even more." then the problem seems to be somewhere else and I'm not sure we can judge agile itself from this.
I've never seen a perfect place, but I'm sorry you had experiences like that. There really are places which function better and actually do friendly cooperation across levels.
> If you get an experience like "to slap developers into rushing even more." then the problem seems to be somewhere else and I'm not sure we can judge agile itself from this.
Oh, absolutely. Agreed. That's why I left several places during the course of the last 10-ish years.
> I've never seen a perfect place, but I'm sorry you had experiences like that. There really are places which function better and actually do friendly cooperation across levels.
Well, I just recently finished a limited term contract and started looking for a full-time employment (contracting is exhausting). Shout if you have anything. :) I mellowed out quite a lot in the last years and my comment above is just a triggered reaction.
If someone’s work history is littered with only dysfunctional companies, are we sure the companies are 100% of the issue?
Regional work culture is a thing and it took me a long time to start looking outside of that bubble. I was pretty stupid when it comes to work negotiations and people abused that.
Secondly, I don't think you'll find many programmers praising Scrum.
But, think what you will. I'm absolutely the villain, congratulations, you cracked the code.
¯\_(ツ)_/¯
There are numbers between 0 and 100.
Yes, and I never said 100% of my professional experiences were bad. I had extremely positive contracts that left me smiling.
What I did say was that I never stumbled upon managers who did Scrum / Agile in a way that was empowering for the programmers.
Obviously these two things are very different.
Same here. Daily stand ups (no matter if they last 5 min. or 20) have not being useful for me any single time. They are used by managers to force us to show what we have been doing the day before. No more, no less. If I ever get stuck with something, I go and ask for help to my colleagues; I update the corresponding Jira ticket status and whatever is needed to keep my work visible.
Same for retros or any other kind of ceremony. They are just for managers.
> Retrospectives have been used in my career, without failure, without a single exception, to slap developers into rushing even more. That's what all managers
Dude, no. Kick managers out of the retro. The retro is a place for uncomfortable candor between peers, not another place for your manager to hold court. They need to leave the room while you decide what’s a problem, and what is not a problem (yet). Once you have a plan on the table you can bring the boss back in to discuss the redacted summary of the meeting and any proposals that require their assistance.
They didn’t work for you because you’ve done them wrong at every single place. I’ve had to fight twice to do it right, but we won both times via solidarity.
I haven't "done" anything. They were forced on me.
I get what you're saying and with time I started fighting for something 90% the same as you are describing. But most of the time I had no choice. It was "our way or the highway".
And since I was financially and career-wise extremely stupid for most of my life and career... yeah. I worked with idiots and slave-drivers.
I am looking to finally change that by changing the way I conduct myself. You hiring? Yeah, I didn't make myself an excellent advertisement with my original comment but at least people will know where I stand.
No methodology will get good work out of bad people.
Having good people is table stakes.
I've met some pretty obnoxious and difficult programmers but statistically most managers I ever met were difficult.
So yep, agreed with your point.
Problem with hiring good people is that you also have to give them the space and time to show their talents. Shoving them into meetings mostly aimed at people who are bad at communication and/or are junior in terms of abilities is the best way to destroy their motivation.
[flagged]
> The problem is that some methodologies (Scrum, etc.) are heavily abused and transformed into management frameworks, which is the opposite of why they were created in the first place.
At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand.
Any quality work, gain in efficiencies, improvement potential, etc will be hindered by the desire to apply blindly and without creativity any given thought framework.
management is very creative, they just sometimes don't realize that agile is not a management process, it's an engineering process. it's an easy mistake to make because they want to measure engineering output somehow and introduce measurements which cause decoherence of the engineering process state if I may use a quantum analogy instead of a car one.
IOW they're trying to do their jobs (manage employees) but engineering is a high trust profession and some managers just don't have the trust (not to say that all engineers have the integrity...)
That’s because Scrum is so easy to turn into a management process. It makes more sense to them than all the other forms of Agile combined. So like children reaching for candy instead of vegetables, or who will only eat carrots as a vegetable, you have to work to make them reach for something else, otherwise they will be unhealthy.
> management is very creative
What you described, I wouldn't accept generally under my definition of creativity.
In order for creativity to be such it must ultimately deliver value; managers "doing their job" in ways which hinder instead of supporting engineers is not creative, it's disruptive.
> agile is not a management process, it's an engineering process
That's interesting - I've always thought of it slightly more broadly as a team-running process. You don't have to be doing engineering to do it; you might be building a website in Wix. You just need to iterate and inspect. What do you think?
Maybe it would be more accurate to say agile is a way of doing things, not a way of managing people.
yeah I completely agree, well put; I also like the sibling's 'process of making/doing things'.
> At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand.
I think most commenters on HN understand this.
But then what problem does capital-A Agile solve? It was meant to surface problems faster and empower people in teams, and benefit the customer, avoiding waste and nasty surprises. Yet we've seen enough horror stories in these past decades to understand Agile (Scrum et al) can fail just just as often and is as prone to mismanagement and meddling as the methods it was meant to replace.
It takes a strong team (leadership and stakeholders included) to make Agile work and reap its benefits. But such a strong team will probably work well with whatever methodology -- strong teams are effective regardless.
What about average teams, which Agile was supposed to be helping? In my experience, they'll fail just as often.
A method that works for a team of focused superheroes is not really applicable to the general population of developers.
Capital-A Agile is for companies that want the benefits of agile (higher velocity) but don’t want to trust their employees or make any meaningful changes in how the management team operates (micromanagement, committing to rigid feature scopes on rigid schedules).
Obviously this doesn’t increase work but companies get to say they are “agile” and the management team gets to keep doing all the counterproductive management they were doing before. No hard conversations about changing how management operates or unpredictable things like giving engineers autonomy.
This sounds cynical on its face but it is my experience as well. Management does not actually trust engineers to provide value without close oversight (sometimes with good reason!), so any framework that purports to give engineers more autonomy will eventually be subverted by the management. And since management always has more power than line engineering, they always win.
The only way for "true" agile to really take root would be for management to trust engineering to add more value on their own than when being micromanaged. That's a tall order, and gets much taller in larger organizations.
Agile is not there for higher velocity! It is sold to management that way often, but intrinsically - no.
Agile though is meant to reduce waste. In other words, you don't march faster, but are supposed to spend more time marching in the right direction. (I personally loathe agile and find it intrinsically broken.. I just find it kind of funny that a process oriented around dynamic environments is supposed to give predictability and speed, when it gives neither. If anything, a lack of predictability since direction can change)
I think there's some truth that process slows down development. (Full disclosure, I work for a company in the same space as these folks.)
I love a provocative essay as much as the next person.
But the authors are in a relatively new, smaller company focusing on devtools[0]. This has a couple of ramifications related to process need:
- they are the customer to a great extent, so they don't need to involve external customers to discover what is needed.
- they are fast followers (an OSS WorkOS competitor[1]), so can rely on product need discovery from other competitors. That's not a bad thing (I've done the same!), but it isn't sustainable forever.
- they have a small team, which means everyone has autonomy and knowledge.
- at the size of 2, they don't have other departments with schedules and deadlines and goals. Process is critical to getting input and coordinating across departments to achieve company goals.
All of these factors mean process is an impediment without any benefit.
Not every company is like this company. Not every dev team is like this dev team. My opinion is that this company in three years won't be like this company is now.
I'd wager that in 3 years, if ssoready is successful, there'll be process. It'll be an impediment but a necessary one, as the attributes they currently have won't be enough to keep delivering.
Happy to bet on that if either Ned or Ulysse is reading :)
0: According to https://www.ycombinator.com/companies/ssoready they were founded in 2023 and have 2 employees.
1: https://news.ycombinator.com/item?id=41111136
Every team has process. It doesn't matter if it's documented or not, or whether improvements (or impediments) are intentional or not. Every team has their process.
Source: Identifying teams' principles and practices is one of the tools I use.
Agile, in practice, has turned into "disorganized waterfall." Witness absurdities like the existence of the "Agile Gantt Chart for Jira." The reason Waterfall, or modern Agile, are the way they are, is that they are systems that allows the smallest possible number of people to take responsibility, while allowing everyone to perform accountability. Basically nobody wants to lay it on the line and say to the CTO, "I'm going to make this project succeed." Much easier to say, "we're using best practices and modern processes."
This is a consequence of failing to train managers, especially in the moral dimension of management, which is entirely about accepting responsibility, and of promoting into management individuals who are not prepared to do so.
It turns out for large cross-team initiatives, organizing the work is as hard as doing it.
I like the example of internationalization. You need involvement from all parts of the product to release it - you rarely can sell a half-internationalized product. You need to work with external teams of translators who need to be fed the work in a consistent interface. There will be pieces of the work that nobody is going to forsee (e.g. pulling text from the database) that will be surfaced and handled consistently.
So, to get it out, you need to have each team prioritize the work. You effectively need a deadline, or the work will never happen. (The work is valuable for the company, but does not drive any individual team's customers.) You will have dependencies: Team A has to address part of the work before team B can. And you need a way for teams to report that they are done so that it can be reviewed for consistency across the product.
This is a bad fit for most agile methodologies, but you're not going to take everyone out of it temporarily and then go back in. So you have to accommodate a project within your system.
But these exceptions become more and more common as your company gets bigger and bigger. The only truth that I can find is that the only way to stay agile is to stay small: small teams naturally do the things that are agile.
> Well, right from the Agile manifesto
The Agile manifesto is great. It is simple, straightforward, and most importantly, it clearly defines itself as a statement of opinion, with a counterpart to each of its value. And yet so many people do exactly what the manifesto tells them not do to. Why? Just why? It is as if a clothing brand has "beach and sun over mountain and snow" as its value and people go to ski with them and complain that they get cold.
Agile is not on size fits all, sometimes you need comprehensive documentation for instance. In this case, just don't do Agile, the manifesto is really explicit in that it is not the right methodology for you. But for some reason, Agile is fashionable, so you take it anyways and try reshape it into the V-model you should have used in the first place and get the worst of both.
> And yet so many people do exactly what the manifesto tells them not do to. Why? Just why?
The manager on the top says "do Agile" because his friends say that this is now the cool thing. The managers on the bottom have no idea what it means, so they do some random thing and call it "Agile", and report job done. The manager on the top is happy and gives them a small bonus.
And as managers circulate across companies, they keep introducing the "random thing we did at my previous job and called it Agile" as the one true Agile, so the whole randomness converges to one specific version (with Jira and long meetings and other stuff).
Much of this has, I think, to do with mutuality. If person A and person B need to work together both need to change their preferred way of working to accommodate each other. In larger groups there is a problem if one person gets to decide on too much and does not have to take other people seriously.
And that usually breaks, as another reply said, when the manager of the two people delegates responsibility for the problem getting solved to one of those two people instead of keeping it for themselves.
If you have a boss who cares whether the task gets done, you can’t make excuses about how it violates your moat to have to do it. Shut up and help your coworker. Now. Or you’re on PIP.
The coworker who isn’t getting useful collaboration gets blamed for their soft skills, when it’s the boss’s soft skills that should have reigned over both.
Parent is close to what I argued here:
https://zwischenzugs.com/2017/10/15/my-20-year-experience-of...
Any extreme has it's own inefficiencies.
Take a hopelessly disorganized team, apply any, literally any, management framework on top of that team and productivity will increase.
Since management frameworks do not contain intrinsic fixpoints, keep applying the framework and things will halt to a stop, because whole effort will be spent serving the framework. Ditch the framework, start doing random stuff and productivity will magically increase.
The pendulum continues to swing, unbothered.
well observed. Why do we keep going in cycle?
I think because there are lots of different type of humans.
The motivated developer. The descipline strict developer. The unfocused. The learner. The over the line stepper who wants more. etc
One process can not serve them all.
I think also because we’re not all that great at solving human problems.
I can run code and we can agree what it does or doesn’t do.
But when we decide it is time to organize humans and understand the results we struggle.
> I wonder how we can break the cycle.
Make management consulting illegal.
All developers know all the wisdom. Everyone who had a manager knows the problems in any process.
The only ones who seem to not know or see or understand the problems are various layers of management. This is weird because ostensibly that is their one job.
I can understand how a junior manager who only worked one year in the industry can get fooled into believing in the rigid processes with pointless artifacts.
But if you worked building software for five or even two or three years, I cannot possibly imagine how one goes about their day managing a software project in this fantasy land.
By “manager” I mean all the chickens that decide how the pigs work, and all the chicken in pigs clothing. I do not mean all kinds of management.
I agree, it’s a new/old methodology disguised in a rant.
To your last point that we’ve come full circle.
Maybe that’s exactly how things evolve. Start small, get large and complex, cut back to become simple again.
While it might sound like a circle, I believe that it’s an evolution. Things improve over time with each iteration.
> we’ve come full circle.
We never went anywhere. I had such high hopes for the agile manifesto when I first read it in 1999. "Whew," I though, "finally, they realize that software can't be managed like an automobile assembly line." Nope, they just rebranded the "manage software like an automobile assembly line" methodology as... AGILE! Don't get me wrong - the signatories on the agile manifesto did seem to understand how to realistically plan and manage software. Nobody else who read it and had any position of authority seemed to.
> Maybe that’s exactly how things evolve. Start small, get large and complex, cut back to become simple again.
I like to think it is! Two steps forward, one step back, but overall advancing slowly.
There is no breaking cycles. Humanity is on an approximately periodic 20-year oscillation around the mean. Just look at programming languages, ai cycles, web iterations, etc.
It's just human nature - we deplore the tools our parents used.
However, as long as that mean drifts in the right direction!
If your team has high alignment on what needs to be done and how to do it, then yeah, no processes are needed.
But if you ever want to hire more than a handful of engineers, you need to processes to train them up and build alignment.
I can't even imagine how Scrum could ever align with the Agile values for it to be abused and transformed. IMO, that part is impossible, and Scrum was always a "bad-management by the numbers" framework.
Anyway, I've hear phrases like your example since some time around 2001. Agile was practically born with a parasitic consulting market intent on having the one true way to do it, and that way being what middle-managers adept of micro-managing want it to be. In fact, I think those consultants were the ones that pushed the word around, without them we wouldn't even have heard of the manifesto.
That's to say that, yeah, I do agree with your comment, but the actual problem is deeper, and harder to fix. Scrum and bad processes are just symptoms here.
> I wonder how we can break the cycle
"Hire former software engineers at management positions" would be the answer, but of course there are various factors that makes it difficult to do so.
In theory, management should be held accountable for getting in a way, but it is not possible either because of the nature of software development: one cannot really measure productivity because it is to a more-or-less large extent a research activity.
I think probably the best option is to introduce some more democracy (or rather "technocracy" in the literal sense, "power to those who build") in the mix: management evaluated and chosen by the engineers. Call me communist all you want...
I didn't take the article as a "lack of organization" is best. I took the overall theme as that most methodologies are a distraction to what is most important, building things.
The fundamental issue, I think, is that there is a strong tendency for management to value process (measurable) over progress (often seems like nothing for weeks or months and then bam out of “nowhere” revolutionary new features.
Agile, scrum, etc al are supposed to be guidelines for engineering teams to maintain coherence on progress, but they describe a process, so inevitably management either interjects in the process, tries to use it as a handle to control the process, or pulls engineers out of the project to “manage” the process… all at the expense of progress.
Management can’t see progress, but they can see process. So naturally, they become focused on what they can see, and conflate the process for progress.
What is BS is a fixed, one size fits all methodology. As fast as you write it down and proclaim „this is out procces”, it starts to be BS.
If consultants start selling it as a packaged methodology, you can be certain it's BS.
> So it sounds like we've come full circle.
I think the issue with Agile was that it was named. After something is named and codified it becomes a thing and everyone can mangle the thing to fit their desires until it becomes antithesis of the initial intents.
This guy doesn't name or codify his approach. So it's fine, there are only intents, there's barely anything to mangle.
> But do you know how Agile was invented? It was a group of software developers, tired of heavy management processes, who came together to decide how to make their processes lightweight.
Agile is agile the same way the People’s Democratic Republic of Korea is a democracy. And like most dictatorships with these names, I’m sure they also have a founding myth that claims a genuine concern for Democracy and the People.
Software developers are concerned with developing software. The people with the time and energy to develop and sell methodologies like Agile are not in the business of developing software; they’re in the business of selling methodologies. Maybe they’re consultants trying to sell clients on the methodology as a selling point for their consultancy (much of Agile seems geared to this), or maybe they’re trying to train people to be Certified Scrum Masters or whatever. Either way, you can’t actually sell people a methodology that boils down to reducing methodology because then you have nothing to sell.
I know I sound cynical, but the reality is that human behavior is driven by incentives and anyone who genuinely cared about making processes lightweight has little incentive to hang around the Agile scene fighting with the grifters.
> The point being made is "methodology is bullshit," yet what is proposed is exactly that: a new methodology.
Nailed it. “Your heuristic is bullshit, here have a heuristic to know when.”
Basically, I agree … but …
In my experience, to successfully reduce process, you need to have really good people.
That usually means a heterogeneous mix of skilled, smart, experienced, and creative people that work well as a team, and teams like that, don’t come easily.
People (and teams) are really important, and I believe it’s a mistake to think of them as some kind of interchangeable modules (as is the norm in the tech industry, these days).
So good management is critical. Keeping staff for long periods of time is also critical. If you have a lot of turnover, you need process to regulate the churn. Long-term employees don’t need to be told what to do, in triplicate, every day. They Just Know, and that “tribal knowledge” is the real key. Also, people that have worked together for a long time have significantly reduced communication overhead. A lot of stuff doesn’t need to be said or written down.
This goes double, when working at scale.
All that said, I used to work for a corporation that treated Process as a religion.
They make really, really good stuff (at scale), but the overhead can be unbearable.
They still make good stuff, though, and I haven’t seen anything close, come from less process-driven outfits. Their competitors have just as much process.
I wrote a piece called “Concrete Galoshes”[0], some time ago, that talks about this.
[0] https://littlegreenviper.com/concrete-galoshes/
That's the thing all these "easy bake recipe for success" blog posts miss: it's all about the people. I've been in companies with the exact same processes and wildly different outcomes because staff was more competent (which includes soft skills) and experienced.
But that is anathema to tech companies that think having the right X (agile, Spotify guilds, kanban, etc.) will fix everything because that's what they sell to end users.
These rigid processes and ceremonies are the mcdonalds approach. You can get a group of unskilled randos and produce passable slop (e.g. MS Teams). The problem is that people with actual skill suffocate in such an environment.
If you have a crappy team and only light processes, you get garbage.
If you have a crappy team and heavy processes, you get barely passable results.
If you have a good team and only light processes, you get great results.
If you have a good team and heavy processes, you get barely passable results.
It's worth bearing in mind that as much as we don't like it, a lot of the time the goal is passable slop. Mcdonalds is doing well, and they arent focussing on increasing the quality of their slop unless theres some public outcry.
This is true.
I once read a comment, here, that said, "If the code quality on your MVP doesn't physically disgust you, you're probably focusing on code quality too much."
I think that sort of sums up the zeitgeist. I'm also not a fan of the MVP Model. I don't think it results in good work.
maybe it should be prepended with 'if you work in the mcdonalds of software development companies'
I was extremely fortunate, and managed a team of really experienced and good developers.
Unfortunately, the company I worked for, worshipped Process, so, as their manager, I spent a great deal of time, shielding them from that overhead. This did not always win me praise from my managers.
But we got pretty damn good work done. Sadly, it was "engine" code, and was often shipped in "passable" UX.
Kind of like dropping an F1 engine into a beater Chevy Vega.
That does raise the question of what those tech companies' motivation really are though.
The processes you described would work really well if the goal is to meet a hiring target and ship just enough product that marketing and sales can run with it.
If they don't necessarily care about quality of end product or quality of the engineering that went into, throwing heavy process at the team may get them there just fine. That heavy process may even work better for them if the goal is more managerial control to meet sales and marketing deadlines.
Agile Manifesto was invented by consultants / contractors to make better products for their customers at a good price, not by ivory tower engineers building Platonically ideal software.
Sure, I don't disagree there. In context I was replying to a comment about how big tech companies use agile and similar though.
I do agree though, when used in the specific context of consulting it may be a better fit than in a big tech corporation.
> But that is anathema to tech companies
One of the biggest dangers in business is believing your own PR. And yet tech companies do it over, and over, and over again.
Largely agree. Heavy process is a tool to help less skilled people have output more comparable to more skilled people. But it comes at a cost of making more skilled people less productive. If you can hire small numbers of highly skilled people you can accomplish a lot with little process. Sadly at some scale “hire only really skilled people” becomes basically impossible and process needs to be more heavy to account for that.
Scrum seems to be more about helping a manager of less skilled/experienced people get more output from them.
As people become more familiar with agile processes in general (we all say we are “doing scrum” but we are also doing more than half of XP - otherwise a scrum doesn’t work at all) those gains diminish and I think among us we can agree they go negative.
This. If you have good people, it really doesn't matter what process you use. If you don't have good people, well, it really doesn't matter then, either...
This is very true, and I second the importance of long tenure. There is no substitute for it; it helps with product experience, personal relationships, and organizational knowledge.
> In my experience, to successfully reduce process, you need to have really good people.
Yes, but...
Don't all of these Agile methodologies predicate their success on having at least a decent proportion of really good people (including stakeholders!) in the team?
Real Agile, yes (look at the pedigrees of the signatories on The Manifesto).
In my experience, modern SV companies are obsessed with hiring armies of short-term, barely-qualified LeetCoders.
They sell dross. It would be a problem, if people didn't buy it, but people don't seem to mind, paying for crap.
I worked for a company that did really good (and expensive) stuff.
They are struggling, these days.
Once again, you have no idea what you're talking about.
Sigh ...
Normally, I ignore obvious troll comments, but I do have respect for your expertise, so I'd like to ask for some enlightenment. If I'm wrong, the only way to find out, is to ask how.
Thanks!
Good stuff in here, but be cautioned that the author doesn’t mention their customers are engineers until a bit later in. Which gives a lot more leeway in allowing engineers to make a majority of decisions.
In a more complex domain, like maybe selling private securities, collaboration isn’t slow, it helps us not get fined millions of dollars by the SEC.
Personally, I also love minimalist process and likewise believe “methodology” is bullshit, but I caution you, the reader, to consider the specifics of the context you’re working in.
For me, that means that almost everything goes figma first. Engineers + product work together to build a figma, which allows other parties to see what we’re building and contribute in a tangible and useful way.
I'm in a large corp as bridge between development and the business. What i do is minimize process on the dev side, and maximize it on the org side. On the dev side my only ask is predictability, which is hard enough already, but is so important for communication. On the org side, i overengineered process. It focusses on value, and helps to keep chaos away from the developers.
That's genius. Let the workers work and keep busybodies with busywork.
Most domains lie somewhere between serving engineers and doing something really complex and sensitive. It's always a nice goal for your engineers to gain significant proficiency in the product domain, so they don't have to defer all decisions to other people. It's a "cache miss" equivalent in product development process.
Yes exactly. The engineers as users part is important IMHO. I would also really like to see how this whole thing pans out in the long term.
You can still have domain experts collaborate directly with engineers instead of adding a middleman in the form of a product manager.
The more I work, the more I'm convinced that product management is not truly a profession but rather a way for non-technical people to insert themselves into a profitable industry.
This might make sense from a high level, but again, the devil is in the details.
Realistically you do need someone (vendor or not) to translate 1000's of pages of legal jargon into actual product decisions. There's a tipping point where paying an engineer $x or $y to do that themselves (if they even have the skill to interpret it) is waste of talent.
Your product decisions are hidden in thousands of pages of legal jargon?
I only lurk HN but seems that comments such as these are becoming commonplace now.
Why the accusatory and negative tone? How does this contribute to the discussion in a meaningful way at all?
The point of a product manager is to make a lot of decisions that don't have a clear answer. "Should we use websockets or REST for our chat client?" - easy technical call. "Which market segment should we target with our features?" - not so technical.
There are plenty of technical decisions that don't have a clear answer (e.g. which of 1000 web frameworks should we use?), and plenty of product decisions that do. The separation between roles has nothing to do with clarity but with the (sometimes fuzzy) difference between technical decisions and product decisions.
> e.g. which of 1000 web frameworks should we use?
This is fuzzy, but that's because it's not a technical question! It's isomorphic to "what three blog posts on web frameworks did I last read?" (-:
You're right that decisions regarding frameworks are often made for largely arational reasons, but I'm baffled by the claim that these are not technical decisions (unless you're just joking?). If they're not, does that mean that in your model it's the PM who decides which web framework and database the team uses?
In any case, even if my example were a bad example for some reason, there are definitely lots of technical decisions that are fuzzy. How could there not be?
Oh yes, I agree that there are technical decisions are fuzzy. I'm happy to concede that; just dashed it off too quickly.
While the domain of e.g. private securities may be complex, this usually isn't the main problem for developers; I'd argue this article isn't about legal requirements and the like so much, but about the actual implementation thereof. In the case of a complex domain, stick to writing the requirements and don't try and invent new things or what-ifs, because those may end up causing those legal issues.
That said, the reality is that a lot of developers are also expected to be domain experts and work independently, including knowing a lot of the legal requirements. More in my field, that's stuff like GDPR and A11y compliance (WCAG 2.2 level AA will be a legal requirement for most companies come 2025, see the European Accessibility Act [0])
[0] https://ec.europa.eu/social/main.jsp?catId=1202&intPageId=55...
>I'd argue this article isn't about legal requirements and the like so much
Yes, it fails to address that other businesses face additional complexity and constraints that they don't have and then broadly over-prescribed their principles.
I'm genuinely curious how you're separating "legal requirements" from "implementation" (of either product, or process). When you build things, you have constraints, and you have to respect those constraints, or you built something lousy. If understanding those constraints is part of the building process, then trying to find the fastest way to incorporate those constraints into the product while minimizing time this blocks product development (and thus, velocity), seems like the obvious thing to optimize for. So I don't understand how you're trying to separate those (and to to be overly clear, I'm asking out of genuine curiosity to understand your point better).
> Engineers + product work together to build a figma
I'm not going to tell you that what works for you doesn't work for you, but just to contribute another perspective, elaborate Figma mockups are a bit of a red flag for me. They show that a significant amount of time has been invested in a high-fidelity design of a complex UI that has never once been used do to any actual work. It's impossible to know if a UI is any good if you haven't used it in anger. A rough functional prototype might take longer to make (and, crucially, doesn't look as good in company-internal slide presentations), but it's vastly more valuable IMHO.
That’s a good point. The figmas we build are not high fidelity. But they’re more than wireframes. The point is to get everyone on the same page conceptually as to what is going to be built, but the details are still left as an iterative process for the engineer implementing.
The point of the figma is to answer the question “what visuals will help ops, legal, and engineers be on the same page when discussing” and NOT “the button should be 48px down”. UX specific “extras” like confirmation modals, etc. are never added because that doesn’t answer the first question.
The missing context here is that their company looks to be a very small team - 5 employees according to LinkedIn.
Any process or methodology, or lack of, will work for a small sized company. At that size you get things done by just talking with each other. That doesn't scale to companies with hundreds or thousands of employees where multiple teams that you've never interacted with before may be involved in a project. These "throw out the processes and methodologies" articles are always written by people at small companies. Once they grow, they'll implement the same processes that everyone else uses to solve the problem of becoming too chaotic.
> These "throw out the processes and methodologies" articles are always written by people at small companies.
That's great advice then! HN is mostly comprised of people looking for tips on how to go from 0 to 1, not to 0 to 100.
> Most companies assign requirements, assert a deadline, and treat quality as an output. We tend to do the opposite. Given a standard of quality, what can we ship in 60 days?
This sounds like the Six Week Cycles and "Fixed time, variable scope" from Shape Up: https://basecamp.com/shapeup/1.2-chapter-03#fixed-time-varia...
They're absolutely describing Shape Up, but without agreeing on what the valuable things are to build - apparently engineers can figure all that out by themselves. I have my doubts.
Although not exactly the same, this is very reminiscent of Spolsky's "Big Macs vs. The Naked Chef" (2001) [0] where he explained:
> What’s the moral of the story? Beware of Methodologies. They are a great way to bring everyone up to a dismal, but passable, level of performance, but at the same time, they are aggravating to more talented people who chafe at the restrictions that are placed on them. It’s pretty obvious to me that a talented chef is not going to be happy making burgers at McDonald’s, precisely because of McDonald’s rules. So why do IT consultants brag so much about their methodologies? (Beats me.)
https://www.joelonsoftware.com/2001/01/18/big-macs-vs-the-na...*
I really enjoyed this. I try to run my team similarly.
Where I disagree slightly is vendors. If the need filled by the vendor is well-defined and low-complexity, sure, I'll go for it. Otherwise, I'm doing it in-house nine times out of ten.
Where this starts to get tricky is when some worthy competitors emerge, utilizing your foundation to scale quicker and more effectively. Then you might wish you had hired more people earlier. But overall, I think starting from this perspective is a lot safer than the opposite.
> Our customers are engineers, so we generally expect that our engineers can handle product, design, and all the rest. We don’t need to have a whole committee weighing in.
This is the reason you have the luxury of this approach, engineers tend not to care as much about the "little things", but average users, especially enterprise users, rely heavily on the little pieces of experience that make tech palatable to them.
Sounds like this company is small. The processes the author discards have their place. His article more or less sounds like “our customers want a small hole dug, we don’t need to a whole excavator for that - just shovels”.
The reason larger companies write prds, figma mocks, etc is to get alignment across more people that are detached from your individual thing
At a small company you don’t need that. Everyone is working on one main work stream
At larger companies, there’s hundreds or thousands of important projects at one time and lots of supporting teams for those. Everyone has their own shit to worry about and can’t possibly remember all the context on your projects, so you make it clear as possible to quickly bring disassociated people up to speed on why it’s important and what you need from them
It also helps disassociated leadership buy into your ideas. A picture is worth a thousand words.
These guys do security software.
You don't find out if security software is badly broken until you're attacked.
Up to a point, sure. But it's definitely a field full of "unknown unknowns", and I don't envy them. That said, good architecture and principles are important, which is why for example *nix has a better security track record than older Windows versions.
That's a good point. I imagine this advice would be actively bad advice for building more complicated things (e.g. an IDE, perhaps a game, a turbotax alternative).
Part of the skill of engineering is knowing when you need to do upfront engineering and when you can just throw some code at the wall.
This works if a project is doable with a small team of smart/experienced people -- if it isn't then the methodologies become important
On any sufficiently complex piece of engineering -- using vendors to accelerate progress works until it doesn't -- there is usually a point very early in a product lifecycle where that starts to constrain progress/agility or limit feature development ... then there is another point later where it starts to bite financially ... then a point where the vendor gets acquired or ceases supporting it
> Most companies assign requirements, assert a deadline, and treat quality as an output. We tend to do the opposite. Given a standard of quality, what can we ship in 60 days?
Also, work tends to expand to occupy alloted time. That is, if you tell someone they have 60 days to finish a task that could be done in a week, most often than not people will use 60 days.
So by not limiting what should be done in 60 days, they are more likely to avoid this pitfall.
> That is, if you tell someone they have 60 days to finish a task that could be done in a week, most often than not people will use 60 days.
This happens in mostly too situations:
- the person has absolutely no stakes in the game, and you are the only one caring whether it takes 60 days or not. Typically if you are paying them based on their hours worked as a contractor.
- The person understands that the task or the deadline is bullshit and nothing will important will happen whether it's finished in 60 days or not.
Either way, it's never a great situation IMHO.
I've found that people who do this have just told your company they are not worth the money to employ them, and they go in the next downsize. If the sixty days is enforced by being the actual deadline, all the important steps (documentation, testing, future-proofing, extensibility, simplicity of design, etc.) should be done, along with a new set of custom tools to make the same type of job take a week next time it is asked for. By somebody else if necessary. Ironically (?) the best developers build their own redundancy into their work. I developed in a way that allowed another person to get up to speed and take over my work. It informs good design, coding and documentation. I kept that job for over twenty years with several downsizing episodes. Sorry this sounds like gloating, but it was a technique that worked, so I thought I'd share.
RE "small problems": I would be very curious to know what the top 3 principles are for this team. What are the three things that _never_ fall into small problems? Security was mentioned, but what else is their non negotiable?
To be honest I have a hard time squaring "security is important" with "we write idiot mode code all the time" and "we don't write design docs". I do believe some people can just naturally, from the ether, pull out things that are designed "correctly" from the outset. But my impression is that if you're caring about security, then you need to have some established patterns for how to deal with stuff.
Not talking about SOLID so much as just, on an API design level, having things that are hard to mis-use and the like. And seems hard to land on that without some levels of discussion. But maybe the small team is actually micro-iterating at such a level that this does not matter!
"No silver bullet" usually holds true. The same methodology might make an inexperienced team productive AND be an impediment for an experienced one.
So, move fast and break things. (aka Facebook's motto before they changed it to "move fast with stable infrastructure")
HN clickbait is HN clickbait
I love The Rise of Worse is better, and this sounds just like that:
https://www.dreamsongs.com/RiseOfWorseIsBetter.html
It doesn't explain _why_ simple implementation is more important than having a simple interface, but it just makes an observation that simple implementation usually wins.
In my experiments simple implementation won for velocity, because quite often I need to change small parts in all the implementation no matter how modular / reusable code I'm trying to write.
As my velocity increases testing becomes more important as well (especially integration testing), as there are more features interacting in a small amount of code.
This really hinges on 'velocity':
> .. simple implementation won for velocity ..
How do you specifically define velocity in this context?
(I am asking because I tend to favor speedy velocity in quick iterations; which is another story, than say velocity for change...)
Kind regards
Sure, it's the speed of adding a new incremental simple feature to the existing code base.
Ironic that the article said:
> A wrong lesson is to take the parable literally and to conclude that C is the right vehicle for AI software. The 50%
Now we use Python to glue C code to train the best AIs of this time.
My friends and I believe these are more people-problem than anything else. If we iterate at solving that people-problem as much as possible; introduction of patterns, processes, etc., will eventually lead to better work results.
For instance, even if a team has the best-intentioned tools such as Project Management, CRM, Wiki, Documentation, etc., if the teams do not use them well, they are always bad tools.
Separating toolings (including all of the methodologies) from the ways and the culture of how a team works will be more beneficial to the team and, hence, benefit the company.
> Pay vendors to do it
Generally I agree with this for 90% of startups. If it's a solved problem, you should not be doing it. Don't reinvent wheels just pick wheels off the street and use them. Then an axel then a frame, etc etc until you've got something that moves because it's literally held together by zipties.
The key is that a number of people are willing to pay you for the moving ziptie vehicle because it solves their particular problem - whatever it is.
Most recently I tried Cursor app. it helps me be a faster coder and uses something i already know - i really like it (except that they shit all over the hotkey bindings).
The line that surprises me:
> Of course, using a vendor has significant upfront costs – these things are usually pretty expensive. It also restricts our freedom a bit.
I recall I don't know Rick meme instantly. It is obviously contrary. Always doing something on your own is the most expensive way, in my opinion.
Ouch. I guess you never did one of those "we brought large-software-X, and are in 2/3 of the way to implement it; we just need you to plug you in-house software-Y to it" projects, where you end up reimplementing every single feature from X into Y and make people give-up on the brought software before the vendor finishes installing it or allows you to see the documentation on how to plug anything into it.
Those are so common that I think they are the majoritarian way any large software is brought.
The biggest midwit vibe is throwing everything out when the pendulum swings to no process mode and then adding a whole bunch of process/methodology when that doesn't work.
This is 4 year cycle tied to economic conditions
Moderation is key
They seem to really prioritize “just works”. I am currently reviewing a PR that assembles some code as a string, using a CSV with carefully named columns. It does, in fact , work on the example CSV. I would invite this team to approve and support that for me over the next 5 years.
Absolutely on point and matches my experience (20+ years in software). The hard part is not software delivery; the hard part is stopping all the unnecessary technology and process and people inexorably creeping into everything everywhere.
Who does this apply to? Idiot mode doesn't make sense in the long run, does it mean they skip tests? Do they only build fragile stuff? Is there API easy to work with?
Idiot mode just means that if the job is to turn some bits into some other bits, you just write a function to do that. You don't make a whole business taxonomy in a UML class diagram first or worry about the single responsibility of the function or whatever.
Here we go again. The golden rule I've come to realise is that people don't like what they don't understand. It's made very clear this person doesn't like methodologies.
I don't get the use of midwit meme here. Either you're implying that you're preaching the the choir, in which case it's just an echo chamber, or you're calling your audience idiots. Neither outcome is great.
There's always a balance. Being overly orthodox about methodology is suboptimal, yet equally, having no guard rails when people need them is equally as bad. Going around expecting everyone to work exactly how you work is not the reality and tends to lead you down one path.
> Given a standard of quality, what can we ship in 60 days?
Others have said it, this is a methodology, and quite an aggressive one that causes a lot of questions to be asked, and if you don't, you'll end up in a mess. It requires planning, discussion, size estimation, design, maybe even prioritization (if you have two things that each take 45 days, one needs cutting and a 15 day one needs picking up, or you need to cut the scope down to 30 days each, and so on).
I get it, people are bored of being managed to an inch of their lives, but I'm going to be contrarian here:
We need to grow up as an industry a bit on this one.
If you walk onto a construction site, you will see methodologies. The methods you see will not be the same ones as you might have used to build a lego house, or even a sandcastle on a beach. There will be Gaant charts, and project managers, and discussions, and plans, and estimates, and meetings. They do all that, because they don't want the building to fall down. These methods give us some assurances that the right things are happening in the right order and at the end, the building will function as designed and not kill anyone.
When you walk into Airbus (let's leave Boeing to one side on this one), they aren't sat around making paper planes or models like they did when they were kids. They're not throwing designs together as they feel like it: there are methods, projects, and people to co-ordinate them. They do this because they want to be sure that the aircraft they build do not fall apart, even in marginal conditions they could have accounted for.
Yet, for some reason, perhaps because its an industry where people first get involved in coding as a hobby, or for personal fulfillment, or some other personal reason, we seem to reject all this.
We all want to be left alone, artisans in our attics, cutting the code we want to cut, for the features we think are needed, the way we want to build them, because we're special, and managers "don't understand".
Perhaps even worse, many people really learn the fundamentals of the industry from academic applied mathematicians, who think the work is thinking alone in an office, writing a paper and occasionally teaching people - this isn't how software is built in industry. We have much to learn from professors of computer science, but we should not model our work behavior on their work behavior.
The software we build can really hurt people. We owe it to others that we actually engineer it, not just hack it. Our software can easily do a bad enough job that the company - or customers' companies - fail and people lose their jobs. In some cases, failing to ship on time, or to a good enough quality might lead to even bigger consequences, up to and including death.
There is an entire subsection of the industry pointing out the security risks created by software badly designed and badly built, due to a lack of engineering talent and appropriate oversight. We should all want to fix that, and I don't believe letting engineers sit in corner ignoring basic engineering best practices is going to be a successful path to that outcome.
We need to be more like the construction sites, the aircraft builders, the ship yards submarines get built in, the real grown-up engineering disciplines. We need to come down from our little pillars and talk to people about what needs doing, and by when, and then have adult conversations about constraints and risks.
Nobody wants everyone in meetings all day. Perhaps those conversations are weighted more heavily towards more senior engineers, which is what happens in most industries outside of software. Nobody wants to be micro-managed, but at the same time it is reasonable for the people paying you many multiples of the national median salary to ask you what it is you're doing right now, if you're blocked, and what you plan to work on next - and make suggestions about changing that plan if the company paying you needs you to change that plan.
I agree that the agile certifications need to go - or radically change - and that engineers need to be trusted more, but trust is earned. The constant push back on anything that looks like reasonable organization to any other industry or to any manager, makes the industry as a whole - and those who shout the most about the pain of it all - lose trust in the eyes of the people who we need to invest in it.
We just need to grow up, stop pretending that what worked when we were making sandcastles works for employers, and look to successful engineering disciplines away from software and learn from them.
But most software out there is built with heavy processes? SAFe and all that nonsense, and everyone agrees the output is complete garbage. The software that is lauded and praised tends to be made by small teams of highly skilled engineers, stuff like EmberGen.
To me what this says is that software is not, at all, like other engineering disciplines. Software developers aren't like masons, we're not just mixing cement, there's more to it than that. You can add more masons to a construction work and it will most likely go faster. Add more devs to a project and most likely it'll go slower.
Everybody uses methodology and processes, being it explicit or implicit, cool or not, written or tribal-transmited.
We tend to go to the other side of the pendulum when something disgusts us but there's no single company without it's own methodology. Even the most "we're code punks" expect their team to work in some specific way.
"Extremes are bullshit". And some articles nonsense.
While I can get behind a lot of points in this post like "what can we do well in 60 days?" and "some problems aren't important," I shudder a little when I see that headline, when I note that the company provides SSO for enterprises, and when I then wonder about their test and QA pipeline.
"Word"
at least part of it smells like bullshits
[dead]
[dead]
[dead]