9 ms·

Agility Requires Safety

128 points by runesoerensen 11y ago

franciscop 11y ago
> all the teams would use the metric system, except one We all know which one. Side question: why don't tech companies help push the USA public towards the metric system and the SI (International System of Units) in general?
- ktRolster 11y ago
  Because units don't matter anymore ever since the units command line utility was created. I can use watts/hogshead or horsepower/liter just as easily as kilometers or miles. In practical terms, for the UI, it's best to use whatever customers are most comfortable with, since you don't want to scare them away over irrelevant issues.
  - franciscop 11y ago
    I'm sure in 1998 there was a similar utility such as units; still the Mars Climate Orbiter disaster [1] and the Gimli Glider [2] happened. By Engineers or technical people, not the general public. I'm sure everyday small misunderstandings/errors happen from the disparity. [1] https://en.m.wikipedia.org/wiki/Mars_Climate_Orbiter https://en.m.wikipedia.org/wiki/Mars_Climate_Orbiter [2] https://en.m.wikipedia.org/wiki/Gimli_Glider https://en.m.wikipedia.org/wiki/Gimli_Glider
    - garrettgrimsley 11y ago
      >I'm sure in 1998 there was a similar utility such as units; still the Mars Climate Orbiter disaster The utility did exist then, but a reading of the mishap report[0] for that event makes it clear that NASA was not using it. It looks like someone assigned a constant using the Imperial measure rather than Metric representation of a value. The function that used this constant did not verify the unit of measure, and the constant was likely just a floating point number, not a data type that even stored unit of measure. I haven't read the Gimli report yet, but it's probably the same story: human error. Edit: The Gimli Glider [1] was caused by human error. [0] ftp://ftp.hq.nasa.gov/pub/pao/reports/1999/MCO_report.pdf see page 16 [1] http://aviation-safety.net/database/record.php?id=19830723-0 http://aviation-safety.net/database/record.php?id=19830723-0
      - mpweiher 11y ago
        > probably the same story: human error. Right. Humans are error-prone. That's why you want to remove places where human can make errors, such as unnecessary unit conversions.
        garrettgrimsley 11y ago
        I agree, and I don't mean to argue against moving to the metric system. I only intended to dispel the notion that software safeguards that would have prevented these incidents were in place and failed. Educating developers about this potential issue and ensuring safeguards are in place to prevent disaster seems like a more readily achievable goal than inducing a national migration to the metric system.
        Ntrails 11y ago
        Sod national, I'm talking about corporate. If my company mandates that all code must be written in Lisp, then that's what I'll do. If they mandate all monetary values must be stored as USD then that's what I'll do. And if they require that all code must use the metric system - with display options to convert to imperial? Thats. What. I'll. Do. I don't care what the coding guidelines are - I only care that they exist. [within reason]
        zeveb 11y ago
        In aviation the standard units are traditional units; it's the French units which are non-standard and unnecessary. So the Right Answer is to switch to traditional units everywhere:-)
    - sokoloff 11y ago
      The Air Crash Investigations episode on the Gimli Glider is interesting: https://www.youtube.com/watch?v=cf2KCCv-NDo https://www.youtube.com/watch?v=cf2KCCv-NDo
  - majewsky 11y ago
    Fun fact: I recently used units(1) to convert a power of two of something, when it threw a syntax error on me because the power operator (like "2^6") was not known. It turned out that I was accidentally not using the units(1) from my Linux VM, but the one on my Mac's native terminal, which according to the manpage dates back to 1991. Apple has literally not gotten around to updating their units for 25 years.
    - coldtea 11y ago
      Actually Apple just uses the BSD-licenced version of units -- and not the GNU units -- which is currently at version 2.x. You can get "gunits" via Homebrew though...
  - jzwinck 11y ago
    As a former draftsman: this is not accurate. You might think that units are convertible and we have plenty of software for that. But it doesn't work that way. If a drawing says to drill 3mm holes and you have imperial drills, what to do? If a drawing says tolerance is 1/64 inch, how do you use your metric digital calipers quickly to verify it? If you have a paper drawing provided to you, which is the reality of life in the field, how do you visualize all the dimensions in your head if they are in a system of units you don't use every day? If you receive a part with 28mm wrench flats, how can you be sure they aren't meant for a 1 1/8 spanner? There are real mass produced parts where the metric female threads can easily be enlarged (or stripped!) to accept imperial male threads. But the converse doesn't work, and even if you possess a tap you probably don't have a metric thread gauge in your imperial shop. It goes on and on. Software won't eat this problem, so we have to.
    - sokoloff 11y ago
      Spot on, with one small exception. I suspect every machine shop has thread gauges for Imperial and metric. I'm a backyard hack and I have both, just because this problem is so common and annoying. 28mm is compatible "enough" to 1 1/8, as 14mm and 9/16 are a very common "either one works" interchange for sockets/wrenches.
