[HN Gopher] Principles for product velocity
___________________________________________________________________
Principles for product velocity
Author : noleary
Score : 212 points
Date : 2024-11-08 06:48 UTC (16 hours ago)
(HTM) web link (ssoready.com)
(TXT) w3m dump (ssoready.com)
| hahahacorn wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Your product decisions are hidden in thousands of pages of
| legal jargon?
| capitalatrisk wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| Oh yes, I agree that there are technical decisions are
| fuzzy. I'm happy to concede that; just dashed it off too
| quickly.
| robador wrote:
| 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 wrote:
| That's genius. Let the workers work and keep busybodies with
| busywork.
| Cthulhu_ wrote:
| 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...
| hahahacorn wrote:
| >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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| These guys do security software.
|
| You don't find out if security software is badly broken until
| you're attacked.
| Cthulhu_ wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| "No silver bullet" usually holds true. The same methodology
| might make an inexperienced team productive AND be an
| impediment for an experienced one.
| ChrisMarshallNY wrote:
| 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/
| bantunes wrote:
| 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 wrote:
| 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.
| ChrisMarshallNY wrote:
| 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.
| kraftman wrote:
| 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.
| ChrisMarshallNY wrote:
| 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.
| kraftman wrote:
| maybe it should be prepended with 'if you work in the
| mcdonalds of software development companies'
| _heimdall wrote:
| 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.
| lupire wrote:
| 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.
| _heimdall wrote:
| Sure, I don't disagree there. In context I was replying
| to a comment about how big tech companies use agile and
| similar though.
|
| I do agree though, when used in the specific context of
| consulting it may be a better fit than in a big tech
| corporation.
| hinkley wrote:
| > But that is anathema to tech companies
|
| One of the biggest dangers in business is believing your own
| PR. And yet tech companies do it over, and over, and over
| again.
| the_af wrote:
| > _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?
| ChrisMarshallNY wrote:
| 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.
| bradley13 wrote:
| 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...
| josh-sematic wrote:
| Largely agree. Heavy process is a tool to help less skilled
| people have output more comparable to more skilled people. But
| it comes at a cost of making more skilled people less
| productive. If you can hire small numbers of highly skilled
| people you can accomplish a lot with little process. Sadly at
| some scale "hire only really skilled people" becomes basically
| impossible and process needs to be more heavy to account for
| that.
| hinkley wrote:
| Scrum seems to be more about helping a _manager_ of less
| skilled /experienced people get more output from them.
|
| As people become more familiar with agile processes in
| general (we all say we are "doing scrum" but we are also
| doing more than half of XP - otherwise a scrum doesn't work
| at all) those gains diminish and I think among us we can
| agree they go negative.
| mwigdahl wrote:
| This is very true, and I second the importance of long tenure.
| There is no substitute for it; it helps with product
| experience, personal relationships, and organizational
| knowledge.
| msla wrote:
| Once again, you have no idea what you're talking about.
| ChrisMarshallNY wrote:
| Sigh ...
|
| Normally, I ignore obvious troll comments, but I do have
| respect for your expertise, so I'd like to ask for some
| enlightenment. If I'm wrong, the only way to find out, is to
| ask how.
|
| Thanks!
| mtkd wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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...)
| robertlagrant wrote:
| > 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?
| mcmcmc wrote:
| Maybe it would be more accurate to say agile is a way of
| doing things, not a way of managing people.
| baq wrote:
| yeah I completely agree, well put; I also like the
| sibling's 'process of making/doing things'.
| hinkley wrote:
| That's because Scrum is so easy to turn into a management
| process. It makes more sense to them than all the other
| forms of Agile combined. So like children reaching for
| candy instead of vegetables, or who will only eat carrots
| as a vegetable, you have to work to make them reach for
| something else, otherwise they will be unhealthy.
| jdsalaro wrote:
| > management is very creative
|
| What you described, I wouldn't accept generally under my
| definition of creativity.
|
| In order for creativity to be such it must ultimately
| deliver value; managers "doing their job" in ways which
| hinder instead of supporting engineers is not creative,
| it's disruptive.
| the_af wrote:
| > _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.
| zimzam wrote:
| 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.
| mwigdahl wrote:
| This sounds cynical on its face but it is my experience
| as well. Management does not actually trust engineers to
| provide value without close oversight (sometimes with
| good reason!), so any framework that purports to give
| engineers more autonomy will eventually be subverted by
| the management. And since management always has more
| power than line engineering, they always win.
|
| The only way for "true" agile to really take root would
| be for management to trust engineering to add more value
| on their own than when being micromanaged. That's a tall
| order, and gets much taller in larger organizations.
| seadan83 wrote:
| Agile is not there for higher velocity! It is sold to
| management that way often, but intrinsically - no.
|
| Agile though is meant to reduce waste. In other words,
| you don't march faster, but are supposed to spend more
| time marching in the right direction. (I personally
| loathe agile and find it intrinsically broken.. I just
| find it kind of funny that a process oriented around
| dynamic environments is supposed to give predictability
| and speed, when it gives neither. If anything, a lack of
| predictability since direction can change)
| cjfd wrote:
| 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.
| hinkley wrote:
| And that usually breaks, as another reply said, when the
| manager of the two people delegates responsibility for the
| problem getting solved to one of those two people instead of
| keeping it for themselves.
|
| If you have a boss who cares whether the task gets done, you
| can't make excuses about how it violates your moat to have to
| do it. Shut up and help your coworker. Now. Or you're on PIP.
|
| The coworker who isn't getting useful collaboration gets
| blamed for their soft skills, when it's the boss's soft
| skills that should have reigned over both.
| pflenker wrote:
| 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.
| pdimitar wrote:
| 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.
| pflenker wrote:
| 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.
| pdimitar wrote:
| > _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. :(
| viraptor wrote:
| 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.
| pdimitar wrote:
| > _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.
| paulcole wrote:
| If someone's work history is littered with only
| dysfunctional companies, are we sure the companies are
| 100% of the issue?
| pdimitar wrote:
| 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.
|
| -\\_(tsu)_/-
| paulcole wrote:
| There are numbers between 0 and 100.
| pdimitar wrote:
| Yes, and I never said 100% of my professional experiences
| were bad. I had extremely positive contracts that left me
| smiling.
|
| What I did say was that I never stumbled upon managers
| who did Scrum / Agile in a way that was empowering for
| the programmers.
|
| Obviously these two things are very different.
| lupire wrote:
| No methodology will get good work out of bad people.
|
| Having good people is table stakes.
| pdimitar wrote:
| 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.
| hinkley wrote:
| > Retrospectives have been used in my career, without
| failure, without a single exception, to slap developers
| into rushing even more. That's what all managers
|
| Dude, no. Kick managers out of the retro. The retro is a
| place for uncomfortable candor between peers, not another
| place for your manager to hold court. They need to leave
| the room while you decide what's a problem, and what is not
| a problem (yet). Once you have a plan on the table you can
| bring the boss back in to discuss the redacted summary of
| the meeting and any proposals that require their
| assistance.
|
| They didn't work _for you_ because you've done them wrong
| at every single place. I've had to fight twice to do it
| right, but we won both times via solidarity.
| pdimitar wrote:
| I haven't "done" anything. They were forced on me.
|
| I get what you're saying and with time I started fighting
| for something 90% the same as you are describing. But
| most of the time I had no choice. It was "our way or the
| highway".
|
| And since I was financially and career-wise extremely
| stupid for most of my life and career... yeah. I worked
| with idiots and slave-drivers.
|
| I am looking to finally change that by changing the way I
| conduct myself. You hiring? Yeah, I didn't make myself an
| excellent advertisement with my original comment but at
| least people will know where I stand.
| tkiolp4 wrote:
| Same here. Daily stand ups (no matter if they last 5 min.
| or 20) have not being useful for me any single time. They
| are used by managers to force us to show what we have been
| doing the day before. No more, no less. If I ever get stuck
| with something, I go and ask for help to my colleagues; I
| update the corresponding Jira ticket status and whatever is
| needed to keep my work visible.
|
| Same for retros or any other kind of ceremony. They are
| just for managers.
| f1shy wrote:
| 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.
| the_af wrote:
| If consultants start selling it as a packaged methodology,
| you can be certain it's BS.
| scotty79 wrote:
| > 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.
| fmbb wrote:
| > 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.
| zwischenzug wrote:
| Parent is close to what I argued here:
|
| https://zwischenzugs.com/2017/10/15/my-20-year-experience-of...
| jvanderbot wrote:
| 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!
| taneq wrote:
| > 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."
| brainzap wrote:
| 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.
| duxup wrote:
| 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.
| friendzis wrote:
| 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.
| therealmulder wrote:
| 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.
| K0balt wrote:
| 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.
| calderwoodra wrote:
| 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.
| mooreds wrote:
| I think there's some truth that process slows down development.
| (Full disclosure, I work for a company in the same space as
| these folks.)
|
| I love a provocative essay as much as the next person.
|
| But the authors are in a relatively new, smaller company
| focusing on devtools[0]. This has a couple of ramifications
| related to process need:
|
| - they are the customer to a great extent, so they don't need
| to involve external customers to discover what is needed.
|
| - they are fast followers (an OSS WorkOS competitor[1]), so can
| rely on product need discovery from other competitors. That's
| not a bad thing (I've done the same!), but it isn't sustainable
| forever.
|
| - they have a small team, which means everyone has autonomy and
| knowledge.
|
| - at the size of 2, they don't have other departments with
| schedules and deadlines and goals. Process is critical to
| getting input and coordinating across departments to achieve
| company goals.
|
| All of these factors mean process is an impediment without any
| benefit.
|
| Not every company is like this company. Not every dev team is
| like this dev team. My opinion is that this company in three
| years won't be like this company is now.
|
| I'd wager that in 3 years, if ssoready is successful, there'll
| be process. It'll be an impediment but a necessary one, as the
| attributes they currently have won't be enough to keep
| delivering.
|
| Happy to bet on that if either Ned or Ulysse is reading :)
|
| 0: According to https://www.ycombinator.com/companies/ssoready
| they were founded in 2023 and have 2 employees.
|
| 1: https://news.ycombinator.com/item?id=41111136
| kmacleod wrote:
| Every team has process. It doesn't matter if it's documented
| or not, or whether improvements (or impediments) are
| intentional or not. Every team has their process.
|
| Source: Identifying teams' principles and practices is one of
| the tools I use.
| astrobe_ wrote:
| > I wonder how we can break the cycle
|
| "Hire former software engineers at management positions" would
| be the answer, but of course there are various factors that
| makes it difficult to do so.
|
| In theory, management should be held accountable for getting in
| a way, but it is not possible either because of the nature of
| software development: one cannot really measure productivity
| because it is to a more-or-less large extent a research
| activity.
|
| I think probably the best option is to introduce some more
| democracy (or rather "technocracy" in the literal sense, "power
| to those who build") in the mix: management evaluated and
| chosen by the engineers. Call me communist all you want...
| sevensor wrote:
| Agile, in practice, has turned into "disorganized waterfall."
| Witness absurdities like the existence of the "Agile Gantt
| Chart for Jira." The reason Waterfall, or modern Agile, are the
| way they are, is that they are systems that allows the smallest
| possible number of people to take responsibility, while
| allowing everyone to perform accountability. Basically nobody
| wants to lay it on the line and say to the CTO, "I'm going to
| make this project succeed." Much easier to say, "we're using
| best practices and modern processes."
|
| This is a consequence of failing to train managers, especially
| in the moral dimension of management, which is entirely about
| accepting responsibility, and of promoting into management
| individuals who are not prepared to do so.
| ebiester wrote:
| It turns out for large cross-team initiatives, organizing the
| work is as hard as doing it.
|
| I like the example of internationalization. You need
| involvement from all parts of the product to release it - you
| rarely can sell a half-internationalized product. You need to
| work with external teams of translators who need to be fed
| the work in a consistent interface. There will be pieces of
| the work that nobody is going to forsee (e.g. pulling text
| from the database) that will be surfaced and handled
| consistently.
|
| So, to get it out, you need to have each team prioritize the
| work. You effectively need a deadline, or the work will never
| happen. (The work is valuable for the company, but does not
| drive any individual team's customers.) You will have
| dependencies: Team A has to address part of the work before
| team B can. And you need a way for teams to report that they
| are done so that it can be reviewed for consistency across
| the product.
|
| This is a bad fit for most agile methodologies, but you're
| not going to take everyone out of it temporarily and then go
| back in. So you have to accommodate a project within your
| system.
|
| But these exceptions become more and more common as your
| company gets bigger and bigger. The only truth that I can
| find is that the only way to stay agile is to stay small:
| small teams naturally do the things that are agile.
| baxtr wrote:
| I agree, it's a new/old methodology disguised in a rant.
|
| To your last point that we've come full circle.
|
| Maybe that's exactly how things evolve. Start small, get large
| and complex, cut back to become simple again.
|
| While it might sound like a circle, I believe that it's an
| evolution. Things improve over time with each iteration.
| commandlinefan wrote:
| > we've come full circle.
|
| We never went anywhere. I had such high hopes for the agile
| manifesto when I first read it in 1999. "Whew," I though,
| "finally, they realize that software can't be managed like an
| automobile assembly line." Nope, they just rebranded the
| "manage software like an automobile assembly line"
| methodology as... AGILE! Don't get me wrong - the signatories
| on the agile manifesto did seem to understand how to
| realistically plan and manage software. Nobody else who read
| it and had any position of authority seemed to.
| alentred wrote:
| > Maybe that's exactly how things evolve. Start small, get
| large and complex, cut back to become simple again.
|
| I like to think it is! Two steps forward, one step back, but
| overall advancing slowly.
| GuB-42 wrote:
| > Well, right from the Agile manifesto
|
| The Agile manifesto is great. It is simple, straightforward,
| and most importantly, it clearly defines itself as a statement
| of opinion, with a counterpart to each of its value. And yet so
| many people do exactly what the manifesto tells them not do to.
| Why? Just why? It is as if a clothing brand has "beach and sun
| over mountain and snow" as its value and people go to ski with
| them and complain that they get cold.
|
| Agile is not on size fits all, sometimes you need comprehensive
| documentation for instance. In this case, just don't do Agile,
| the manifesto is really explicit in that it is not the right
| methodology for you. But for some reason, Agile is fashionable,
| so you take it anyways and try reshape it into the V-model you
| should have used in the first place and get the worst of both.
| Viliam1234 wrote:
| > And yet so many people do exactly what the manifesto tells
| them not do to. Why? Just why?
|
| The manager on the top says "do Agile" because his friends
| say that this is now the cool thing. The managers on the
| bottom have no idea what it means, so they do some random
| thing and call it "Agile", and report job done. The manager
| on the top is happy and gives them a small bonus.
|
| And as managers circulate across companies, they keep
| introducing the "random thing we did at my previous job and
| called it Agile" as the one true Agile, so the whole
| randomness converges to one specific version (with Jira and
| long meetings and other stuff).
| marcosdumay wrote:
| I can't even imagine how Scrum could ever align with the Agile
| values for it to be abused and transformed. IMO, that part is
| impossible, and Scrum was always a "bad-management by the
| numbers" framework.
|
| Anyway, I've hear phrases like your example since some time
| around 2001. Agile was practically born with a parasitic
| consulting market intent on having the one true way to do it,
| and that way being what middle-managers adept of micro-managing
| want it to be. In fact, I think those consultants were the ones
| that pushed the word around, without them we wouldn't even have
| heard of the manifesto.
|
| That's to say that, yeah, I do agree with your comment, but the
| actual problem is deeper, and harder to fix. Scrum and bad
| processes are just symptoms here.
| philwelch wrote:
| > But do you know how Agile was invented? It was a group of
| software developers, tired of heavy management processes, who
| came together to decide how to make their processes
| lightweight.
|
| Agile is agile the same way the People's Democratic Republic of
| Korea is a democracy. And like most dictatorships with these
| names, I'm sure they also have a founding myth that claims a
| genuine concern for Democracy and the People.
|
| Software developers are concerned with developing software. The
| people with the time and energy to develop and sell
| methodologies like Agile are not in the business of developing
| software; they're in the business of selling methodologies.
| Maybe they're consultants trying to sell clients on the
| methodology as a selling point for their consultancy (much of
| Agile seems geared to this), or maybe they're trying to train
| people to be Certified Scrum Masters or whatever. Either way,
| you can't actually sell people a methodology that boils down to
| reducing methodology because then you have nothing to sell.
|
| I know I sound cynical, but the reality is that human behavior
| is driven by incentives and anyone who genuinely cared about
| making processes lightweight has little incentive to hang
| around the Agile scene fighting with the grifters.
| davedx wrote:
| 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 wrote:
| 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.
| Quimoniz wrote:
| 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 wrote:
| Sure, it's the speed of adding a new incremental simple
| feature to the existing code base.
| vdvsvwvwvwvwv wrote:
| 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.
| irjustin wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| at least part of it smells like bullshits
| bambax wrote:
| 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...*
| Brajeshwar wrote:
| 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 wrote:
| "Word"
| jpswade wrote:
| 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 wrote:
| > 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...
| PaulRobinson wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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.
| sirwhinesalot wrote:
| But most software out there is built with heavy processes? SAFe
| and all that nonsense, and everyone agrees the output is
| complete garbage. The software that is lauded and praised tends
| to be made by small teams of highly skilled engineers, stuff
| like EmberGen.
|
| To me what this says is that software is not, at all, like
| other engineering disciplines. Software developers aren't like
| masons, we're not just mixing cement, there's more to it than
| that. You can add more masons to a construction work and it
| will most likely go faster. Add more devs to a project and most
| likely it'll go _slower_.
| orzig wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| FrameworkFred wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2024-11-08 23:02 UTC)