5 ms·

Excellent rebuttal of those calling for the end of Agile whilst simultaneously not know what Agile even is. My addition-- If we're going to end cargo culting,

Excellent rebuttal of those calling for the end of Agile whilst simultaneously not know what Agile even is. My addition-- If we're going to end cargo culting, we should also end all the cargo cults of Silicon valley style startups. 1. Stop the cult of "Grind". Working more hours is not more productive for most people 2. Stop the cult of "build faster with tech debt" -- internal quality matters and costs you velocity. Those 10x engineers are 0.1x when you consider their externalities 3. Stop the lie that you'll get rich off startup options. Statistically improbable and options which expire 90 days after your employment ends are not equity or property as most people understand it. They expire/evaporate unless you shell out the exercise price, and the tax money on the gains... -- RSUs or extended exercise windows are though. 4. "We can fix it later with an order of magnitude more VC money" -- Similar to the tech debt item, a company w/ a game plan of "more VC money" is outdated and missing the change in environment, instead be profitable from very early.. ideally from your first customer. 5. "We need bespoke software because our Product is so unique." -- Nope -- use all the tools you can until you have scale, then start to build whatever is least economical to buy. 6. Doing it like Google (or other respected company). You're not google. Oh and if you survey for "Best practices" -- it's not best, it's average. Average isn't going to cut it anymore. What'd I miss from the list?

chinaman425 4y ago
[flagged]
- maerF0x0 4y ago
  not sure if you're ironically mocking the exact kind of answer you'd get in an "I'm so excited!" style culture. Or if you're serious... I'm not angry I'm just tired of the doublespeak by people who, for example, say you gotta take a vaccine or you're "anti-science" but then turn around and denying much of the academic information we know about software engineering practice. It's self serving cherry picking.
cratermoon 4y ago
While we're at it, let's talk about what Technical Debt really means. A mess is not technical debt. Ward Cunningham explains Debt Metaphor https://www.youtube.com/watch?v=pqeJFYwnkjE https://www.youtube.com/watch?v=pqeJFYwnkjE transcript at http://wiki.c2.com/?WardExplainsDebtMetaphor http://wiki.c2.com/?WardExplainsDebtMetaphor
- feoren 4y ago
  A mess is debt, because you have to pay interest on it. If you don't pay your interest, it will compound and completely kill your velocity. Nothing in Ward's transcript disputes that, nor would it matter if he did (Death of the Author). Ward seems to be clarifying the difference between useful technical debt, which gets your product out the door faster, and wasteful technical debt, which is writing your code poorly when you could have done better. If it's slowing your velocity down, making things harder than they should be, it's technical debt. I suppose if you had a "mess" that was self-contained, bug-free, and not slowing you down at all, then that's not debt -- but is it even a mess?
  - maerF0x0 4y ago
    you've described a mess correctly, but misused the term/jargon. What you've described is poor quality implementation. There are many (infinite?) implementations that could satisfy the product manager, but each has it's nuances of correctness in non-tested cases (if you have tests), in runtime effects, race conditions (across processes), thread safety, ease of refactor, readability etc. All these are markers of software quality, but failing to do them is not "techdebt". Tech debt is a very specific thing as described in the video above
- pnt12 4y ago
  I've hear this before and I found it nonsense. In short, I don't see any advantage to distinguish responsible) deliberate debt from irresponsible/involuntary debt. A debt is a debt. You take a loan to buy a house, knowing your salary will allow for the extra expense and you have backups plan. That's a responsible debt. Like, hardcoding some variables in a prototype - eventually that needs fixing. Everyone agrees this is technical debt. But you can also take an irresponsible loan, eg for some far away vacations you can't afford to. Is that debt? Sure it is, and you better figure a way to solve it once you realize your mistake!
