Building the right thing, building it right, fast

Who I am

My name is Jakub Holy and I’m a software craftsmanship enthusiast and a (mainly JVM-based) developer since ~ 2005, consultant, and occasionally a project manager, working currently with Iterate AS in Norway. More under About and #opinion.

Posts Tagged ‘review’

Pack Publishing has asked me to review their new book, Clojure for Machine Learning (4/2014) by Akhil Wali. Interested both in Clojure and M.L., I have taken the challenge and want to share my impressions from the first chapters. Regarding my qualification, I am a medium-experienced Clojure developer and have briefly encountered some M.L. (regression etc. for quantitive sociological research and neural networks) at the university a decade ago, together with the related, now mostly forgotten, math such as matrices and derivation.

In short, the book provides a good bird-eye view of the intersection of Clojure and Machine Learning, useful for people coming from both sides. It introduces a number of important methods and shows how to implement/use them in Clojure but does not – and cannot – provide deep understanding. If you are new to M.L. and really like to understand things like me, you want to get a proper textbook(s) to learn more about the methods and the math behind them and read it in parallel. If you know M.L. but are relatively new to Clojure, you want to skip all the M.L. parts you know and study the code examples and the tools used in them. To read it, you need only elementary knowledge of Clojure and need to be comfortable with math (if you haven’t worked with matrices, statistics, or derivation and equations scare you, you will have a hard time with some of the methods). You will learn how to implement some M.L. methods using Clojure – but without deep understanding and without knowledge of their limitations and issues and without a good overview of alternatives and the ability to pick the best one for a particular case.

Highlights from Dan North‘s excellent, inspiring, and insightful talk Patterns of Effective Delivery at RootConf 2011. North has a unique take on what agile development is, going beyond the established (and rather limitied and rigid) views. I really recommend this talk to learn more about effective teams, about North’s “shocking,” beyond-agile experience, and for great ideas on improving your team.

The talk challenges the absolutism of some widely accepted principles of “right” software development such as TDD, naming, the evilness of copy&paste. However the challenge is in a positive way: it makes us think in which contexts these principles really help (in many) and when it might be more effective to (temporarily) postpone them. The result is a much more balanced view and better undestanding of their value. A lot of it is inspired by the theory (and practice) of Real Options.

What are Patterns of Effective Delivery?

Patterns – strategies that work in a particular context – and not in another (too often we forget the context and to consider the context where a strategy doesn’t work / is contra-productive); beware: a part of the context is the experience of the developer; for unexperienced devs it might be better to just stick to a process and applying TDD etc. all the time than trying to guess when they are appropriate and when not without having the experience to decide it right

I highly recommend this very thin and down-to-the-earth-practical book to everybody interested in back-end Java (a basic knowledge of servlets, Java ORM, and REST might be useful). The book evolves around a small but realistic project (X-Ray), which we follow from the inception through couple of iterations til the end. Bien shows us how lean Java EE can be, how to profit from the functionality that it offers, and how these pieces of functionality fit together to deliver something useful. He actually introduces a complete Java EE development environment including continuous integration (CI), code quality analysis, functional and stress testing.

Some of the things that I appreciate most in the book is that we can follow author’s decision process with respect to implementation options (such as SOAP vs. REST vs. Hessian etc., a REST library vs. sockets, or when (not) to use asynchronous processing) and that we can see the evolution of the design from an initial version that failed through cycles of growing and refactoring and eventually introducing new technologies and patterns (events, configuration over convention) to support new and increased requirements. Read the rest of this entry »

Summary: Should you read the book? Yes, the chapter on principles and values is trully enlightening. The book in general contains pearls of wisdom hidden in the mud of “I know that already, man.” I would thus recommend skimming through the book and reading only the pieces matching your level and needs.

The book seems to be targeted a lot at Java beginners (especially the chapter on collections), going into otherwise unnecessary details, yet there are many valuable advises of which some can only be appreciated by somebody with multiple years of professional programming experience. It thus seems to me that the book isn’t a perfect match for anybody but everybody will find there many useful ideas. It would best be split in two.

An experienced developer will already know many of the patterns though it’s perhaps useful to see them named and described explicitly and listed next to each – it helps to be aware and clearer of what you do and why you do it.

I’d absolutely recommend everybody to read the chapter A Theory of Programming, explaining Kent’s style of programming and the underlying key values of communication, simplicity and flexibility as well as the more concrete principles (local consequence, minimize repetition, logic and data together, symmetry, declarative expression, co-locating data and logic having the same rate of change). Also in the rest of the book there are valuable ideas that it would be a pity to miss. I list below some of those that I found particularly interesting.