- zeveb 11y ago
  > Side question: why don't tech companies help push the USA public towards the metric system and the SI (International System of Units) in general? Because French units are objectively worse for concrete manipulation (while being admittedly objectively superior for abstract conversion, and under the metric of popularity). Switch to decimal units was among the dumber ideas of the French Revolution; switching to duodecimal digits would have been far wiser.
smegel 11y ago
So do more faster? Sounds like something pointy-haired boss would say.
- distrill 11y ago
  That's not quite what I got from it. More like, here's a more robust way to go about writing software, that may end up saving you time in the long run.
- LoSboccacc 11y ago
  The post is not overly original but it does explain how being safer and how that makes you faster
mikekchar 11y ago
Google is failing me right now, but I remember Kent Beck explaining why he used the term "extreme" in XP. It refers to things like extreme skiing. You can helicopter to the top of a mountain and do crazy things, but you will get killed. Extreme skiers avoid getting killed by reducing risk. You break down all of your movements to their absolute basics and you perfect them. Then when you are skiing, you stick to those basics, performing them almost perfectly time after time. You never do anything extraordinary. By doing this you de-risk each movement to the point that you can chain them together and do something astonishing. In reality, though, extreme skiing (and extreme programming) is simply monotonous repetition of basic skills executed to near perfection. To me, this is what "agile" means. It means boiling it all down to a small set of skills that you can perfect and repeating them over and over again without exception. Because you are never taking any risks, the overall project can appear to be insane, but still be accomplished. If you are negotiating what you are doing by saying, "maybe we can get away with X", or "maybe this will be good enough", then you will not be able to achieve this kind of agility. And before someone asks: yes, the code will still not be perfect in the end. You goal is the perfection and de-risking of your actions not your artifacts. It is a subtle but important point.
- seivan 11y ago
  No risk, no experiments, no innovation and getting caught in a rut of mediocrity and boredom. I love experimenting and taking chances with code and ideas. Yeah you end up spending more nights and it might take more time or it might blow up in your face but what's the point of being a programmer if you can't push limits.
  - jtfairbank 11y ago
    You can certainly experiment and innovate. Nothing about agile stops you from adding an issue to spend half a day investigating the right tool to solve a problem, or implementing something two different ways to determine the best one. But by explicitly defining that objective and blocking out time to do that you de-risk the development process related to it. These "extreme" processes force you to define the motions (issues, work tasks) and allow you to practice getting them done using the same process over and over again.
jimjimjim 11y ago
basically: write some tests, write some docs, add some automated tests, checkin often, be sensible and try not to cut corners. how about: code like you are going to have to remove 2 features and add 3 new features to your code in 6 months time without the place burning down.
- insanebits 11y ago
  Yep, that is the reality most of the time. It would be easy if you had a fixed list of features for a project. But they change most of the time throughout the development. You get used to it and start planning accordingly.
