The Holy Java

Building the right thing, building it right, fast

Posts Tagged ‘xp’

The Invisible Benefits Of Pair-Programming: Avoiding Wasteful Coding Excursions

Posted by Jakub Holý on July 5, 2013

There has been recently an article about how bad, expensive, and wasteful pair-programming is, since you need double as many developers. It used lines of code (LoC) produced per hour as the main metric. As many have commented, LoC is not the best measure, actually just the opposite, as I want to demonstrate on my experience. (The article is questionable also for other reasons, such as providing no data to back its claims of a pari costing 2.5 times more without any quality benefits, which contradicts f.ex. the studies summarized in ch. 17 of Making Software that show one1 1.6* cost + better quality, other 1.15* cost + 15% less failed tests.)

My main point is that by working with another person that you have to justify your plans to, you can be saved from pursuing suboptimal or unnecessary solution, thus considerably reducing both time spent and lines of code produced (more talk, less [wasteful] code).

Read the rest of this entry »

Advertisements

Posted in General, SW development | Tagged: , , , , | Comments Off on The Invisible Benefits Of Pair-Programming: Avoiding Wasteful Coding Excursions

Most interesting links of December ’12

Posted by Jakub Holý on December 31, 2012

Recommended Readings

Software development

  • Kent Beck: When Worse Is Better: Incrementally Escaping Local Maxima – Kent reintroduces his Sprinting Centipede strategy (“reduce the cost of each change as much as possible so as to enable small changes to be chained together nearly continuously” => “From the outside it is clear that big changes are happening, even though from the inside it’s clear that no individual change is large or risky.”) and advices how to deal with situations where improvements have reached a local maxima by making the design temporarily intentionally worse (f.ex. by inlining all the ugly methods or writing to both the old and the new data store); strongly recommended
    • Related: Efficient Incremental Change – transmute risk into time by doing small, safe steps, then optimize your ability to make these steps quickly and thus being able to achieve large changes
  • Researchers: It is not profitable to outsource development – the Scandinavian research organisation SINTEF ICT has studied the effects of outsourcing and discovered that often it is more expensive than in-country development due to hidden costs caused by worse communication and cultural differences (f.ex. Indians tend not to ask questions and work based on their, often incomplete, understanding) and very high people turn-over; even after the true cost is discovered, companies irrationally stay there. However it is possible to succeed, in some cases.
  • Bjørn Borud: Tractor pulling and software engineering – very valuable and pragmatic advices on producing good software (i.e. avoiding accumulating so much crap that the software just stops progressing). Don’t think only about the happy path. Simplify. Write for other developers, i.e. avoid too “smart” solutions, test & document, dp actually think about design and its implication w.r.t performance etc. Awake the scientist in you: “Do things because you know they work, not because it happens to be the hip thing to do.”
    (Note: I see the good intention behind “design for the weakest programmer you can think of” but plase don’t take it too far! Software should be primarily simple, not necessarily easy.
  • Know your feedback loop – why and how to optimize it – to succeed, we need to learn faster; the only way to do that is to optimize our feedback loops, i.e. shorten the path our assumptions travel before they are (in)validated, whether about our code, business functionality, or the whole project idea. Conscise, valuable.
  • Code quality is the least important reason to pair program – the author argues, based on his experience, other benefits of pair programming are more important than code quality: “[..]  the most important reasons why we pair: it contributes to an amazing company culture, it’s the best way to bring new developers up to speed, and it provides a great way to share knowledge across the development team.”
  • You Can’t Refactor Your Way Out of Every Problem – refactoring can’t help you if the design is fundamentally wrong, you need to rewrite it; know when it can or cannot help and act accordingly (related to how much design is needed upfront since some design decision cannot be reverted/improved upon)

Languages

  • Josh Bloch: Java – the good, bad and ugly parts (video, 15 min); summary: right design decisions (VM, GC, threads, dynamic linking, OOP, static typing, exceptions, …), some bad details (signed byte, lossy long-> double, == doesn’t cal .equals, ability to call overriden methods from constructors, …); Mr. Bloch has also given a longer talk examining the evolution of Java from 1.0 to 1.7 in The Evolution of Java: Past, Present, and Future.
  • True Scala complexity – a thoughtful criticism of the complexity of Scala, based on code samples; “[it is true that] Scala is a language with a smaller number of orthogonal features than found in many other languages. […] However, the problem is that each feature has substantial depth, intersecting in numerous ways that are riddled with nuances, limitations, exceptions and rules to remember. It doesn’t take long to bump into these edges, of which there are many.”; however, its possible to avoid many of the problems mentioned by resorting to less smart, more clumsy and verbose Java-like code; also, the author still likes Scala.
  • Scala or Java? Exploring myths and facts (3/2012) – a balanced view of Scala’s strengths and weaknesses; “[..] the same features that makes Scala expressive can also lead to performance problems and complexity. This article details where this balance needs to be considered.” Topics: productivity, complexity, concurrency support, language extensibility, Java interoperability, quality of tooling, speed, backward compatibility. Plenty of useful links.

Big data & Cloud:

  • Dean Wampler’s slides from Beyond Map Reduce – 1) Hadoop Map Reduce is the EJB 2 of big data but there are better APIs such as Cascading with Scala/Clojure wrappers; there are also “alternative” solutions like Spark and Storm; 2) functional/relational programming with simple data structures (lists, sets, maps etc.) is much more suitable for big data than OOP (for we do mostly stateless data transformations)
  • Apache HBase vs Apache Cassandra – comparison sheet – if you want to decide between the two
  • Optimizing MongoDB on AWS – 20 min talk about the current state of the art. Simplicity: Mongo AMIs by 10gen, Cloudformation template etc. Stability & perf.: new storage options – EBS with provisioned IOPS volumes (high I/O) + EBS Optimized Instances (dedicated throughput to EBS), High IO instances (hi1.4xlarge – SSD)); comparison of throughput (number of operations, MBs) of these storages; tips for filesystem config. Scalability: scale horizontally and vertically, shrink as needed.
  • Getting Real About Distributed System Reliability by Jay Kreps, the author of the Voldemort DB: distributed software is NOT somehow innately reliable; a common mistake is to consider only probability of independent failures but failures typically are dependent (e.g. network problems affect the whole data center, not a single machine); the theoretical reliability “[..] is an upper bound on reliability but one that you could never, never approach in practice”; “For example Google has a fantastic paper that gives empirical numbers on system failures in Bigtable and GFS and reports empirical data on groups of failures that show rates several orders of magnitude higher than the independence assumption would predict. This is what one of the best system and operations teams in the world can get: your numbers may be far worse.” The new systems are far less mature (=> mor bugs, worse monitoring, less experience) and thus less reliable (it takes a decade for a FS to become mature, likely similar here). Distributed systems are of course more complex to configure and operate. “I have come around to the view that the real core difficulty of these systems is operations, not architecture or design.” Some nice examples of failures.

