Most interesting links of Mars '13
- Agile in a Nutshell (originally Agile Product Ownership in a Nutshell) by Henrik Kniberg - the best explanation of the agile development process ever, in just 15 minutes and with wonderful animation; every developer should see this. Some highlights: the most important task of product owner is to say NO so that backlog doesn't grow infinitely; at start, the estimates of size and value will suck and that's OK because the value is in the conversation, not in the numbers (that are anyway just relative); the goal is to maximize outcome (value), not output (# features). Compromises between short-term vs. long-term goals, knowledge vs. customer value building etc. Build the right thing (PO) x build it right (devs) x build it fast (SM). Technical debt x sustainable pace. As I said - you MUST see it.
- Martin Fowler: The Value of Software Design (talk, 22 min, from 0:45:00 til 1:07; Feb 2013) - a balanced argument for the value of good software design and internal code quality based on paying off by enabling us to keep our development speed. Discusses the DesignStaminaHypothesis (bad design => rapid decline of development speed), TechnicalDebt, TechnicalDebtQuadrant (Prudent x Reckless, Deliberate x Inadvertent), TradableQualityHypothesis. According to the experience of Fowler and others, the good design payoff point "it's weeks, not months."
- What Does It Take To Become A Grandmaster Developer? - great post about cognition and learning, valuable references, quotes from an interesting study of good vs. mediocre developers. We have mental capacity for ~7 chunks of information => great performers recognize patterns and see and understand thus higher-level chunks and have many "chunks" (patterns encountered previously) readily available. You need deliberate effort to learn more chunks - especially initially but you must always try to get out of your comfort zone to grow. Experienced collegues can help a lot in acending the learning curve.
- How to Prioritize a User Story Map - we all know that we should prioritize features by their value, risk, and lack of knowledge and that we should slice the features thin so that they fit into short iteration and can be deployed soon to produce feedback, right? Here we see a nice example of what happens if not done so and how to do feature slicing better.
- Bob Marshall: Rightshifting - according to the author, 80% of knowledge work organizations are very ineffective, wasting resources on non-value-adding activites; only few are effective, even fewer highly effective. Rightshifting is the attempt at shiting them to the right, towards higher effectiveness. Links to a few videos explaining it more. Related: Steve McConnell's Business Case for Better Software Practices, referring to a study by SEI; "The actual distribution of software effectiveness is asymmetric. Most organizations perform much closer to the worst practice than to the best." - the best performing 10 times better then the worst/average (productivity, speed, defects, value)
- On Antifragility in Systems and Organizational Architecture - introduces the concept of antifragility, based on Nassim Taleb's book Antifragile that compares fragile, robust, and antifragile systems and organizational structures (which is also applicable to SW systems); robust = resists change (unless too large); antifragile: learn, adapt; closely related to DevOps and continous delivery
- M. Fowler: PurposeOfEstimation - many Agilist disdain estimation, this is a balanced view: "estimation is valuable when it helps you make a significant decision." (F.ex. when deciding what we (don't) have resources for or when in need of coordinating related activities.) It is evil when used as commitments that people are forced to stick to and blamed for not managing to do so. "Above all be wary of anyone who tells you they [estimates] are always needed, or never needed." A. Ferguson: "[..] it is poor project management (whether by project managers or other team members) that results in a client who thinks estimates are fixed, or that raw estimates = actual effort/duration".
- Ron Jeffries: Estimation is Evil - discusses the problems estimates can cause, issues with requirements gathering up front and their volatility, transparency and politics. Very valuable, highly recommended. See the "favorite quotes" at the bottom of this post. Also contains an interesting lesson learnt from the failed Chrysler C3 project: don't try to build a grand new system to replace and fix the old one, fix one problem at a time - worth reading for this alone.
- Interview with Steve Blank: Why Big Companies Can’t Innovate - the 2013 list of the world’s 50 most innovative companies has only a few large, established firms (those that have built innovation into its DNA such as Apple and Google). Established companies are less innovative because they focus in their existing business model, have risk-aversion (while there are many failures on the way to a new business model); finally "the people who are best suited to search for new business models and conduct iterative experiments usually are not the same managers who succeed at running existing business units." - and thus aren't given the chance. "[..] the process of starting a new business [..] is fundamentally different from running an existing one. So if you want your company to grow organically, then you need to organize your efforts around these differences."
- M. Fowler: Schemalessness + NoSQL and Consistency (20 + 20 min) two short, very good, balanced talks about NoSQL. He explains schemalessness and consistency and points out common misunderstanding about them so if you are into NoSQL, watch it.
- What Powers Instagram: Hundreds of Instances, Dozens of Technologies (2012) - interesting high-level overview of the Instagram infrastructure based on AWS and Python (25 XL instances running Django/Gunicorn behind ELB with 3 Nginxes, sharded PostgreSQL with streaming replication on 12 QXL mem instances with software raid and XFS to freeze when snapshoting, media in S3, Redis, Solr for geo-search, Memcached. Gearman for task queues, pyapns for notifications. Munin for monitoring.)
- The Netflix API Optimization Story - how Netflix redesigned its APIs to improve performance, reduce chattiness, and power product development and experimentation. The common REST API has become a development bottleneck and a lowest common denominator solution (w.r.t. supporting various clients). The main changes were: usage Hystrix for fault tolerance, each device team managing their own end-points in any JVM languges (primarily Groovy) and re-using common APIs (i.e. pushing some device-specific code to the server) => able to experiemnt more quickly, using the Functional Reactive Programming Model and asynchronous APIs (to abstract away thread-safety and parallel execution implementation details from the device teams so that code can execute sync. or async. without them needing to know).
- Me: Overview of current monitoring libs for Java - Netflix' Servo, Yammer's Metrics, JavaMelody, JavaSimon.
- Debug Servlets, or 'HTTP Won; Use It' - expose all debugging info of your services over HTTP - it makes debugging much simpler. We do a part of it and it really helps. Expose config (values, where they come from), logs, log configuration, JMX (setting it up otherwise not trivial), version, build number, git hash, server time (timezones tricky), metrics, stack dumps, app-specific status (Hadoop: live nodes, data size etc.). The author recommends JavaMelody to collect & visualize many common metrics. Not on security: Make sure to hide passwords and make the endpoints visible only internally. (Tip: consider Jolokia for exposing JMX over HTTP, see below.)
- JVM Crash/Core Dump Analysis - 3 common categories of JVM crash causes (JVM/JIT/JNI) and how to recognize and troubleshoot them
- How to lose wight in the browser: The definitive front-end performance guide - a site by a number of experts from Twitter, Opera, Google, and other places with best practices for performant web sites (HTML, CSS, JS, jQuery, images). Ex.: styles up top, scripts down bottom; minify your html, css and JS; async script loading; combine css/JS files into one; cache array lengths while looping; use css sprites for icons.
- Luke Stevens: The harsh truth about HTML5′s structural semantics (part 1) - "HTML’s structural elements — article, section, nav and aside — are, at first glance, some of the easiest parts of the HTML5 specification to understand and implement. However, they’re actually some of the most poorly specified, poorly understood, and poorly implemented parts of HTML5." Interesting: The "research" leading to their establishment was quite random, ignoring a crucial source of information (css IDs).
- Marco Emmanuel Patiño: Six non-technical books every programmer should read - 1. Team Geek: A Software Developer’s Guide to Working Well with Others (-> effective communication and collaboration), 2. The Pragmatic Programmer: From Journeyman to Master, 3. The Passionate Programmer: Creating a Remarkable Career in Software Development, 4. Clean Code: A Handbook of Agile Software Craftsmanship, 5. 97 Things Every Programmer Should Know: Collective Wisdom from the Experts (online), 6. Code Simplicity: The Fundamentals of Software.
- Related: Top 5 Java programming books - Best of lot (actually 8) - 1) Head First Java, 2) Effective Java, 3) Thinking in Java, 4) Head First Design Pattern, 5) Concurrency Practice in Java, 6)Java performance, 7) Java Puzzlers, 8) Head First Object Oriented Analysis and Design.
- Humans as slaves of chemistry: America's Real Criminal Element - Lead - a fascinating article about how whole nations can be seriously influenced by a single chemical substance. Aside of that it is also fascinating to observe how we tend to search for causes in our domain of expertise (police, sociologists, ...) and of interest while denying other possible causes, no matter how strong are the proofs. If the facts presented are true, then the fivefold increase in serious crimes in (not only) America since 60s has been caused by the increase of lead in the environment (pushing many people over the edge of ocassional violent loss of control). How many social problems in the world have similar industrial causes? Are we careful enough with what we let into our air and bodies?
- newcoder.io: Learning more Python via projects - an excellent next step when you have learned Python syntax via LPHW or similar; in this tutorial series you will be building real-world apps while learning more of Python. You will play with, Data Visualization, APIs, Web Scraping, Networks, GUI.
- Brian McCallister: Go is PHP for the Backend - a very good explanation why you might want to use Go and that you have to first learn "the Go way" to avoid insanity, since it is very opinionated and different from what you might be used to. Some pros: "native code, UNIX friendly, higher level then C, lower level then Python or Ruby, garbage collected, strongly typed, good performance, good concurrency support, etc."
- The Neophyte's Guide to Scala 1 to 15 (list) - a good follow-up on the Cursera FP in Scala course, a series of blog posts exploring some topics more in depth. F.ex.: extracotrs (unapply, for pattern-matching), the broad applicability of pattern matching, pattern matching anonymous functions & partial functions #4, usiong Option idiomaticly #5, nice FP error handling with the Try type #6, Futures, etc. Higly recommended! Thx to Jakob Lind
- Jolokia is remote JMX with JSON over HTTP: a REST API bridged to JMX, with support for security, fine-grained access control, bulk operations. Especially useful if you either 1) need to perform bulk operations (e.g. get multiple values) or 2) want to access them from something that doesn't support JMX. JSON is in general very easy to use and navigate. You can install Jolokia as a WAR (or mebedd its Servlet), a JVM agent, or attach it on-the-fly to a running JVM.
- The Appeal and Controversy of ZeroMQ - why to use 0MQ? It is a messaging library that focuses on performance, decentralization and simplicity, solving some really hard problems (sending async. messages w/o locks, distribuing to specific subscribers) and providing a simple API. Main pros: decentralized (no central broker), many languages; cons: no security (but you can use it over SSH).
- Tim O'Reilly: Create More Value Than You Capture (30 min + questions) - build apps that matter, that change how we do things. Thinking just about money is bad. Try to make the society better, smart, create more value than you capture, solve important problems, help people. Ex. startups: Uber, Square, Code for America.
- TED: Bruce Feiler: Agile programming -- for your family (20 min) - an inspirational talk, based on positive experience from multiple families, about applying the agile thinking and values to make our families happier by empowering the children (enlist them in their upbringing, deciding on goals, rewards, punishments), letting them know who they are, being adaptive, having regular "retrospectives" (that eventually become cherrished memories). Backed by research. Did you know that the #1 wish of children isn't that parents spend more time with them but that they are less stressed?
- What's new in Clojure 1.5.x - reducers, new threading macros (cond->, as->, some->, ..), various improvements, improved performance, erro messages, doc strings, bug fixes
- Stuart Sierra: On the Perils of Dynamic Scope - summary: don't create macros like with-connection binding to a thread-local var; make all methods take the resource as a parameter - thus the user has the freedom to decide when to close the resource and isn't limited to a single thread and can use lazy sequences
- Logic programming is overrated - core.logic is essentially only a complex DSL for doing an exhaustive search and there is already a nice, clean tool for that: the for comprehension. A logic puzzle can be much more clearly and also efficiently using for. But it is not completely useless - logic programming is good e.g. for running programs backwards, unification is important for writing type checkers, and the new constraint programming piece has good potential. Read also Logic Programming is Underrated, which provides a faster core.logic solution than for-comprehension and provides some pointers rgarding the practical usefulness of core.logic.
- Prismatic - Graph: Abstractions for Structured Computation - How to reduce the complexity overhead in large, real-world, FP systems by decoupling what is done from how it is executed. Graph is a Clojure library enabling a declarative way to describe how data flows between (mostly pure) functions => "It allows us to formalize the informal structure of good FP code, and enables higher-order abstractions over these structures that can help stamp out many persistent forms of complexity overhead." By decoupling the description of how data flows and the actual execution, we can execute it in different ways (parallelized, with memoization, lazy/eager) and apply various interceptors (for logging etc.). See especially the part "Graph and complexity overhead."
- Mike Anderson: Game development in Clojure : Alchemy 7DRL post-mortem (and the previous 7 daily updates, Alchemy @ GitHub) - an interesting report about game making in Clojure during 7 days, in as functional and immutable style as possible while keeping it sufficiently fast. How do you represent & handle statuf game objects, the world map, game state? The design of the game, what was easy and what hard with Clojure. Tl;dr: search it for "Some parting thoughts" (Clojure productive, immutability hard but pays off, prototype objects great, more typing would have helped). "Making everything immutable in Clojure is harder than it would have been in an OOP language like Java where everything can be encapsulated in mutable classes. In particular, the state update functions are tricky to make both correct and performant. The payoff is big however: in terms of the simplicity and effectiveness later on, and in the conceptual clarity being able to treat the entire game state as an immutable value". Having REPL is a big win.
- Refactoring Java using Clojure with the Eclipse Java development tools (JDT) (operation on AST nodes, i.e. little too low level; the Eclipse Refactoring API might be better)
- Clojure at a Bank – [Our] Clojure Code Immaturity - experiences with going from Java to Clojure: 1) too few comments, too short names => hard to learn the code; 2) not knowing clojure.core well enough => reimplementing (if-let, juxt, ...); 3) structure, comment, split up your namespaces well, navigating more complicated then in Java IDEs; 4) reasonably used Macros, Protocols, Defrecords payed off;
- Datomic for Five Year Olds - explaining the key characteristics of Datomic compared to relational and NoSQL DBs (schema, architecture, programmability/language); doesn't go into details of how it works (e.g. how does Datomic determine what subset of the DB to cache locally and what if it is few GBs); Honey Badger's 2012 talk Exploring Datomic: a database deconstructed explores the architecture and technical details much more
- Vagrant 1.1.0 is out (what's new?), with support for VMWare Fusion and AWS VM backends in addition to VirtualBox - use the same config to create, provision, stop, destroy and connect to a virtual machine locally or in the cloud (with limited support for shared folders, I'd suppose). V. 1.1 is backwards compatible aside of plugins, upgrade to new config optional.
- Animated presentations: ArtRage (drawing program, also for iPad), Wacom Intuos 5 (drawing tablet), Screenflow (screen & audio capture) - used for the Agile in a Nutshell (Agile Product Ownership in a Nutshell) mentioned above
- ckjm — Chidamber and Kemerer Java Metrics (via Neal Ford) - a command-line tool (also Maven/Ant plugin) to compute some metrics, outputting text or XML for further processing; the metrics: WMC: Weighted methods per class (cyclomatic complexity of its methods), DIT: Depth of Inheritance Tree, NOC: Number of Children, CBO: Coupling between object classes, RFC: Response for a Class, LCOM: Lack of cohesion in methods, NPM: Number of Public Methods, Ca: afferent coupling.
- Bulletproof Demos: Record & Replay built into Chrome - ever got a failure while demonstrating a web app though it has worked moments ago? No more! You Chrome to record your requests and responses and let its cache handle them during the real demonstration. (Mac: stop Chrome, to record run open -a "Google Chrome" --args --record-mode, to replay run open -a "Google Chrome" --args --playback-mode. Linux: google-chrome --record-mode and --playback-mode. Win.: run chrome <arg>)
- UserTesting.com (via Ash Maurya, the author of Running Lean) - on-demand usability testing; they have a large base of test users, can select those matching your criteria and unleash them upon your site guided by a script your provide, watch videos of their actions while they verbalize their thinking process, recieve written answers from them, talk to them.
- MindMup.com - opensource, free mind-mapping in the cloud by Gojko Adzic & co., with main focus on productivity. Store private maps in Goolge Drive, support for mobile devices, keyboard shortcuts. No registration needed.
Once we estimated a project to require 9 man-months but were later told that we do not understand a thing and it may not take more then 4. At the end it took over 25 and still wasn't done.On collecting requirements up front:
- paraphrasing my collegue Kim Leskovski
At the very beginning, we know less about our project than we’ll ever know again. This is the worst possible moment to be making firm decisions about what we “require.”On the estimate of project delivery date at its initial phase:
- Ron Jeffries in Estimation is Evil: Overcoming the Estimation Obsession
It’s based on an unrealistic list of requirements, using weak estimates, made at the moment of maximum ignorance, by people who are always optimistic about their own abilities. - ibidOn planning and requirements (the Chrysler’s C3 payroll project, having a payroll expert and a team familiar with the domain):
This was one of the best-planned projects I’ve ever seen, and even so, at least one third of the requirements were added, removed, or substantially changed. - ibid
[..] a line of code is a liability, not an asset [..] - Jez Humble in Why Software Development Methodologies Suck
Agile is not something you do, it is something you are. - Huib Schoots in Creating my own flow with personal kanban, Agile Record Feb 2013