junke 11y ago
While I agree with the content, I dislike the straw-man pattern that is so commonly found: "you can use method A stupidly or method B (my favorite) intelligently. Hence method B is the best." Take for example: > Developers work in total isolation for weeks or months at a time on feature branches and then try to merge all their work together into a release branch at the very last minute. You have also option 3: Come up with a specification (not design) for all the components up front in such a way that it minimizes integration risks. Split tasks and define interfaces and/or protocols so that the work can be developed in parallel. Still, try to follow up with the changes in other branches and keep your work up-to-date with major changes that may happen in the main branch. Try to merge to see if there is any conflict, but don't push half-work. However, if you have to modify a main component that is used by other in order to implement your thing, and that change can be merged back safely, do it as soon as possible.
- brikis98 11y ago
  Author here. FWIW, that sentence "Developers work in total isolation for weeks or months at a time on feature branches and then try to merge all their work together into a release branch at the very last minute" is actually the exact opposite of a straw man: it's a real occurrence I witnessed first hand at a number of companies (if you want to hear all the gory details about one of them, check out the book: http://www.hello-startup.net/ http://www.hello-startup.net/). There certainly are companies that are able to make feature branches work for them the way you described, but based on my personal experience and interviews with several dozen other successful companies, feature branches usually lead to disaster.
  - mistermann 11y ago
    Using one anecdotal experience as proof is not the exact opposite of a strawman. Similarly: "That one hour you “saved” by not writing tests will cost you five hours of tracking down a nasty bug in production, and five hours more when your “hotfix” causes a new bug." These numbers don't line up with any experience I've ever had. In my opinion the value of testing should stand on its own without having to exaggerate.
paulojreis 11y ago
I've been having some trainings on agility and software development, at an european Big Corp™ (where I work). Here at european Big Corp™, management is worried that our size is making us slow, and they also want to be cool like the start-up kids in the valley. As such, we've been using/trying to use Agile, but with very limited success. Big Corp™'s solution to this obviously low success is to buy thousands and thousands of Euros worth of training, with Agile and Scrum certified trainers and partners, which - every single time - repeat ad nauseam the same doctrine and dogmas, much like liturgy in a church. A few examples: * "So your colleagues are over-estimating every single task - pardon me, user story! - to have time to browse reddit? Estimate with story points, they'll see that their velocity is slow."; * "So your colleagues don't like resolving bugs? Put a bug chart in the office where everyone can see it, they'll feel guilty and solve them!"; * "So your colleagues don't like to create tests and write half-assed code, totally ignoring definitions of done and the like? Just wait until velocity drops because of technical debt, they'll understand and learn!". Well, what's my point here? Agile may require "safety" and all the technical goodies described in this article, but - before that - it requires a team of committed people. This is the basis of Agile and Scrum. And that's where my company fails, and that's why Agile - or any other approach - won't work here until people are responsible and committed. The build is now broken, will a team of uncommitted people will care? They'll push around the responsibility until someone fixes it. So, yeah, Agile requires safety; but, before that, it requires commitment. I feel it's an engineering-type trait, to try to solve human issues with tools (bug charts, code coverage, continuous integration/delivery), and many engineering-driven companies seem to play the game that way. But all these tools won't solve the real problems which explain why a team might be failing. And if a team is committed, they'll eventually succeed, even without the shiny tools and cool approaches.
- brikis98 11y ago
  > So, yeah, Agile requires safety; but, before that, it requires commitment. Completely agreed. There are certainly tools and processes that are more effective than others (as I discussed in the post), but for a creative discipline like programming, no process or tool will be effective unless the creators (the programmers) buy into it. That reminds me of a quote from Peopleware: > The maddening thing about most of our organizations is that they are only as good as the people who staff them. Wouldn't it be nice if we could get around that natural limit, and have good organizations even though they were staffed by mediocre or incompetent people? Nothing could be easier—all we need is (trumpet fanfare, please) a Methodology.