Other

  • Talks To Help You Become A Better Front-End Engineer In 2013 (tl;dr) – topics such as mobile web development, modern web devel. workflow, current/upcoming featrues of CSS3, ECMAScript 6, CSS preprocessors (LESS etc.), how to write maintainable JS, modular CSS, responsive design, JS debugging, offline webapps, CSS profiling and speed tracer, JS testing
  • On Being A Senior Engineer – valuable insights into what makes an engineer “senior” (i.e. mature; from the field of web operations but applies to IT in general): mature engineers seek out constructive criticism of their designs, understand the non-technical areas of how they are perceived (=> assertive, nice to work with etc.), understand that not all of their projects are filled with rockstar-on-stage work, anticipate the impact of their code (on resource usage, others’ ability to understand & extend it etc.), lift the skills and expertise of those around them, make their trade-offs explicit when making decisions, do not practice “Cover Your Ass Engineering,” are able to view the project from another person’s (stakeholder’s) perspective, are aware of cognitive biases (such as the Planning Fallacy), practice egoless programming, know the importance of (sometimes irrational) feelings people have.

Clojure Corner

  • Polymorphism in Clojure – Tim Ewald’s 1h live coding talk at Øredev conference introducing mechanisms for polymorphism (and Java interoperability) in Clojure and explaining well the different use cases for them. Included: why records, protocols & polymorphism with them (shapes, area => open, not explicit switch) (also good for Java interop.: interfaces), reify, multimethods.
  • Stuart Sierra: Thinking in Data (1h talk) – Sierra introduces data-oriented programming, i.e. programming with generic, immutable data structures (such as maps), pure functions, and isolated side-effects. Some other points: Records are an optimization, only for perforamnce (rarely) or polymorphism (ot often); the case for composable functions;  testing using simulations (generative testing) etc.; visualization of state & process

Tools & Libs

  • Netflix’ Hysterix: library to make distributed systems more resilitent by preventing a single slow/failing dependency from causing resource (thread etc.) exhaustion etc. by wrapping external calls in a separate thread with clear timeouts and support for fallbacks, with good monitoring etc. Read “Problem Definition” on the page to understand the problem it tries to solve.

Favorite Quotes

if you build something that is fundamentally broken it isn’t really interesting that you followed the plan or you followed some methodology — the thing you built is fundamentally broken.

Bjørn Borud, Chief Architect at Comoyo.no, in an email 12/2012

The root of the Toyota Way is to be dissatisfied with the status quo; you have to ask constantly, “Why are we doing this?”

– Katsuaki Watanabe, Tyota President 2005 – 2009 (from the talk Deliberate Practice)

Posted in General, Languages, Tools, Top links of month | Tagged: , , , , , , , , , , , , | Comments Off on Most interesting links of December ’12

Most interesting links of September ’12

Posted by Jakub Holý on September 30, 2012

