8 ms·

Principles for product velocity

226 points by noleary 2y ago

hahahacorn 2y ago
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.
- ks84 2y ago
  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.
- tmarice 2y ago
  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.
  - deviation 2y ago
    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.
    - Xss3 2y ago
      Your product decisions are hidden in thousands of pages of legal jargon?
      - capitalatrisk 2y ago
        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?
  - robertlagrant 2y ago
    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.
    - foldr 2y ago
      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.
      - robertlagrant 2y ago
        > 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?" (-:
        foldr 2y ago
        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?
        robertlagrant 2y ago
        Oh yes, I agree that there are technical decisions are fuzzy. I'm happy to concede that; just dashed it off too quickly.
- robador 2y ago
  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.
  - scotty79 2y ago
    That's genius. Let the workers work and keep busybodies with busywork.
- Cthulhu_ 2y ago
  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=5581&langId=en https://ec.europa.eu/social/main.jsp?catId=1202&intPageId=55...
  - hahahacorn 2y ago
    >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).
- exitb 2y ago
  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.
- foldr 2y ago
  > 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.
  - hahahacorn 2y ago
    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.
hu3 2y ago
> 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.
- makeitdouble 2y ago
  > 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.
- pcblues 2y ago
  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.
lightyrs 2y ago
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.
Animats 2y ago
These guys do security software. You don't find out if security software is badly broken until you're attacked.
- Cthulhu_ 2y ago
  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.
- zug_zug 2y ago
  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.
rtpg 2y ago
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!
- exitb 2y ago
  "No silver bullet" usually holds true. The same methodology might make an inexperienced team productive AND be an impediment for an experienced one.
ChrisMarshallNY 2y ago
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/ https://littlegreenviper.com/concrete-galoshes/
- bantunes 2y ago
  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.
  - sirwhinesalot 2y ago
    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.
mtkd 2y ago
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
alentred 2y ago
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.
- jdsalaro 2y ago
  > 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.
  - baq 2y ago
    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...)
davedx 2y ago
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.
xiphias2 2y ago
I love The Rise of Worse is better, and this sounds just like that: https://www.dreamsongs.com/RiseOfWorseIsBetter.html 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.
- Quimoniz 2y ago
  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
  - xiphias2 2y ago
    Sure, it's the speed of adding a new incremental simple feature to the existing code base.
    - Quimoniz 2y ago
      Thank you.
- vdvsvwvwvwvwv 2y ago
  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.
- deleted 2y ago
  [deleted]
irjustin 2y ago
> 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).
- simultsop 2y ago
  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.
  - marcosdumay 2y ago
    Ouch. I guess you never did one of those "we brought large-software-X, and are in 2/3 of the way to implement it; we just need you to plug you in-house software-Y to it" projects, where you end up reimplementing every single feature from X into Y and make people give-up on the brought software before the vendor finishes installing it or allows you to see the documentation on how to plug anything into it. Those are so common that I think they are the majoritarian way any large software is brought.
megamix 2y ago
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?
- sirwhinesalot 2y ago
  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.
duke360 2y ago
at least part of it smells like bullshits
michael0x11 2y ago
[dead]
bambax 2y ago
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-naked-chef/ https://www.joelonsoftware.com/2001/01/18/big-macs-vs-the-na...*
Brajeshwar 2y ago
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.
wg0 2y ago
"Word"
jpswade 2y ago
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.
schnable 2y ago
> 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-variable-scope https://basecamp.com/shapeup/1.2-chapter-03#fixed-time-varia...
- PaulRobinson 2y ago
  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.
mattm 2y ago
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.
- meiraleal 2y ago
  > These "throw out the processes and methodologies" articles are always written by people at small companies. That's great advice then! HN is mostly comprised of people looking for tips on how to go from 0 to 1, not to 0 to 100.
PaulRobinson 2y ago
> 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.
dangsux 2y ago
[dead]
orzig 2y ago
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.
zelias 2y ago
> 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.
luismedel 2y ago
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.
throwaway984393 2y ago
[dead]
FrameworkFred 2y ago
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.
0xbadcafebee 2y ago
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
robust-cactus 2y ago
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
xivzgrev 2y ago
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.