partycoder 11y ago
Agile enthusiasts really enjoy applying agile methodologies to functional requirements such as user stories. But non-functional requirements are rarely explicit: security, reliability, redundancy, durability, concurrency, performance, scalability, configuration, deployment, documentation, logging, monitoring, supervision, maintainability, construction for verification... You don't get a user story saying: "as a user i would like my information to be private" or "as a user i would not like to experience a concurrency bug". To neglect those non-functional requirements in favor of perceived progress is not in the company's best interest. A solution that doesn't comply with those requirements also has a name: a functional prototype. There's a difference between developing production software and developing prototypes, even if you consider yourself agile. Now, as a software engineer, you should be able to identify these requirements and include them in estimations. You can also ignore them, and project an image of a highly productive engineer, but some day your code will crash and you won't have 10 days to fix it. That day you will be miserably fired to the sound of a trumpet.
- robinwarren 11y ago
  I think most successful agile teams would adopt those non-functional requirements not as tasks to be implemented but as cross-cutting concerns of all work. Ie, on a Scrum team they could be part of the Definition of Done, ie "Is the code maintainable" which would not allow some work to be considered completed until it met that definition. I'm not 100% clear on what you are saying but it sounds like you think agile teams ignore these non-functional requirements in favour of perceived progress on features. I think that may well be true in practice but it is also true of non-agile teams. It is in fact just true of immature development teams the world over. Being agile or not has nothing to do with it. Scrum and other processes do at least try to have something in place to cater for these requirements, which often sadly get overlooked when pressure is applied to make flat out progress on features.
  - partycoder 11y ago
    I concur. But it was mostly in response to the article. I do believe though that there are many engineers that highly disregard good practices because they get a political benefit from releasing more. Just like politicians get appraisal when doing ribbon cutting at inaugurations, and never when repairing a bridge, many organizations promote the engineers that deliver more features, not the ones that keep the system working. By doing this they create a culture of technical debt and failure.
nxzero 11y ago
Agility requires prior knowledge and any action that puts that knowledge at risk of catastrophic lose is questionable. That said, agents taking on risks that are expendable without major loss of knowledge or unreasonable expenditures of resources will outperform competing systems that avoid loss at all costs.
hibikir 11y ago
I have done agile development successfully, and yet, the article rings very hollow for me, because most of its examples have very little to do with the principles the author tries to explain. For instance, he talks about working strategies, and puts Google as an example. Google is a terrible example for almost every other company out there. They have a gigantic monorepo, which is only manageable because they have custom tooling from hell. For most of us, the organization doesn't have said custom tooling from hell: The OSS version of bazel just doesn't work quite as well out of the box. If you aren't running a highly modified version control system like they do, check in performance dies. You might be able to pretend to be Google if you are tiny instead, but anyone in between will just meet suffering. It's a bit like trying to match apple in industrial design. Then there's the talk about feature flags. They are great, useful things, but there is also hidden suffering behind feature flagging all the things. There is much extra gardening required, and a completely different set of headaches when relatively large changes affecting the same parts of the code are being hidden behind feature flags. They have weird interactions too! And don't forget how much fun it is to have intermediate data structures changing for features that aren't active: He is just glossing over big, big problems, that happen to be different than the one he discusses. Given that the author is consulting for tiny startups, chances are he hasn't stared at those problems in the face, but they exist, and they are especially pernicious when your tiny company believes that imitating google will work, and then reaches 60-80 programmers: Then all the advice above starts to crack, and it only gets worse when you get into the 200 engineer range. The difficult part is not being a small company, where any and all practices will work. It's not that hard being huge either: Just invest heavily in your own ecosystem. PHP too slow? Rewrite it! Git too slow? Write a new engine for Mercurial! It is when a company is growing fast, bit isn't really large, when your technical practices can cost you your company, and the article's advice is PRECISELY the way to get murdered.
- brikis98 11y ago
  > For instance, he talks about working strategies, and puts Google as an example. First, I also listed LinkedIn and Facebook. Second, many small companies use the same strategies, but most people probably haven't heard of them, so they don't serve as particularly useful examples. > Given that the author is consulting for tiny startups, chances are he hasn't stared at those problems in the face If you're going to make an ad hominem argument, you should at least do a more thorough job of looking up my background :) I've worked at and with small, medium, and large companies. Every single tool and technique involves trade-offs, and no one approach will fit everyone, which is exactly the point I discuss at the end of the post.