feoren 4y ago
All of these are great except (depending on what exactly you're thinking of): > 5. "We need bespoke software because our Product is so unique." -- Nope -- use all the tools you can until you have scale, then start to build whatever is least economical to buy. You're talking about software startups, right? If their product is not "so unique" then why are they building it? If you don't need custom software, why the hell are you hiring software developers? This one is just weird. While I understand the dangers of Not-Invented-Here syndrome, the pendulum is currently WAY too far the other direction. Almost every "modern" software project is way too reliant on dozens of libraries that are philosophically incompatible, spending more time on adapters and API-specific integration than they would spend simply writing what they actually want to begin with.
- OJFord 4y ago
  You can build bespoke software without using bespoke software (other than your own to test or dogfood if applicable of course). E.g. if it's basically a webapp, the chances that it's such a snowflake that existing frameworks are inappropriate and you need to roll your own are extremely slim. (On the other hand, you won't think you're making a game and accidentally create Slack that way...)
- richeyryan 4y ago
  I used to work for an automated property valuation platform. It was basically a property valuation workflow tool that presented valuers with the right data at the right time so they could drastically reduce the amount of time spent valuing each property and theoretically produce much more accurate results. We spent so much time working on features and workflows to interact with clients rather than building the platform for our actual users, the valuers. We could have picked any CRM off the shelf, adopted its way of working, and saved ourselves a lot of time. There is no scenario in which the CRM subscription would have exceeded the cost of the developer's time to produce the cobbled-together half-baked solution we ended up with.
- CharlieDigital 4y ago
  When I arrived at the startup I'm at now, we used a "bespoke" backend for interacting with AWS SQS. It was a pile of code that was written that had no value to the function of the startup. Switched it to an OSS bus and dumped a bunch of bespoke code. I regret not pushing harder for the CTO to avoid even more bespoke code for some of the admin interfaces that we ended up building for internal tooling which probably would have been better in something like NocoDB. The value of the startup is rarely in the bits and pieces themselves (very few are), but the process or data flow that the startup models with those bits and pieces and some pain point or business value that gets added in doing so. One thing I have come to appreciate in startups is that it's better to even spend $10,000 to learn fast rather than to wait 3 months to come to the same conclusion. To put it another way: if you could see 3 months into the future for $10,000, would you pay it? Instantly. So if there's a shortcut that can -- with a high degree of certainty -- remove obfuscations of the path to take, you take it.
pif 4y ago
> Stop the cult of "build faster with tech debt" -- internal quality matters and costs you velocity. Well, internal quality costs, and the price is expressed in time. As someone else said: "shipping is a feature", and especially for first versions! The quality of the code is only important for that code that actually brings value to the user, and you need to ship in order to know which is which. The problem with technical debt stems from the diffused myth that the development of a functionality ends as soon as it is released. No, you must continue to work after the first release, in order to polish the code while integrating the feedback from the user. This is the core of Agile.
- maerF0x0 4y ago
  >The way I assess where lines cross is by canvassing the opinion of skilled developers that I know. And the answer surprises a lot of folks. Developers find poor quality code significantly slows them down within a few weeks. So there's not much runway where the trade-off between internal quality and cost applies. Even small software efforts benefit from attention to good software practices, certainly something I can attest from my experience. https://martinfowler.com/articles/is-quality-worth-cost.html https://martinfowler.com/articles/is-quality-worth-cost.html If you expect your business to exist more than a few weeks from now, opt for quality implementation over "ship it" hacks that cause compounding costs into the future.
  - pif 4y ago
    There are hacks like "everything in a huge global object", and technical debts like "no unit tests for internal detail and no detailed software structure documentation until we know which code is actually worth to maintain".
  - pif 4y ago
    > Developers find poor quality code significantly slows them down within a few weeks. By the way, I'd like to know which kind of software those "skilled" developers are used to work on. If it is the umpteenth CRUD web application, several weeks can correspond to a few releases. In other fields, a few releases is a matter of years, and even only a few months of customer feedback is a treasure that smart developers don't give up easily.
shantnutiwari 4y ago
>What'd I miss from the list? Fucking "Hustle" -- a word used by scammers and conmen that now somehow means "work smart" but actually means spamming people and doing other sleazy things to get money
penguinvondoom 4y ago
I think both the rebuttal and the original articles are good, but talk about different things. The original one seems to talk about the way Agile tends to be done, especially via the world of corporate, consultant agile, certified scrum masters and so on, whereas the rebuttal is talking from the point of view of what Agile should be. Two very different things, both very valid, and in a sense the discrepancy between the two tells you a lot about the state of agile itself. That said I love the thing about ending Sillicon Valley bullshit - IMO it has led to a lot more hurt than good.

chinaman425 4y ago

[flagged]

maerF0x0 4y ago
not sure if you're ironically mocking the exact kind of answer you'd get in an "I'm so excited!" style culture. Or if you're serious... I'm not angry I'm just tired of the doublespeak by people who, for example, say you gotta take a vaccine or you're "anti-science" but then turn around and denying much of the academic information we know about software engineering practice. It's self serving cherry picking.

cratermoon 4y ago

While we're at it, let's talk about what Technical Debt really means. A mess is not technical debt. Ward Cunningham explains Debt Metaphor https://www.youtube.com/watch?v=pqeJFYwnkjE https://www.youtube.com/watch?v=pqeJFYwnkjE transcript at http://wiki.c2.com/?WardExplainsDebtMetaphor http://wiki.c2.com/?WardExplainsDebtMetaphor

feoren 4y ago
A mess is debt, because you have to pay interest on it. If you don't pay your interest, it will compound and completely kill your velocity. Nothing in Ward's transcript disputes that, nor would it matter if he did (Death of the Author). Ward seems to be clarifying the difference between useful technical debt, which gets your product out the door faster, and wasteful technical debt, which is writing your code poorly when you could have done better. If it's slowing your velocity down, making things harder than they should be, it's technical debt. I suppose if you had a "mess" that was self-contained, bug-free, and not slowing you down at all, then that's not debt -- but is it even a mess?
- maerF0x0 4y ago
  you've described a mess correctly, but misused the term/jargon. What you've described is poor quality implementation. There are many (infinite?) implementations that could satisfy the product manager, but each has it's nuances of correctness in non-tested cases (if you have tests), in runtime effects, race conditions (across processes), thread safety, ease of refactor, readability etc. All these are markers of software quality, but failing to do them is not "techdebt". Tech debt is a very specific thing as described in the video above
pnt12 4y ago
I've hear this before and I found it nonsense. In short, I don't see any advantage to distinguish responsible) deliberate debt from irresponsible/involuntary debt. A debt is a debt. You take a loan to buy a house, knowing your salary will allow for the extra expense and you have backups plan. That's a responsible debt. Like, hardcoding some variables in a prototype - eventually that needs fixing. Everyone agrees this is technical debt. But you can also take an irresponsible loan, eg for some far away vacations you can't afford to. Is that debt? Sure it is, and you better figure a way to solve it once you realize your mistake!

