The Holy Java

Building the right thing, building it right, fast

Posts Tagged ‘opinion’

Frustration-Driven Development – Towards DevOps, Lean, Clojure

Posted by Jakub Holý on March 17, 2014

A post about development practices, speed, and frustration.

My wife has mentioned that she likes my passion for doing things right in software development. That made me thinking, why do I actually care so much and do not just enjoy the coding itself? It boils down to that I am not happy until my code is in production. Seeking the satisfaction of having my code used by and helping people while trying to eliminate all unnecessary mental drain is behind all the practices that I embrace and evangelize. It’s a drug I like to take often, in small doses.

practices = f(max(delivered value), min(mental energy))

So how does this relate to DevOps, Continuous Delivery, testing, single-piece-flow, Lean Startup, Clojure? It is simple.

Read the rest of this entry »

Posted in SW development | Tagged: | 1 Comment »

Seek Understanding

Posted by Jakub Holý on February 23, 2014

The most important lesson I have learned in 2013 is that I won’t change anything by writing critical blog posts and talking to like-minded people. Fostering the “we vs. them,” we who are right vs. them idiots sentiment is ineffective, even destructive. To be able to achieve anything, I have to talk to the people with opposite opinions and understand them. They are rarely ***holes and typically have good reasons for their opinions. Only by understanding those reasons and the background, history, and emotions they stem from – and hopefully helping the “opponents” understand some of my reasons and context – we can find a common ground and common goals that we can build upon to go further – perhaps not in harmony but still together rather than against each other.

Talking to people is difficult. Having my dearly hold beliefs exposed to discussion and criticism is painful. Trying to find a common ground with people with totally different needs, experiences, and ideas about the best way to do software development in a particular context is challenging. But only by doing so, and by being open to changing my own stance, I can hope to influence the stance of other “stakeholders” and thus bring a positive change to a project or organization.

Side note: It’s funny that the more I learn about IT the more I realize that the main challenges and solutions we encounter are not about technology, but about the fundamentally human in us. Also the approach advocated here – seeking understanding and respect in spite of disagreement instead of the radically adversarial “we vs. them” thinking – is crucial not just for IT, but also for building a better society. So far it unfortunately seems that politicians – especially in the US but not just there – tend to prefer the wrong approach. And also the willingness to expose one’s beliefs to discussion and the openness to change are important not only for talking to people, but for being able to keep developing mentally and spiritually, as put so well by M. Scott Peck in The Road Less Traveled.

I’d like to thank to Markus Krüger for showing me the power of talking to people and to Marshall B. Rosenberg’s Nonviolent Communication: A Language of Life for being so inspirational on this path.

Posted in General | Tagged: , | Comments Off

The Risks Of Big-Bang Deployments And Techniques For Step-wise Deployment

Posted by Jakub Holý on February 17, 2014

If you ever need to persuade management why it might be better to deploy a larger change in multiple stages and push it to customers gradually, read on.

A deployment of many changes is risky. We want therefore to deploy them in a way which minimizes the risk of harm to our customers and our companies. The deployment can be done either in an all-at-once (also known as big-bang) way or a gradual way. We will argue here for the more gradual (“stepwise”) approach.

Big-bang or stepwise deployment?

A big-bang deployment seems to be the natural thing to do: the full solution is developed and tested and then replaces the current system at once. However, it has two crucial flaws.

Read the rest of this entry »

Posted in SW development | Tagged: , | Comments Off

Bad Code: Are We Thinking Too Little?

Posted by Jakub Holý on December 31, 2013

Do we not think enough when coding? Do we jump to the first solution without really considering the problem, without trying to analyze and decompose it and understand the components and orthogonal forces invovled? Is that the cause of bad code (together with time press) and the reason why we typically see a “patchvolution” rather than evolution (of design)?

For example I want a certain item on my list shown grayed out because it has been marked for removal or is currently being edited and I therefore add a flag called isDisabled. But if I really thought about it, I would likely call it based on the purpose rather than display, e.g. isBeing Edited. And I have often observed that I/we tend to jump to the first acceptable solution without trying to consider other, (radically) different and perhaps better alternatives. That is easily explained with our inborn intelectual laziness and we certainly can agree that we should not overthink things and that we need to ship but still, shouldn’t we try to think a little more?

The Clojure community has been very inspiring for me in this regard. There is a strong focus on spending more time on the problem than the solution to really understand it, and on separating the different concerns involved and adressing them separately, as well as on achieving simplicity. One of the manifestation is the strong preference of small, focused, composable libraries over frameworks. F.ex. it took couple of years for Clojure to get support for named arguments – but the result – destructuring – is something much more powerful, that now pervades the whole languages (of course, this is a language, not an app). When you listen to Rich Hickey talking f.ex. about core.async (vs. actors, Reactive Extensions etc.) you see that the man thought deeply about the problem, alternatives, and their pros and cons.