128 points by runesoerensen 11y ago

> all the teams would use the metric system, except one We all know which one. Side question: why don't tech companies help push the USA public towards the metric system and the SI (International System of Units) in general?

ktRolster 11y ago
Because units don't matter anymore ever since the units command line utility was created. I can use watts/hogshead or horsepower/liter just as easily as kilometers or miles. In practical terms, for the UI, it's best to use whatever customers are most comfortable with, since you don't want to scare them away over irrelevant issues.
- franciscop 11y ago
  I'm sure in 1998 there was a similar utility such as units; still the Mars Climate Orbiter disaster [1] and the Gimli Glider [2] happened. By Engineers or technical people, not the general public. I'm sure everyday small misunderstandings/errors happen from the disparity. [1] https://en.m.wikipedia.org/wiki/Mars_Climate_Orbiter https://en.m.wikipedia.org/wiki/Mars_Climate_Orbiter [2] https://en.m.wikipedia.org/wiki/Gimli_Glider https://en.m.wikipedia.org/wiki/Gimli_Glider
  - garrettgrimsley 11y ago
    >I'm sure in 1998 there was a similar utility such as units; still the Mars Climate Orbiter disaster The utility did exist then, but a reading of the mishap report[0] for that event makes it clear that NASA was not using it. It looks like someone assigned a constant using the Imperial measure rather than Metric representation of a value. The function that used this constant did not verify the unit of measure, and the constant was likely just a floating point number, not a data type that even stored unit of measure. I haven't read the Gimli report yet, but it's probably the same story: human error. Edit: The Gimli Glider [1] was caused by human error. [0] ftp://ftp.hq.nasa.gov/pub/pao/reports/1999/MCO_report.pdf see page 16 [1] http://aviation-safety.net/database/record.php?id=19830723-0 http://aviation-safety.net/database/record.php?id=19830723-0
    - mpweiher 11y ago
      > probably the same story: human error. Right. Humans are error-prone. That's why you want to remove places where human can make errors, such as unnecessary unit conversions.
      - garrettgrimsley 11y ago
        I agree, and I don't mean to argue against moving to the metric system. I only intended to dispel the notion that software safeguards that would have prevented these incidents were in place and failed. Educating developers about this potential issue and ensuring safeguards are in place to prevent disaster seems like a more readily achievable goal than inducing a national migration to the metric system.
        Ntrails 11y ago
        Sod national, I'm talking about corporate. If my company mandates that all code must be written in Lisp, then that's what I'll do. If they mandate all monetary values must be stored as USD then that's what I'll do. And if they require that all code must use the metric system - with display options to convert to imperial? Thats. What. I'll. Do. I don't care what the coding guidelines are - I only care that they exist. [within reason]
      - zeveb 11y ago
        In aviation the standard units are traditional units; it's the French units which are non-standard and unnecessary. So the Right Answer is to switch to traditional units everywhere:-)
  - sokoloff 11y ago
    The Air Crash Investigations episode on the Gimli Glider is interesting: https://www.youtube.com/watch?v=cf2KCCv-NDo https://www.youtube.com/watch?v=cf2KCCv-NDo
- majewsky 11y ago
  Fun fact: I recently used units(1) to convert a power of two of something, when it threw a syntax error on me because the power operator (like "2^6") was not known. It turned out that I was accidentally not using the units(1) from my Linux VM, but the one on my Mac's native terminal, which according to the manpage dates back to 1991. Apple has literally not gotten around to updating their units for 25 years.
  - coldtea 11y ago
    Actually Apple just uses the BSD-licenced version of units -- and not the GNU units -- which is currently at version 2.x. You can get "gunits" via Homebrew though...
