11–20 of 138 posts
These guys do security software. You don't find out if security software is badly broken until you're attacked.
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 “…
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!
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.
> 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…
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.
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…
> 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…
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
Earlier quoted context omitted.
You can still have domain experts collaborate directly with engineers instead of adding a middleman in the form of a product manager. The more I work, the more I'm convinced that product management is not truly a profession but rather a way for non-technical people to insert themselves into a profitable industry.
This might make sense from a high level, but again, the devil is in the details. Realistically you do need someone (vendor or not) to translate 1000's of pages of legal jargon into actual product decisions. There's a tipping point where paying an engineer $x or $y to do that themselves (if they even have the skill to interpret it) is waste of talent.
The point 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.