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.
> 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...)
> 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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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...
> 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?
> 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.
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.
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.
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?
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.
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.
> 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.
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.
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.
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.
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
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.
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.
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.
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).
> 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!
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.
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.
> 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.
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.
> 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...)
> 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.
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.
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.
¯\_(ツ)_/¯
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.
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.
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.
Parent is close to what I argued here:
https://zwischenzugs.com/2017/10/15/my-20-year-experience-of...
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.
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 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.
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.
> 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.”
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.
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.
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...
> 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.
> 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.
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.
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.
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.
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?
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.
> 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.
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.
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.
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.
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
These guys do security software.
You don't find out if security software is badly broken until you're attacked.
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.
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.
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.
> 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.
> 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.
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.
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.
> 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.
"Word"
at least part of it smells like bullshits