- jzwinck 11y ago
  As a former draftsman: this is not accurate. You might think that units are convertible and we have plenty of software for that. But it doesn't work that way. If a drawing says to drill 3mm holes and you have imperial drills, what to do? If a drawing says tolerance is 1/64 inch, how do you use your metric digital calipers quickly to verify it? If you have a paper drawing provided to you, which is the reality of life in the field, how do you visualize all the dimensions in your head if they are in a system of units you don't use every day? If you receive a part with 28mm wrench flats, how can you be sure they aren't meant for a 1 1/8 spanner? There are real mass produced parts where the metric female threads can easily be enlarged (or stripped!) to accept imperial male threads. But the converse doesn't work, and even if you possess a tap you probably don't have a metric thread gauge in your imperial shop. It goes on and on. Software won't eat this problem, so we have to.
  - sokoloff 11y ago
    Spot on, with one small exception. I suspect every machine shop has thread gauges for Imperial and metric. I'm a backyard hack and I have both, just because this problem is so common and annoying. 28mm is compatible "enough" to 1 1/8, as 14mm and 9/16 are a very common "either one works" interchange for sockets/wrenches.
zeveb 11y ago
> Side question: why don't tech companies help push the USA public towards the metric system and the SI (International System of Units) in general? Because French units are objectively worse for concrete manipulation (while being admittedly objectively superior for abstract conversion, and under the metric of popularity). Switch to decimal units was among the dumber ideas of the French Revolution; switching to duodecimal digits would have been far wiser.

smegel 11y ago

So do more faster? Sounds like something pointy-haired boss would say.

distrill 11y ago
That's not quite what I got from it. More like, here's a more robust way to go about writing software, that may end up saving you time in the long run.
LoSboccacc 11y ago
The post is not overly original but it does explain how being safer and how that makes you faster

mikekchar 11y ago

Google is failing me right now, but I remember Kent Beck explaining why he used the term "extreme" in XP. It refers to things like extreme skiing. You can helicopter to the top of a mountain and do crazy things, but you will get killed. Extreme skiers avoid getting killed by reducing risk. You break down all of your movements to their absolute basics and you perfect them. Then when you are skiing, you stick to those basics, performing them almost perfectly time after time. You never do anything extraordinary. By doing this you de-risk each movement to the point that you can chain them together and do something astonishing. In reality, though, extreme skiing (and extreme programming) is simply monotonous repetition of basic skills executed to near perfection. To me, this is what "agile" means. It means boiling it all down to a small set of skills that you can perfect and repeating them over and over again without exception. Because you are never taking any risks, the overall project can appear to be insane, but still be accomplished. If you are negotiating what you are doing by saying, "maybe we can get away with X", or "maybe this will be good enough", then you will not be able to achieve this kind of agility. And before someone asks: yes, the code will still not be perfect in the end. You goal is the perfection and de-risking of your actions not your artifacts. It is a subtle but important point.

seivan 11y ago
No risk, no experiments, no innovation and getting caught in a rut of mediocrity and boredom. I love experimenting and taking chances with code and ideas. Yeah you end up spending more nights and it might take more time or it might blow up in your face but what's the point of being a programmer if you can't push limits.
- jtfairbank 11y ago
  You can certainly experiment and innovate. Nothing about agile stops you from adding an issue to spend half a day investigating the right tool to solve a problem, or implementing something two different ways to determine the best one. But by explicitly defining that objective and blocking out time to do that you de-risk the development process related to it. These "extreme" processes force you to define the motions (issues, work tasks) and allow you to practice getting them done using the same process over and over again.

jimjimjim 11y ago

basically: write some tests, write some docs, add some automated tests, checkin often, be sensible and try not to cut corners. how about: code like you are going to have to remove 2 features and add 3 new features to your code in 6 months time without the place burning down.

insanebits 11y ago
Yep, that is the reality most of the time. It would be easy if you had a fixed list of features for a project. But they change most of the time throughout the development. You get used to it and start planning accordingly.

junke 11y ago