Recommended Readings

  • Johannes Brodwall: This dependency injection madness must end! – it’s very valuable to hear well-founded arguments against any popular belief and Dependency Injection is one of these. “I have started disliking the consequence of this strategy very much: All coupling in my system becomes implicit and harder to understand. I have instead reverted to using design patterns like the Singleton pattern, but with a slight twist.”
  • Computer Programmers Learn Tough Lesson in Sharing – WSJ.com – A balanced presentation of pair-programming including both benefits and issues. A key point: It is a skill that must be learned (to respect the other one, give her space, be aware of how your behavior is perceived by her, …).
  • Kent Beck: Functional TDD: A Clash of Cultures – TDD has been developed for object-oriented languages and applying it to a functional language with strong type brings interesting challenges. Also a good summary of the benefits of TDD: double checking of the logic (by the implementation and the, preferably quite different, test), solution decomposition (focus on part of the problem, once solve be sure it stays solved),  automatic checking of correctness, outside in design (API first, implementation after that). Plus the pleasant experience of the continuous cycle of tension (failing test) – relief (green).
  • Paul Callaghan: Thinking Functionally with Haskell: Types? Tests? We Need a New Word – Powerful type systems eliminate possibility of defects thus venturing into the domain of testing – what can they offer and where the new border and symbiosis between types and tests will be?
  • Tales from the Ops Side: Black Friday – an interesting and exciting view into the life of operations engineers one day when all went wrong. Key learnings: Many interdependant components are difficult to reason about; good monitoring and communication are crucial. The post refers to an interesting concept of Recovery-Oriented Computing, i.e. failures are inevitable and their prediction is nearly impossible thus we must focus on making the systems able to survive failures (e.g. vi damage containment, automatic fault detection, component-level restartability).
  • Groovy: The road map for the popular JVM language – why was Groovy created (as Java companion focused on productivity), key changes in Groovy 2.0 (more suport for static typing, Java 7, modularity with speed as a side-effect) and in the future Groovy 3.0 (invokedynamic everywhere, more Groovy written in itself).
  • Martin Fowler: Key Points from NoSQL Distilled – an overview of why NoSQL, data models, distribution models, consistency, map-reduce, polyglot persistence, criteries for choosing a database.
  • You’re a Top Developer! – a surprising hypothesis that “90% of all developers never read a programming blog, never have any side projects to learn something new, and never spend any time or effort outside work hours to improve”. However I haven’t seen any data to back that up (the author only quotes  Peopleware) and the author doesn’t propose any explanation for the fact. I’d really like to know if it is true and why it is so.

Business & Agile

  • Experimentation Is The New Planning – “You have no idea what’s going to happen to your industry. That’s why you build your organization into an engine of possibility.” We need “to  continually develop options and explore possibilities” to survive in the ever-changing conditions. Successful strategies emerge from the many ongoing experiments. However, “For emergent strategy to be successful, there must be enough autonomy, freedom, and slack in the system for people and resources to connect in a peer-to-peer way”.
  • The Buy-vs-Build Shift (part 1) – Buy to reduce risk of failure (however true agile development – with frequent deliveries and feedback-driven direction – may be cheaper and more importantly can tailor the product to the actual needs) and to avoid inefficiecy of development (but it doesn’t need to be so with agile). “[..] in projects with long cycle times (years) there is a tendency for the business to be somewhat speculative and request all functionality that they can think of [..] With prioritised iterative delivery the business can halt a project when all features that are actually needed have been completed. [..] it does reduce the amount of features that are implemented, and based on my experience, quite substantially so.” Today’s development with e.g. TDD, powerful IDEs supporting automated refactoring, powerful development/production machine, the all-knowing Internet may be much more efficient.
  • European entrepreneurs – Les misérables – A good analysis of why it is much more difficult to be an entrepreneur in Europe than in USA (the strong negative impact of a business failure, lack of local investors, cost of firing people) and the decline of European entrepreneurship since 19th century/WW1.
  • U.S. Government Accountability Office: Effective Practices and Federal Challenges in Applying Agile Methods – US government considers agile effective; description of the useful practices and of challenges

Tools

Clojure Corner

  • 10-minute Emacs for Clojure – getting started with Emacs for Clojure – install & config & basic usage for Emacs newbies (though no REPL integration yet)
  • Keep IT Simply Simple: First month @Runa Inc. – Clojure shop in Silicon Valley – brief post about using Clojure in the wild. Some points: TDD works splendidly; frameworks are not necessary; Clojure can be really fast (<= type hinting, memoziation, performant data structures + occasional Java code)
  • Blackstag: Why Clojure? The author describes the set of reasons that have led him to Clojure – and those that actually made him stick with it. “[..] what I like the most about Clojure is that it brings together the best of what many languages have to offer while not forcing it all upon me and, in doing so, has provided a good balance between power and flexibility.” “With Clojure I accomplish more and have found a greater sense of happiness with the work I am doing.”

Posted in General, Testing, Top links of month | Tagged: , , , , , , , , | Comments Off on Most interesting links of September ’12