alt Hacker NewsPrinciples for product velocity
Comments
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.
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.
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?
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...
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.
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
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
> 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.
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!
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
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.
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.
> 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).
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?
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.
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.
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.
> 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
[dead]
[dead]
[dead]
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.