While I agree with the content, I dislike the straw-man pattern that is so commonly found: "you can use method A stupidly or method B (my favorite) intelligently. Hence method B is the best." Take for example: > Developers work in total isolation for weeks or months at a time on feature branches and then try to merge all their work together into a release branch at the very last minute. You have also option 3: Come up with a specification (not design) for all the components up front in such a way that it minimizes integration risks. Split tasks and define interfaces and/or protocols so that the work can be developed in parallel. Still, try to follow up with the changes in other branches and keep your work up-to-date with major changes that may happen in the main branch. Try to merge to see if there is any conflict, but don't push half-work. However, if you have to modify a main component that is used by other in order to implement your thing, and that change can be merged back safely, do it as soon as possible.

brikis98 11y ago
Author here. FWIW, that sentence "Developers work in total isolation for weeks or months at a time on feature branches and then try to merge all their work together into a release branch at the very last minute" is actually the exact opposite of a straw man: it's a real occurrence I witnessed first hand at a number of companies (if you want to hear all the gory details about one of them, check out the book: http://www.hello-startup.net/ http://www.hello-startup.net/). There certainly are companies that are able to make feature branches work for them the way you described, but based on my personal experience and interviews with several dozen other successful companies, feature branches usually lead to disaster.
- mistermann 11y ago
  Using one anecdotal experience as proof is not the exact opposite of a strawman. Similarly: "That one hour you “saved” by not writing tests will cost you five hours of tracking down a nasty bug in production, and five hours more when your “hotfix” causes a new bug." These numbers don't line up with any experience I've ever had. In my opinion the value of testing should stand on its own without having to exaggerate.

paulojreis 11y ago

I've been having some trainings on agility and software development, at an european Big Corp™ (where I work). Here at european Big Corp™, management is worried that our size is making us slow, and they also want to be cool like the start-up kids in the valley. As such, we've been using/trying to use Agile, but with very limited success. Big Corp™'s solution to this obviously low success is to buy thousands and thousands of Euros worth of training, with Agile and Scrum certified trainers and partners, which - every single time - repeat ad nauseam the same doctrine and dogmas, much like liturgy in a church. A few examples: * "So your colleagues are over-estimating every single task - pardon me, user story! - to have time to browse reddit? Estimate with story points, they'll see that their velocity is slow."; * "So your colleagues don't like resolving bugs? Put a bug chart in the office where everyone can see it, they'll feel guilty and solve them!"; * "So your colleagues don't like to create tests and write half-assed code, totally ignoring definitions of done and the like? Just wait until velocity drops because of technical debt, they'll understand and learn!". Well, what's my point here? Agile may require "safety" and all the technical goodies described in this article, but - before that - it requires a team of committed people. This is the basis of Agile and Scrum. And that's where my company fails, and that's why Agile - or any other approach - won't work here until people are responsible and committed. The build is now broken, will a team of uncommitted people will care? They'll push around the responsibility until someone fixes it. So, yeah, Agile requires safety; but, before that, it requires commitment. I feel it's an engineering-type trait, to try to solve human issues with tools (bug charts, code coverage, continuous integration/delivery), and many engineering-driven companies seem to play the game that way. But all these tools won't solve the real problems which explain why a team might be failing. And if a team is committed, they'll eventually succeed, even without the shiny tools and cool approaches.

brikis98 11y ago
> So, yeah, Agile requires safety; but, before that, it requires commitment. Completely agreed. There are certainly tools and processes that are more effective than others (as I discussed in the post), but for a creative discipline like programming, no process or tool will be effective unless the creators (the programmers) buy into it. That reminds me of a quote from Peopleware: > The maddening thing about most of our organizations is that they are only as good as the people who staff them. Wouldn't it be nice if we could get around that natural limit, and have good organizations even though they were staffed by mediocre or incompetent people? Nothing could be easier—all we need is (trumpet fanfare, please) a Methodology.

partycoder 11y ago