226 points by noleary 2y ago

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.

ks84 2y ago
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.
tmarice 2y ago
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.
- deviation 2y ago
  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.
  - Xss3 2y ago
    Your product decisions are hidden in thousands of pages of legal jargon?
    - capitalatrisk 2y ago
      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?
- robertlagrant 2y ago
  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.
  - foldr 2y ago
    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.
    - robertlagrant 2y ago
      > 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?" (-:
      - foldr 2y ago
        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?
        robertlagrant 2y ago
        Oh yes, I agree that there are technical decisions are fuzzy. I'm happy to concede that; just dashed it off too quickly.
robador 2y ago
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.
- scotty79 2y ago
  That's genius. Let the workers work and keep busybodies with busywork.
Cthulhu_ 2y ago
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=5581&langId=en https://ec.europa.eu/social/main.jsp?catId=1202&intPageId=55...
- hahahacorn 2y ago
  >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).
exitb 2y ago
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.
foldr 2y ago
> 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.
- hahahacorn 2y ago
  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.

hu3 2y ago

> 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.

makeitdouble 2y ago
> 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.
pcblues 2y ago
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.

lightyrs 2y ago

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.

Animats 2y ago

These guys do security software. You don't find out if security software is badly broken until you're attacked.

Cthulhu_ 2y ago
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.
zug_zug 2y ago
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.

rtpg 2y ago

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!

exitb 2y ago
"No silver bullet" usually holds true. The same methodology might make an inexperienced team productive AND be an impediment for an experienced one.

ChrisMarshallNY 2y ago

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/ https://littlegreenviper.com/concrete-galoshes/

bantunes 2y ago
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.
- sirwhinesalot 2y ago
  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.

mtkd 2y ago

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

alentred 2y ago

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.

jdsalaro 2y ago
> 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.
- baq 2y ago
  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...)

davedx 2y ago

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.

xiphias2 2y ago

I love The Rise of Worse is better, and this sounds just like that: https://www.dreamsongs.com/RiseOfWorseIsBetter.html 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.

Quimoniz 2y ago
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
- xiphias2 2y ago
  Sure, it's the speed of adding a new incremental simple feature to the existing code base.
  - Quimoniz 2y ago
    Thank you.
vdvsvwvwvwvwv 2y ago
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.
deleted 2y ago
[deleted]

irjustin 2y ago

> 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).

simultsop 2y ago
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.
- marcosdumay 2y ago
  Ouch. I guess you never did one of those "we brought large-software-X, and are in 2/3 of the way to implement it; we just need you to plug you in-house software-Y to it" projects, where you end up reimplementing every single feature from X into Y and make people give-up on the brought software before the vendor finishes installing it or allows you to see the documentation on how to plug anything into it. Those are so common that I think they are the majoritarian way any large software is brought.

megamix 2y ago

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?

sirwhinesalot 2y ago
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.

duke360 2y ago

at least part of it smells like bullshits

michael0x11 2y ago

[dead]

bambax 2y ago

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-naked-chef/ https://www.joelonsoftware.com/2001/01/18/big-macs-vs-the-na...*

Brajeshwar 2y ago

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.

wg0 2y ago

"Word"

jpswade 2y ago

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.

schnable 2y ago

> 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-variable-scope https://basecamp.com/shapeup/1.2-chapter-03#fixed-time-varia...

PaulRobinson 2y ago
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.

mattm 2y ago

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.

meiraleal 2y ago
> These "throw out the processes and methodologies" articles are always written by people at small companies. That's great advice then! HN is mostly comprised of people looking for tips on how to go from 0 to 1, not to 0 to 100.

PaulRobinson 2y ago

> 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.

dangsux 2y ago

[dead]

orzig 2y ago

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.

zelias 2y ago

> 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.

luismedel 2y ago

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.

throwaway984393 2y ago

[dead]

FrameworkFred 2y ago

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.

0xbadcafebee 2y ago

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

robust-cactus 2y ago

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

xivzgrev 2y ago

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.