feoren 4y ago

All of these are great except (depending on what exactly you're thinking of): > 5. "We need bespoke software because our Product is so unique." -- Nope -- use all the tools you can until you have scale, then start to build whatever is least economical to buy. You're talking about software startups, right? If their product is not "so unique" then why are they building it? If you don't need custom software, why the hell are you hiring software developers? This one is just weird. While I understand the dangers of Not-Invented-Here syndrome, the pendulum is currently WAY too far the other direction. Almost every "modern" software project is way too reliant on dozens of libraries that are philosophically incompatible, spending more time on adapters and API-specific integration than they would spend simply writing what they actually want to begin with.

OJFord 4y ago
You can build bespoke software without using bespoke software (other than your own to test or dogfood if applicable of course). E.g. if it's basically a webapp, the chances that it's such a snowflake that existing frameworks are inappropriate and you need to roll your own are extremely slim. (On the other hand, you won't think you're making a game and accidentally create Slack that way...)
richeyryan 4y ago
I used to work for an automated property valuation platform. It was basically a property valuation workflow tool that presented valuers with the right data at the right time so they could drastically reduce the amount of time spent valuing each property and theoretically produce much more accurate results. We spent so much time working on features and workflows to interact with clients rather than building the platform for our actual users, the valuers. We could have picked any CRM off the shelf, adopted its way of working, and saved ourselves a lot of time. There is no scenario in which the CRM subscription would have exceeded the cost of the developer's time to produce the cobbled-together half-baked solution we ended up with.
CharlieDigital 4y ago
When I arrived at the startup I'm at now, we used a "bespoke" backend for interacting with AWS SQS. It was a pile of code that was written that had no value to the function of the startup. Switched it to an OSS bus and dumped a bunch of bespoke code. I regret not pushing harder for the CTO to avoid even more bespoke code for some of the admin interfaces that we ended up building for internal tooling which probably would have been better in something like NocoDB. The value of the startup is rarely in the bits and pieces themselves (very few are), but the process or data flow that the startup models with those bits and pieces and some pain point or business value that gets added in doing so. One thing I have come to appreciate in startups is that it's better to even spend $10,000 to learn fast rather than to wait 3 months to come to the same conclusion. To put it another way: if you could see 3 months into the future for $10,000, would you pay it? Instantly. So if there's a shortcut that can -- with a high degree of certainty -- remove obfuscations of the path to take, you take it.

pif 4y ago

> Stop the cult of "build faster with tech debt" -- internal quality matters and costs you velocity. Well, internal quality costs, and the price is expressed in time. As someone else said: "shipping is a feature", and especially for first versions! The quality of the code is only important for that code that actually brings value to the user, and you need to ship in order to know which is which. The problem with technical debt stems from the diffused myth that the development of a functionality ends as soon as it is released. No, you must continue to work after the first release, in order to polish the code while integrating the feedback from the user. This is the core of Agile.

maerF0x0 4y ago
>The way I assess where lines cross is by canvassing the opinion of skilled developers that I know. And the answer surprises a lot of folks. Developers find poor quality code significantly slows them down within a few weeks. So there's not much runway where the trade-off between internal quality and cost applies. Even small software efforts benefit from attention to good software practices, certainly something I can attest from my experience. https://martinfowler.com/articles/is-quality-worth-cost.html https://martinfowler.com/articles/is-quality-worth-cost.html If you expect your business to exist more than a few weeks from now, opt for quality implementation over "ship it" hacks that cause compounding costs into the future.
- pif 4y ago
  There are hacks like "everything in a huge global object", and technical debts like "no unit tests for internal detail and no detailed software structure documentation until we know which code is actually worth to maintain".
- pif 4y ago
  > Developers find poor quality code significantly slows them down within a few weeks. By the way, I'd like to know which kind of software those "skilled" developers are used to work on. If it is the umpteenth CRUD web application, several weeks can correspond to a few releases. In other fields, a few releases is a matter of years, and even only a few months of customer feedback is a treasure that smart developers don't give up easily.

shantnutiwari 4y ago

>What'd I miss from the list? Fucking "Hustle" -- a word used by scammers and conmen that now somehow means "work smart" but actually means spamming people and doing other sleazy things to get money

penguinvondoom 4y ago

I think both the rebuttal and the original articles are good, but talk about different things. The original one seems to talk about the way Agile tends to be done, especially via the world of corporate, consultant agile, certified scrum masters and so on, whereas the rebuttal is talking from the point of view of what Agile should be. Two very different things, both very valid, and in a sense the discrepancy between the two tells you a lot about the state of agile itself. That said I love the thing about ending Sillicon Valley bullshit - IMO it has led to a lot more hurt than good.