Agile enthusiasts really enjoy applying agile methodologies to functional requirements such as user stories. But non-functional requirements are rarely explicit: security, reliability, redundancy, durability, concurrency, performance, scalability, configuration, deployment, documentation, logging, monitoring, supervision, maintainability, construction for verification... You don't get a user story saying: "as a user i would like my information to be private" or "as a user i would not like to experience a concurrency bug". To neglect those non-functional requirements in favor of perceived progress is not in the company's best interest. A solution that doesn't comply with those requirements also has a name: a functional prototype. There's a difference between developing production software and developing prototypes, even if you consider yourself agile. Now, as a software engineer, you should be able to identify these requirements and include them in estimations. You can also ignore them, and project an image of a highly productive engineer, but some day your code will crash and you won't have 10 days to fix it. That day you will be miserably fired to the sound of a trumpet.

robinwarren 11y ago
I think most successful agile teams would adopt those non-functional requirements not as tasks to be implemented but as cross-cutting concerns of all work. Ie, on a Scrum team they could be part of the Definition of Done, ie "Is the code maintainable" which would not allow some work to be considered completed until it met that definition. I'm not 100% clear on what you are saying but it sounds like you think agile teams ignore these non-functional requirements in favour of perceived progress on features. I think that may well be true in practice but it is also true of non-agile teams. It is in fact just true of immature development teams the world over. Being agile or not has nothing to do with it. Scrum and other processes do at least try to have something in place to cater for these requirements, which often sadly get overlooked when pressure is applied to make flat out progress on features.
- partycoder 11y ago
  I concur. But it was mostly in response to the article. I do believe though that there are many engineers that highly disregard good practices because they get a political benefit from releasing more. Just like politicians get appraisal when doing ribbon cutting at inaugurations, and never when repairing a bridge, many organizations promote the engineers that deliver more features, not the ones that keep the system working. By doing this they create a culture of technical debt and failure.

nxzero 11y ago

Agility requires prior knowledge and any action that puts that knowledge at risk of catastrophic lose is questionable. That said, agents taking on risks that are expendable without major loss of knowledge or unreasonable expenditures of resources will outperform competing systems that avoid loss at all costs.

hibikir 11y ago

I have done agile development successfully, and yet, the article rings very hollow for me, because most of its examples have very little to do with the principles the author tries to explain. For instance, he talks about working strategies, and puts Google as an example. Google is a terrible example for almost every other company out there. They have a gigantic monorepo, which is only manageable because they have custom tooling from hell. For most of us, the organization doesn't have said custom tooling from hell: The OSS version of bazel just doesn't work quite as well out of the box. If you aren't running a highly modified version control system like they do, check in performance dies. You might be able to pretend to be Google if you are tiny instead, but anyone in between will just meet suffering. It's a bit like trying to match apple in industrial design. Then there's the talk about feature flags. They are great, useful things, but there is also hidden suffering behind feature flagging all the things. There is much extra gardening required, and a completely different set of headaches when relatively large changes affecting the same parts of the code are being hidden behind feature flags. They have weird interactions too! And don't forget how much fun it is to have intermediate data structures changing for features that aren't active: He is just glossing over big, big problems, that happen to be different than the one he discusses. Given that the author is consulting for tiny startups, chances are he hasn't stared at those problems in the face, but they exist, and they are especially pernicious when your tiny company believes that imitating google will work, and then reaches 60-80 programmers: Then all the advice above starts to crack, and it only gets worse when you get into the 200 engineer range. The difficult part is not being a small company, where any and all practices will work. It's not that hard being huge either: Just invest heavily in your own ecosystem. PHP too slow? Rewrite it! Git too slow? Write a new engine for Mercurial! It is when a company is growing fast, bit isn't really large, when your technical practices can cost you your company, and the article's advice is PRECISELY the way to get murdered.

brikis98 11y ago
> For instance, he talks about working strategies, and puts Google as an example. First, I also listed LinkedIn and Facebook. Second, many small companies use the same strategies, but most people probably haven't heard of them, so they don't serve as particularly useful examples. > Given that the author is consulting for tiny startups, chances are he hasn't stared at those problems in the face If you're going to make an ad hominem argument, you should at least do a more thorough job of looking up my background :) I've worked at and with small, medium, and large companies. Every single tool and technique involves trade-offs, and no one approach will fit everyone, which is exactly the point I discuss at the end of the post.