The book is basically a set of case studies about Scrum that show how to implement the individual aspects of Scrum, what are the common pitfalls and how to avoid them, and help to understand its mantra of “the art of the possible” and how to adapt Scrum to various situations. It’s very easy to read thanks to the case studies being brief and organized by topics (team, product owner, …). I’d absolutely recommend it as a third book in this domain, after a general introduction into the lean thinking (Implementing Lean Software Development – From Concept to Cash by M. & T. Poppendieck is great for that) and an introduction into Scrum itself. Scrum is not just a set of practices, it requires an essential shift in thinking. Thus it is not enough to learn about the practices – you have to learn, understand, and accept the principles behind. This book will hopefully help you to refine your understanding of these principles.

Extract

This extract contains the quotes and observations that I find the most interesting. It tries by no means to be objective or representative, a different person with a different experience and background would certainly pick different ones. Thus its value for others than myself is rather limited but it may perhaps serve as an inspiration to read the book. My all favourite quotes are in italics. Read the rest of this entry »

I consider the Clean Code book to be obligatory for every programmer. And if you currently haven’t the time to read it all at once then you should read – and take deep into your heart – at least the 12th chapter Emergence by Jeff Langr, which introduces Kent Beck’s Four Simple Design Rules and explains thoroughly what they mean and why they’re so important. The rules, in the order of importance, are:

Runs all the tests

Contains no duplications

Expresses the intent of the programmers

Minimizes the number of classes and methods (this isn’t as controversial as it may sound, see below)

Stated like this in simple sentences it’s difficult to see the depth hidden behind them and thus their essential importance for clean, high-quality code with high-quality design and I’ll therefore try to explain what they really mean in the full extent based on Clean Codes. I’ll cite some parts of the book – for I can’t find better words than the author – hoping for the author(s) and publisher graciously permitting it. Read the rest of this entry »

I had high expectations for Martin Fowler’s Refactoring (1999/2002) but it turned out that both me and the book are too old. It had some interesting parts, but the main one – the refactoring catalog itself – had little new for me because I already know most of the refactorings and the description of steps how to perform them safely is nowadays essentially useless as they’re already automatically and safely performed by our IDEs.

I’ve enjoyed chapter 1 with a nice example of how bad code is turned into a nice one via a series of refactorings and I’d recommend it to any beginning developer. For others than me also chapter 2 may be useful, it explains why and when to refactor, how it impacts your development speed and how to justify it to the manager. I’d skip chapter 3 – bad smells in the code – and read instead of it the Uncle Bob’s lovely Clean Code , which is a great justification and basis for refactoring anyway.

In the catalog I’ve appreciated the description of some refactorings for various reasons, such as 6.4 Replace Temp with Query, 8.14 Replace Type Code with Subclasses, 9.7 Introduce Null Object, 9.8 Introduce Assertion. Of course also the other ones are good but they are just too familiar to me and my IDE to draw my attention anymore.

Finally there are some good advices in Putting It All Together by Kent Beck, such as that it’s good to know when to stop and to be able to resist the temptation to refactor too much at once.

I’ve also appreciated the “war stories”, especially regarding performance tuning, where once again it’s demonstrated that a guess (however founded) is incomparable to hard evidence.

Conclusion

If you do refactorings daily, perhaps skip the book. If not, read chapter 1, perhaps browse through 2 and 12, check whether anything catches your eye in the refactoring catalog table of content, read Kent’s closing chapter and return the book to the local museum.

I’d like to make you aware of the excellent book Real World Java EE Patterns – Rethinking Best Practices by Adam Bien (blog), a Java Champion and renowned consultant, software architect and Java EE standardization comitee member. I’d absolutely recommend it to any architect or developer serious with Java EE 5 or 6 development, even to those not planning to use EJB 3.x (at least prior to reading the book :)). It’s a must-read complement to the now a little outdated Core J2EE patterns as it updates the patterns for the new bright world of EJB 3/3.1 while discarding some of them and introducing some new, extremely useful patterns and techniques.

The book starts with an overview of the evolution of Java Enterprise Edition and the hard issues it solves for us, continues with the new and updated patterns and strategies and concludes with an introduction of two opposite architectures you can build with Java EE 5/6, namely lean SOA and domain-driven (which itself makes it worth reading).

What I really appreciate in addition to that valuable content is that for each pattern there is a section on testing and documentation and a really good evaluation of consequences in terms of maintainability, performance and other such qualities. You will find there also many code samples and beautiful applications of the Builder and Fluent API patterns.

The main message is that EJB 3.x is so lean and powerful that we must justify why NOT using it – and when using it, you should be very pragmatic and only introduce patterns, layers and principles if they bring real value.