May be we should spend little more time with our problems before jumping to solutions, no matter how much we like to solve things. Perhaps we would end up with a much better code than we typically have, and thus considerably lower maintenance costs.

Ref: Simple Made Easy, The Clojure Philosophy from Joy of Clojure.

Posted in General | Tagged: , , | Comments Off

Code Is Cheap, It’s Knowledge Discovery That Costs

Posted by Jakub Holý on December 6, 2013

If we knew exactly what code needs to be written, what needs to be done and how it can be done, we would need very little time to write it. It is the discovery of the knowledge what to build and how to build it that takes all the time. Yet non-developers usually see it as an unacceptable waste to write and then throw away – and perhaps rewrite – code.

Read the rest of this entry »

Posted in SW development | Tagged: , | Comments Off

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 »

Posted in General, SW development | Tagged: , , , , | Comments Off

Ignore requirements to gain flexibility, value, insights! The power of why

Posted by Jakub Holý on June 1, 2013

I would like to share an eye-opening experience I have recently made. I have learned that if we do not just passively accept the requirements given to us but carefuly analyse the reasons behind them (and the reasons behind the reasons), we gain incredible power and flexibility. By understanding the real value behind it and by discovering other, related sources of value, we might find a superior solution and, more importantly, we gain a few degrees of freedom in the solution space, the ability to scope up or down the solution and optimize it with respect to other solutions. Let’s see how a seemingly fixed requirement can be easily expanded or shrinked once we bother to trully understand it.

Read the rest of this entry »

Posted in General, SW development | Tagged: , , , , | 2 Comments »

The Value and Perils of Performance Benchmarks in the Wake of TechEmpower’s Web Framework Benchmark

Posted by Jakub Holý on April 1, 2013

The TechEmpower’s Web Framework Benchmark is quite interesting but the comments following it at HackerNews are even more so. That is at least the constructively critical ones that highlight many of the issues with benchmarks while also reminding us of their value. One could formulate the benchmark paradox:

Benchmarks are important for rational technological choices yet it is very hard if not impossible to perform them in a sensible way.

I would like to record here some of the important points, mainly as a future reference for myself for whenever I will be dealing with benchmarking.

Read the rest of this entry »

Posted in General, Testing | Tagged: , , | Comments Off

The Sprinting Centipede Strategy: How to Improve Software Without Breaking It

Posted by Jakub Holý on January 14, 2013

Re-published from

Our code has been broken for weeks. Compiler errors, failing tests, incorrect behavior plagued our team. Why? Because we have been struck by a Blind Frog Leap. By doing multiple concurrent changes to a key component in the hope of improving it, we have leaped far away from its ugly but stable and working state into the marshes of brokenness. Our best intentions have brought havoc upon us, something expected to be a few man-days work has paralized us for over a month until the changes were finally reverted (for the time being).

Lessons learned: Avoid Frog Leaps. Follow instead Kent Beck’s strategy of Sprinting Centipede – proceed in small, safe steps, that don’t break the code. Deploy it to production often, preferably daily, to force yourself to really small and really safe changes. Do not change multiple unrelated things at the same time. Don’t assume that you know how the code works. Don’t assume that your intended change is a simple one. Test thoroughly (and don’t trust your test suite overly). Let the computer give you feedback and hard facts about your changes – by running tests, by executing the code, by running the code in production.

Read the rest of this entry »

Posted in General, SW development | Tagged: , , , | Comments Off

Fast Code To Production Cycle Matters: For Pleasure, Productivity, Profit

Posted by Jakub Holý on January 5, 2013

I spent one afternoon adding a much needed feature to our application. Now I have been waiting for several days for various people to review and approve it. And I have just realized how tiring it is and how much energy it takes from me.

To create something and get it out into production at once (plus minus) is fun and really motivates me to do and try stuff, it is a great feeling to see it immediately affecting the users and processes. And a quick feedback (from the users and the behavior of the application) – while still being engaged for the thing and having all the context in my mind – makes it easy and fun to fix and improve it, leading to a better result faster. Waiting, on the other hand, is exhausting and depressing. I usually start working on something else, forget the context, lose the interest (it is not easy to be fired up for two things at the same time) etc.

Therefore, if you care for happy developers and better products, make sure that your time from code to production is as short as possible. Look at your process, eliminate all delays, make it smooth.

PS: I am not saying that code reviews are bad. They are great. They just shouldn’t be a source of delay. For example if you can pair-program then you get an instant code review.

Posted in General | Tagged: , , | Comments Off