{"componentChunkName":"component---node-modules-gatsby-theme-medium-to-own-blog-src-templates-blog-post-js","path":"/two-years-of-programmer-anarchy/","result":{"data":{"site":{"siteMetadata":{"siteUrl":"https://javame.netlify.app","githubUrl":"https://github.com/aterreno/blog"}},"mdx":{"fields":{"slug":"/two-years-of-programmer-anarchy/"},"excerpt":"Two years passed since  Fred George  and I wrote the  Programmer Anarchy paper , in those two years Fred  went all around the world…","timeToRead":5,"frontmatter":{"title":"Two years of programmer anarchy","description":"","categories":[],"date":"August 20, 2012","canonical_link":"https://javame.netlify.app//two-years-of-programmer-anarchy-7f8a85ec4717"},"body":"function _extends() { _extends = Object.assign || function (target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] = source[key]; } } } return target; }; return _extends.apply(this, arguments); }\n\nfunction _objectWithoutProperties(source, excluded) { if (source == null) return {}; var target = _objectWithoutPropertiesLoose(source, excluded); var key, i; if (Object.getOwnPropertySymbols) { var sourceSymbolKeys = Object.getOwnPropertySymbols(source); for (i = 0; i < sourceSymbolKeys.length; i++) { key = sourceSymbolKeys[i]; if (excluded.indexOf(key) >= 0) continue; if (!Object.prototype.propertyIsEnumerable.call(source, key)) continue; target[key] = source[key]; } } return target; }\n\nfunction _objectWithoutPropertiesLoose(source, excluded) { if (source == null) return {}; var target = {}; var sourceKeys = Object.keys(source); var key, i; for (i = 0; i < sourceKeys.length; i++) { key = sourceKeys[i]; if (excluded.indexOf(key) >= 0) continue; target[key] = source[key]; } return target; }\n\n/* @jsxRuntime classic */\n\n/* @jsx mdx */\nvar _frontmatter = {\n  \"title\": \"Two years of programmer anarchy\",\n  \"description\": \"\",\n  \"date\": \"2012-08-20T00:00:00.000Z\",\n  \"categories\": [],\n  \"published\": true,\n  \"canonical_link\": \"https://javame.netlify.app//two-years-of-programmer-anarchy-7f8a85ec4717\",\n  \"redirect_from\": [\"/two-years-of-programmer-anarchy-7f8a85ec4717\"]\n};\nvar layoutProps = {\n  _frontmatter: _frontmatter\n};\nvar MDXLayout = \"wrapper\";\nreturn function MDXContent(_ref) {\n  var components = _ref.components,\n      props = _objectWithoutProperties(_ref, [\"components\"]);\n\n  return mdx(MDXLayout, _extends({}, layoutProps, props, {\n    components: components,\n    mdxType: \"MDXLayout\"\n  }), mdx(\"p\", null, \"Two years passed since \", mdx(\"a\", _extends({\n    parentName: \"p\"\n  }, {\n    \"href\": \"http://www.linkedin.com/pub/fred-george/0/5b5/596\",\n    \"target\": \"_blank\",\n    \"rel\": \"nofollow noopener noreferrer\"\n  }), \"Fred George\"), \" and I wrote the \", mdx(\"a\", _extends({\n    parentName: \"p\"\n  }, {\n    \"href\": \"https://www.dropbox.com/s/omqe86y4nu0z6uy/Leaner%20Programmer%20Anarchy%20v2.pdf?dl=0\",\n    \"target\": \"_blank\",\n    \"rel\": \"nofollow noopener noreferrer\"\n  }), \"Programmer Anarchy paper\"), \", in those two years Fred \", mdx(\"a\", _extends({\n    parentName: \"p\"\n  }, {\n    \"href\": \"http://www.infoq.com/presentations/Leaner-Programmer-Anarchy\",\n    \"target\": \"_blank\",\n    \"rel\": \"nofollow noopener noreferrer\"\n  }), \"went all around the world\"), \" explaining what was happening here at \", mdx(\"a\", _extends({\n    parentName: \"p\"\n  }, {\n    \"href\": \"http://www.forward.co.uk/\",\n    \"target\": \"_blank\",\n    \"rel\": \"nofollow noopener noreferrer\"\n  }), \"Forward\"), \" and meanwhile I was here experiencing the Anarchy. This blog post is a writeup of this last two years experience, what worked well, what worked less well. To start with, let\\u2019s call it with a different name, which doesn\\u2019t implies chaos and confusion, Anarchy is not a new thing in the agile world, many people refer at it as self-organising teams.\"), mdx(\"p\", null, mdx(\"strong\", {\n    parentName: \"p\"\n  }, \"When does it work well?\")), mdx(\"p\", null, \"It works well when the manager is absent or fully trusting the team. One of the main selling point of Fred Anarchy was the lack of managers in the picture. Well, some sort of business owner, idea creator still needs to be present. That person needs to fully trust the team, ideally needs to be an ex-developer. I never seen in my life a manager without a past in developing software that can trust and understand their team. I truly believe that the most performing teams have developers to lead them and drive the business, google apparently is one of those example. Brandon Keeper recently wrote about \", mdx(\"a\", _extends({\n    parentName: \"p\"\n  }, {\n    \"href\": \"http://opensoul.org/blog/archives/2012/06/05/whats-it-like-to-work-at-github/\",\n    \"target\": \"_blank\",\n    \"rel\": \"nofollow noopener noreferrer\"\n  }), \"Github anarchy\"), \".\"), mdx(\"p\", null, mdx(\"strong\", {\n    parentName: \"p\"\n  }, \"It works well with small teams\")), mdx(\"p\", null, \"I always loved the magic number of 5 developers per team and believed that is enough to build anything in the world. Sometimes you need to increase the WIP and have more developers, without some sort of leadership the team will lack focus and direction. Selforganising team it\\u2019s one of the facets of Agile. It\\u2019s not an arrving point, it\\u2019s not a silver bullet. It\\u2019s something to try as any other practise. I did found however that it requires experience and time to glue the team up together. If I go back in time with my memories, back in 2007, \", mdx(\"a\", _extends({\n    parentName: \"p\"\n  }, {\n    \"href\": \"http://db.tt/XsgLyEGe\",\n    \"target\": \"_blank\",\n    \"rel\": \"nofollow noopener noreferrer\"\n  }), \"the FM team was self organizing\"), \", but it took us few months before reaching that level of maturity when everybody knew what to do and how. We did reach at that level of self organisation leveraging pair programming, a solid, team owned code base, a kanban wall. We had a great agile project manager to help us focus and a great \", mdx(\"a\", _extends({\n    parentName: \"p\"\n  }, {\n    \"href\": \"http://www.thekua.com/atwork/\",\n    \"target\": \"_blank\",\n    \"rel\": \"nofollow noopener noreferrer\"\n  }), \"tech leader\"), \" who rather than leading was just coordinating us and helping us to climb the ladder of self organization.\"), mdx(\"p\", null, mdx(\"strong\", {\n    parentName: \"p\"\n  }, \"What I didn\\u2019t like / What didn\\u2019t work well.\")), mdx(\"p\", null, mdx(\"strong\", {\n    parentName: \"p\"\n  }, \"Not Pairing.\")), mdx(\"p\", null, \"Assuming that you are a mature, highly skilled and performing team the code quality won\\u2019t fall down. What will feel down will be the knowledge sharing, you will need to introduce weekly showcases, increase artificially the communication inside the team.\"), mdx(\"p\", null, mdx(\"strong\", {\n    parentName: \"p\"\n  }, \"Polyglot anarchy.\")), mdx(\"p\", null, \"When I used to be a consultant I always suffered the lack of polyglotism in big enterprise companies. I had to be part of Forward to understand what full polyglot anarchy means. If you write your software in a new funky language, using a new funky application server in a new funky infrastructure you will have not only to maintain it but also to support it. And if the system has to be up and running 24/7 that may lead to some issues. Assuming that your sysadmins on support know everything from clojure to node.js, from golang to asyncronous javascript this choice is still pretty risky. The team should take responsability of keeping the system up and running, but on the long term having a whole team on call at night, day and holidays is not really feasable. I still don\\u2019t have a solution to this, I guess that the sysadmin should pair with the team, learn the caveats of any system built by the team itself. I also start to believe that fixing some constraints in the infrastructure is not such a big deal: let\\u2019s say everything will be built on the jvm, that would still give a decent choice to the teams, leaving some sort of consistency around the deployment and the live real time troubleshooting issues.\"), mdx(\"p\", null, mdx(\"strong\", {\n    parentName: \"p\"\n  }, \"No Iterations.\")), mdx(\"p\", null, \"I am not a big fan of Scrum and generally time boxed iterations, however, the human brain tends to forget the passing of the time, that\\u2019s why we have cuckoo clocks, bells towers and so on. Having iterations while releasing software helps you to realise that time is passing, helps you being more self conscious of the passing of the time. Having iterations creates a safe environment for other rituals such as: team dinners, retrospectives, one2ones with team members, feedback sessions. Most senior developers probably would have the concept of time passing always in the back of their mind, but again, why stopping having iterations if we will have, again, artificially set some dates on a calendar for having agile rituals? Without iterations it\\u2019s also hard to plan for slack, or \", mdx(\"a\", _extends({\n    parentName: \"p\"\n  }, {\n    \"href\": \"http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.23.2798&rep=rep1&type=pdf\",\n    \"target\": \"_blank\",\n    \"rel\": \"nofollow noopener noreferrer\"\n  }), \"Golden Cards\"), \".\"), mdx(\"p\", null, mdx(\"strong\", {\n    parentName: \"p\"\n  }, \"No Estimations and no stories.\")), mdx(\"p\", null, \"I realised that moving a user story on the cardwall is a ritual that causes happiness, sense of completion. If Fred is right when he talks about the story tyranny it\\u2019s also true that without users stories (see \", mdx(\"a\", _extends({\n    parentName: \"p\"\n  }, {\n    \"href\": \"http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/\",\n    \"target\": \"_blank\",\n    \"rel\": \"nofollow noopener noreferrer\"\n  }), \"INVEST in Good Stories and SMART tasks\"), \") and doing continuous deployment the risk of having continuous requirements is pretty high. As a developer you are never done because there will be always something more to do, as a product owner you will never see the end, you will always add new features. People work in contexts and a context can be long as much as one year. When is the end of the context? Unknown. It\\u2019s hard to define done, impossible to estimate, adds way too much uncertainty to the work in progress.\"), mdx(\"p\", null, mdx(\"strong\", {\n    parentName: \"p\"\n  }, \"Standups.\")), mdx(\"p\", null, \"Knowing what the team is doing and if the team needs help is a well established right and duty of any team (not only in IT). If you walk in the morning at Forward these days between 9 and 10 you will see almost every single team standing up. Unless you are a team of 2 people the standup is a must have, and it\\u2019s such a little effort.\"), mdx(\"p\", null, mdx(\"strong\", {\n    parentName: \"p\"\n  }, \"No Tests.\")), mdx(\"p\", null, \"Well \", mdx(\"a\", _extends({\n    parentName: \"p\"\n  }, {\n    \"href\": \"http://dannorth.net/2011/01/15/on-craftsmanship/\",\n    \"target\": \"_blank\",\n    \"rel\": \"nofollow noopener noreferrer\"\n  }), \"Dan\"), \" wrote quite a bit around this area, the spike and stabilize and Liz replied to that blog post \", mdx(\"a\", _extends({\n    parentName: \"p\"\n  }, {\n    \"href\": \"http://lizkeogh.com/2012/06/24/beyond-test-driven-development/\",\n    \"target\": \"_blank\",\n    \"rel\": \"nofollow noopener noreferrer\"\n  }), \"here\"), \". Of all the practices I\\u2019ve abandoned in these last years tests is probably the one I missed the least. It\\u2019s still very dangerous to preach for stopping writing tests. Writing a lot of tests makes you become a better developer. Writing tests in most contexts is a must have.\"), mdx(\"p\", null, mdx(\"strong\", {\n    parentName: \"p\"\n  }, \"No Refactoring/Rewrite and write in micro services\")), mdx(\"p\", null, \"Without tests, writing the code in a dynamic language forced us to write small components and rewrite them instead of refactoring them. What in the past was a module in an enterprise application became a separate codebase talking with other components mainly in json. A part from obvious performance (if performance is important in your context) issues, I found this approach a little wasteful as well. Rewrite comes from lack of analysis (lack of user stories) and lack of correct design in the first place (lack of test driven development). I found more satisfying (and probably more effective) writing my software the first time \\u201Cgood enough\\u201D and then improving it step by step with refactoring. My brain works that way not only for coding. Imagine finding the optimal walking path from home to work, optimizing different things, sightseeing, traffic, pedestrian paths, shops you want to pass by. Refactoring is improving it every day. Rewriting is like coming back once every 3/6 months, for the first 3 months you will walk a shitty path, the next 3 months something better and so on. Rewriting it\\u2019s kaikaku while kaizen is refactoring. Again it all depends on the contexts, but, at least in my experience continuous refactoring is a pleasant activity while continuous rewriting is rather frustrating.\"));\n}\n;\nMDXContent.isMDXComponent = true;"},"allWebMentionEntry":{"nodes":[]}},"pageContext":{"id":"62523819-8b06-5595-879e-8586d59aaf41","previous":{"id":"8d84d711-aa3d-5994-992c-79c9e6fde79d","fields":{"slug":"/luxr-luxi-books-shopping-list/","published":true},"frontmatter":{"redirect_from":["/luxr-luxi-books-shopping-list-8f9636a4ca77"],"redirect_to":null,"title":"#luxr LUXi books shopping list"}},"next":{"id":"58569d45-df5c-5fe4-9d8a-1653d6f37037","fields":{"slug":"/composing-html-fragments-with-mustache-and-clojure/","published":true},"frontmatter":{"redirect_from":["/composing-html-fragments-with-mustache-and-clojure-62bb3e8ad935"],"redirect_to":null,"title":"Composing html fragments with Mustache and Clojure"}},"permalink":"https://javame.netlify.app/two-years-of-programmer-anarchy/","themeOptions":{"plugins":[],"config":{"title":"Antonio Terreno","description":"Antonio Terreno's blog archive","shortBio":"","bio":"Principal Consultant at Equal Experts","author":"Antonio Terreno","githubUrl":"https://github.com/aterreno/blog","siteUrl":"https://javame.netlify.app/","social":{"twitter":"javame","medium":"","facebook":"","github":"aterreno","linkedin":"antonioterreno","instagram":"tritonitri"},"goatCounterCode":null}}}},"staticQueryHashes":["4131332129","645483741"]}