Friday, December 13, 2013

Dichotomies in software development: Anti-Anti-If Campaign?

In the team I am currently working, a toy contest is going on among developers to reduce if-statements in the code-base to a minimum.

This goes along with the Anti-IF Campaign: LESS Ifs, MORE POWER:

600794 581837505169922 1396033429 n

On the other side I recently stumbled across the following code examples from current "bleeding-edge" technologies:

Meteor: Hey cool, we can use the same code on the server and the client! We just have to check where we are and then do different things!

(From the official Meteor.js examples)

Appcelerator Titanium: Hey cool, we can use the same code-base for Android and iOS! We just have to check where we are and then do different things!

(From the appcelerator wiki: Supporting Multiple Platforms in a Single Codebase).

That just looks convincing. Next step on this path to enlightenment would probably be to put all the code in the same source file?

Wednesday, December 11, 2013

Presentation: Professional JavaScript Development (An introduction for Java Developers)

250x250xJavaScript logo png pagespeed ic I5rUk2FRl9

This week I was invented again to speak at the SBB Developer Day 2013.

As in the last three years, I enjoyed the event very much, and I hope to be invited again next time.


Thursday, November 21, 2013

Software: To eat and get eaten…


It has been declared:

Software is eating the world!


But lately it seems like:

Management is eating software development!

(Or at least it's sucking out all the innovation and creativity which used to be a major part in software development)


Some public indications of this trend are:

Is this a bad thing or is it just a sign that the software industry is growing up? Does this boil down to the old question whether software development is craftsmanship or manufacturing?

Tuesday, November 12, 2013

Quotes of the Week: Meetings

Meetings are toxic: They usually convey an abysmally small amount of information per minute.
What exactly is wrong with meetings and managers (or M&Ms, as we call them)? Well there is nothing intrinsically wrong with them. What's wrong is how often they're applied in office situations.
If you are in a room with five people for an hour, it's a five-hour meeting.
Meetings procreate: One meeting leads to another meeting leads to another...
By rationing in-person meetings, their stature is elevated to that of a rare treat.
We lead people not machines, we embrace spending more time with our team than in meetings.


Last but not least: Never forget to run the awesome Meeting-Ticker

Tuesday, October 22, 2013

Bookreview: Instant Vert.x

2913OS Last Year at the SBB Developer Day I was presenting a talk about Vert.x: asynchronous event-driven web-applications on the JVM.

Vert.x is a very interesting project that brings some fresh concepts to the JVM platform. At first glance Vert.x looks like a Node.js clone for the JVM. But there are differences: Vert.x can not (yet) offer the gigantic ecosystem of modules of Node.js, but it is certainly attractive for bringing a "Node.js-like" programming model to the proven and scalable JVM platform. With its distributed event bus and the concept of "worker verticles" Vert.x offers concepts that go beyond Node.js.

Packt Publishing sent me the Book "Instant Vert.x" for review.

Instant Vert.x is a short book (54 pages). As the name suggests, you can read it in "an instant" and it gets you bootstrapped into the world of Vert.x.

I liked the style of the book: it is short and concise and after reading it, you have a good overview over Vert.x as an application platform and the programming model that comes along with Vert.x.

However I have to note that the Vert.x project has a very nice online documentation. In my opinion the book goes not beyond the information that is also available online.

The advantage of the book is, that it structures the information in an easily digestible way that you can read in chunks offline. However I would have hoped for more "in-depth" information or some "best practices" how to use Vert.x in real projects.

If you have never heard of Vert.x, I can fully recommend "Instant Vert.x". If you have already played with Vert.x the book is probably not for you.

Thursday, October 10, 2013

Myco 1.1.0 for iPhone


This week I released Myco 1.1.0 for the iPhone.

So far the App was more successful than we expected: In the last three months we had about 30'000 downloads of which about 5% were paid versions.

In the latest version we updated the library content. We have now 229 mushrooms in the library and we added two new classification attributes: 'edibility' and 'spore print'.


Edibility and Spore print


As a new feature we added a quiz that allows you to learn to identify mushrooms in a playful way:

IOS Simulator Screen shot Jul 13 2013 1 29 02 AMIOS Simulator Screen shot Jul 13 2013 1 29 15 AM

This will be the last version for iOS6 the next version will support iOS7 only.

The Windows Phone edition of Myco supports the same features. Please tell us which additional features you would like to see in the future.

Tuesday, September 17, 2013

Paradise Lost: SAFe banned from the Agile Heaven?


The Scaled Agile Framework (SAFe) recently seems to have fallen from grace in the agile community.

Most of us noticed that something went wrong with Agile. The Scaled Agile Framework now gets stigmatized into the role of the traitor of the True Agile Mindset, it serves as the negative showcase how the original Agile ideas are corrupted by The Enterprise.

I almost get the impression that nowadays every Agile guru has to pick on SAFe, to prove that he stays truly Agile:


The boys from RUP (Rational Unified Process) are back […] They would be at a waterfall conference, but they are no longer.

A core premise of agile is that the people doing the work are the people who can best figure out how to do it. The job of management is to do anything to help them do so, not suffocate them with SAFe.


This seems awfully similar to Rational Unified Process (RUP) from the 1990s but updated to include Agile practices from the 2000s

 [The SAFe] approach is the antithesis of the Kanban Method!


I did not encounter a single person who had successfully implemented SAFE.

Someone just shot the Agile brand in the back of the head.


This means that we are back to the good old days where there was a chasm between product management and development rather than working hand-in-hand as it is intended in Scrum.

Teams are not allowed to self-organize their alignment and predictability is the goal rather than maximization of value

SAFe accepts the status quo in many enterprises and distinguishes between Product Owner and Product Management. [] This does not help collaboration but is a tayloristic division-of-labor approach.

People don’t have to change with SAFe – they can just go on as they always did and call themselves Agile now.

SAFe believes that the world is good as it is [...] so the status quo has to be accommodated. Agile believes that the world is not a good place (at least for people working in software development) and should be improved. The status quo – especially the tayloristic thinking - has to be changed. This doesn’t fit together. SAFe isn’t Agile.


Update 2014-03-03:

SAFe wraps those ideas [of Lean and Agile] in a package that is designed — intentionally in my opinion — to appeal to today’s managers and executives who do not understand Agile, but who know they have a problem to which Agile may be the solution.
If everyone in the organization were to read the fine print in SAFe, then the organization might very slowly evolve to the level of effectiveness that real Agile provides. That’s not going to happen. Managers and executives are too busy to read the fine print. They are too busy doing their job to study how to do their job. They will too easily fall into old patterns of management behavior, and when they do, SAFe will be installed in a fashion that won’t just fail to support Agile, but that will suppress it.

 SAFe assumes that you need a big “solution” and then provides it. More than likely you don’t need a big solution. 

Saturday, September 14, 2013

/ch/open Workshop Tage: JavaScript Bootcamp for Java Developers

Last week Marc and I held a workshop at the /ch/open Workshoptage:

JavaScript for Real Developers: A Survival-Bootcamp



The goal of the full-day workshop was to give typical Java enterprise developers an overview over the current landscape and ecosystem of JavaScript development. Typical undifferentiated prejudices that exist towards JavaScript should be refuted (or confirmed with facts).

The topic we focused on were:

  • JavaScript as a language (concepts, patterns, parallels to other OO languages …)
  • jQuery as a de-facto standard library for client-side JavaScript development
  • The JavaScript toolchain (setting up a professional development and build toolchain)
  • Integration of a JavaScript project into a Java project (using Maven and/or Node.js)
  • Modern Web Architectures (JavaScript for the frontend, Java for the backend)
  • Client Side MVC

The exercises and demos can be found in our Github repository.

I had the idea for this workshop some time ago, when I was working in several enterprise web projects, and I realised that JavaScript is getting more and more important for any kind of (web) projects, but typical enterprise developers (like me) try to avoid the topic at any price. Usually all abstractions (like JSF or GWT) break at some point and JavaScript leaks through. But then it is mostly too late to start dealing with JavaScript professionally, because the project has already progressed into a phase where it's not possible to lay the necessary groundwork for serious JavaScript development. 

The workshop seemed to hit a nerve in the current Java enterprise community: It was fully booked within a few days after the program for the workshop days was published (because there are hands-on exercises in the workshop, we limited the maximal number of attendees to 20).

Thanks to the organisers of the workshop days, we could schedule the workshop a second time at the same workshop days. Also this second workshop was booked out within several days.

I enjoyed the two days of teaching very much and working with Marc was great fun. From both workshops we also got quite good feedback (the official feedback is published here), so we guess that it was also a good experience for the attendees.

I hope there will be the possibility to repeat the workshops in the future. We are open for any suggestions...

Wednesday, August 21, 2013

JBoss Remote EJB Invocation: An Unexpected Journey

Complexity sign6

The amount of complexity I'm willing to tolerate is proportional to the size of the problem being solved. There will come a point where the accumulated complexity of our existing systems is greater than the complexity of creating a new one.

- Ryan Dahl on Software

Es könnte alles so einfach sein, ist es aber nicht.

- Die Fantastischen Vier


Getting EJB Remoting to work in JBoss 7 was probably the most pitfall-ridden path I have travelled so far on my journeys through the swamp of frameworks…

Note: The example and discussion in this post is based on JBoss EAP 6.1.

It all started out well with a simple quick-start: ejb-remote.

But the pitfalls lured …

TL;DR: Finally I got an illustrative example running, which will be the base for the following discussion. The example can be found on my Github repo.

The EJB is simple: [Gist]

It's in the client where we find the pitfalls: [Gist]


Let's discuss the pitfalls:

Pitfall 1: Determining the JNDI-name for the EJB lookup

When you deploy the EJB into JBoss you get a nice output in the server-log:

[0m23:18:42,226 INFO  [] (MSC service thread 1-12) JNDI bindings for session bean named HelloWorldBean in deployment unit subdeployment "ejbremote-ejb.jar" of deployment "ejbremote-ear.ear" are as follows:

It looks easy … but actually none of those JNDI bindings work for remote lookup!


Pitfall 2: There are two approaches for accessing a remote EJB

You can use the "standard" JNDI lookup (which uses the "remote-naming project") or the the (proprietary) EJB Client API. Both approaches differ in the initialisation properties (key-value pairs) that have to be configured and in the JNDI lookup name that must be used for a given bean.

The EJB Client API is recommended. Loadbalancing, clustering and client interceptors are only available with the EJB Client API. Also it is performance optimised. [see here]

Pitfall 3: The initialisation properties are cryptic

I do not understand the following properties (except that they all have something to do with client, context and naming):

jndiProperties.put("jboss.naming.client.ejb.context", true);
ejbProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
ejbProperties.put("org.jboss.ejb.client.scoped.context", "true");

Yet you have to use the correct ones for the correct lookup approach, else it won't work…
There are also a lot of other properties floating around in different documentations, wikis, forums and JIRA issues … I did not find a authoritative documentation about them.

Pitfall 4: Use the correct runtime dependencies

Runtime dependencies are tricky. You can get you code compiling, but it will not work unless you have the correct runtime dependencies configure. Getting the EJB client API running, you need:


Getting the "standard" JNDI lookup running (including JNDI tree traversal) you need:


In both cases you need some more runtime dependencies which are listed in the client pom.xml of the example.


Pitfall 5: Error messages are mostly not helpful or even misleading

Example 1: If you configure the wrong version of the ejb-client dependency like:


Then you get an exception that makes you beleave you have made a mistake somewhere in the security-configuration:

javax.ejb.EJBAccessException: JBAS014502: Invocation on method: [] is not allowed

Example 2: If you pass a number instead of a string for the port configuration like this:

ejbProperties.put("remote.connection.1.port", 4447);

Then you get the same exception as when you use a wrong JNDI lookup name:

java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:ejbremote-ear, moduleName:ejbremote-ejb, distinctName:]


Pitfall 6: Client interceptor registration does not work with scoped context

Since JBoss 7.2 you can use scoped contexts and then you would not need do programmatic initialisation of the EJBClientContext.
So if you do this:

ejbProperties.put("org.jboss.ejb.client.scoped.context", "true");

… then you do not need to do the following:

final EJBClientConfiguration ejbClientConfiguration = new PropertiesBasedEJBClientConfiguration(ejbProperties);
final ConfigBasedEJBClientContextSelector selector = new ConfigBasedEJBClientContextSelector(ejbClientConfiguration);

However if you do the above, then the programmatic registration of a client interceptor does not work any more. I suspect this is a bug?

In a later post I plan to elaborate on how to get the above example running with a custom login module and with a cluster setup… be prepared for more complexity and more magic strings!

Thursday, July 18, 2013

Something went wrong with Scrum: Analogies with the Underpant Gnomes and Sovjet Era Deathmarches

Story card hell is when you have 300 story cards and you have to keep track of them all. [...]
Every customer I've ever worked with wanted to put story cards in a database. That misses the point of story cards. If you're worried about losing story cards, you're doing too much with them. 

- Jim Shore, Beyond Story Cards (2005)


When I was getting to know Scrum, I was taught that it was very much about reacting to change. Product owners define and prioritise the product backlog. They can react to change by re-prioritising the product backlog. Sprints are short focused iterations where the team is protected from change and the associated task switching costs. The effort is streamlined during this period. But because Sprints are short, reacting to change is still possible on the level of the project.

Scrum poses several challenges for the product owner:

  • He is challenged to break down backlog items so that they fit into sprints and are still valuable and independently deliverable.
  • He is responsible for the detail-level of the items in the product backlog. This is a balance-act since the items on the top must be detailed enough for the team to implement them. However items lower in the backlog should not be too detailed, since they can change completely or even become obsolete during the course of the project. Spending too much time upfront on those items is wasteful. I was taught  that items that are not on the top of the product-backlog should just be placeholders for a "just-in-time specification".

It seems that the current state how Scrum is practiced does not reflect those ideas any more. The following burn up-diagram from a real project I have been working on is a good illustration:

Screen Shot 2013 05 28 at 12 17 12 AM

The large gap between "Scope" and "Work Done" hints at a chain of problems:

  • The product-backlog is used to plan the whole project and to monitor its progress.
  • In order to plan and monitor the product-backlog should be as exact as possible. Therefore all items on the product backlog must be estimated as exactly as possible.
  • When items on the backlog are estimated, they are no longer "placeholders for future refinements". They become specifications.
  • An exactly estimated product-backlog suggest a certainty we simply don't have.
  • Following from the above, the backlog strives to become a complete specification for the whole project.
  • Reacting to change is no longer a main concern, when this complete specification is in place.
  • … where is now the difference to a Waterfall Project?
It seems that my experience is not unique:

Gnomes plan

Gojko Adzic is even a bit more provocative (as always). In his talk "Make Impacts, Not Software" he compares the "Complete-Backlog-Antipattern" in Scrum to the Sovjet Era deathmarches like the construction of the White Sea Canal which was a showcase of the success of the First Five-Year Plan:

Belbaltlag detail
According to a recent Forrester Study the above way to practice Scrum is the mainstream today. Forrester calls this "Water-Scrum-Fall":
The reality of agile adoption has diverged from the original ideas described in the Agile Manifesto, with many adoptions resembling what Forrester labels water-Scrum-fall.
According to that study Scrum is not adopted by the whole company. Scrum is seen as the "Development Process". The input for that process is a long term roadmap or a complete feature list defined by the business. Then the development team does all their esoteric ceremonies like "Standups", "Sprints" and "Demos" but when you wait long enough, the output will finally be the complete delivery that goes to production.
I personally don't think that we gain many benefits from "Water-Scrum-Fall". In some cases it can even be harmful, and the project would be better off with a honest waterfall process. Gojko makes the analogy of putting a strong engine into a crappy car.
However I think that this is an inherent conflict between Agile methodologies and plan driven approaches. If you really need a plan driven approach (i.e. because you have a defined long term roadmap) then probably all attempts at using Agile methodologies are just pretenses and will eventually fall back to a disguised waterfall approach.

Saturday, July 13, 2013

New Features in Myco for iPhone


This week I released Myco 1.0.4 for the iPhone. Since the first release of the App we added some new features:


First of all the Standard and Pro editions now feature 205 mushrooms in the library:



Mushrooms are now also attributed with region and season attributes:

IOS Simulator Screen shot Jul 13 2013 1 02 27 AM


In the identification screen attributes can be "locked". Locked attributes are persisted, they keep their value if you press "Clear" or when you quit the application: IOS Simulator Screen shot Jul 13 2013 1 01 09 AM


Finally locations can be attributed with areas and then be filtered by area:

IOS Simulator Screen shot Jul 13 2013 1 29 02 AMIOS Simulator Screen shot Jul 13 2013 1 29 15 AMIOS Simulator Screen shot Jul 13 2013 1 29 20 AM

The Windows Phone edition of Myco supports the same features. Please tell us which additional features you would like to see in the future.

Friday, June 14, 2013

TidBit: Putting an architect in a scrum team is like putting mayonaise in cake

Christin Gorman is my hero! After her Hibernate bashing she now follows up with baking analogies applied to the current state of Scrum:

Putting an architect in a scrum team is like putting mayonaise in cake

Putting an architect in a scrum team is like putting mayonaise in cake - Christin Gorman from Roots conference on Vimeo.

Friday, May 31, 2013

Opinions: JavaScript

Can you spot the differences:

I'm convinced there is a need to replace JavaScript.


JavaScript was that component of the Web that everybody underestimated.


JavaScript is fast becoming a serious contender to Ruby and JVM languages.


This is probably the worst thing any server-side framework can do: be written in JavaScript.


JavaScript is now established as a powerful, mainstream language that can be used in a variety environments both on client and server sides.


A very large group of developers still thinks of JavaScript as a joke.


JavaScript used to be the thing that we tolerated… Now it became the technology leader.


JavaScript in the browser is the single largest development platform.


JavaScript is a bubble. What is actually awesome about JavaScript has nothing to do with JavaScript.


Tuesday, May 28, 2013

Postagile: A large Scrum backlog is like a big pile of underpants

We were used to getting shit done … then they told us about Agile.


If your product backlog contains more than 50 Stories, there probably are inconsistencies due to lack of comprehensiveness.


In his talk "Co-making Great Products" Jeff Patton draws a hilarious analogy between an anti pattern in Scrum and the Underpants Gnomes in South Park:

The business plan of the Underpants Gnomes looks like this:

Gnomes plan

If you think about it, then the business plan of the gnomes is not all too different to an excessively collected and groomed backlog in a Scrum project:

Screen Shot 2013 05 28 at 12 17 12 AM

Let's remember what Agile is about:

  • Individuals and interactions over processes and tools
  • Responding to change over following a plan

Lately it seems that many incarnations of Scrum (typically flavours of "Scrum in the Enterprise") have lost their Agile roots.

In my opinion excessive grooming and estimating of a product backlog beyond the next two sprints is waste. Of course this depends on the definition of "excessive". A backlog should represent an idea where the product is heading, but demanding an exact and fully estimated backlog to plan and forecast efforts and deadlines of a whole project is just not what Agile was all about. In fact, with an idolized  backlog in Scrum there is not much difference any more to a phased waterfall approach … or to an ingenious gnome scheme of fervently collecting with the belief in subsequent profit...

In all the cases where I have seen this antipattern of an idolized backlog the pressure came from management which took the idea too far by striving for the perfect backlog. In most cases the urgent need for the perfect backlog is a result of overusing planning and monitoring tools: it doesn't matter if it is the handcrafted excel-sheet of the project leader or a sophisticated report-dashboard in Jira or TFS. All those tools imply that there is value in a more complete, more detailed and more accurately estimated backlog … but that was already the fallacy of the waterfall, wasn't it?

However it might be that all of this is just the return of an ancient and evil conspiracy:



Update 2013-06-01: I just watched "You Are Not a Software Developer! - Simplicity in Practice" which has a quote that fits totally in the context of this post:

For planning we need a roadmap, not a road! A roadmap is about option and choices, a backlog is not a roadmap.

Thursday, May 23, 2013

Quotes of the Week: Complexity

We complify where we should simplicate.
Somewhere in the history of building web applications on the JVM, adding layers somehow became part of the solution without being seen as a problem.

Complexity is an expensive luxury… powerful solutions do not have to be complex!

You can only build so much on top of something else, before you have to wipe the slate clean and start over.

The amount of complexity I'm willing to tolerate is proportional to the size of the problem being solved. There will come a point where the accumulated complexity of our existing systems is greater than the complexity of creating a new one.

People pile layers on top of layers, abstractions on top of abstractions, complications on top of complications, crap on top of patches, and patches on top of crap until everything collapses onto itself and the singularity appears.

OOP programs built as towering hierarchies of classes are like perfect crystals, to be admired by architects everywhere but loathed by the programmers responsible for maintaining them.

Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.

Friday, May 17, 2013

Myco: My first iOS App is in the iTunes Store

My colleague Stefan created Myco / Pilzkenner for Windows Phone.
The App won the "Best Windows Phone Apps" award in the Microsoft Switzerland App Award 2013. 

We partnered up and I ported the app to iOS. Myco is now available in the iTunes Store.

There are three editions of Myco: 

StoreIcon114x114 proStoreIcon114x114

StoreIcon114x114 free

  For more information please visit the Myco product page.

If you like the app, please consider submitting a review to the iTunes Store.

Friday, May 10, 2013

Tidbit: How programmers spend their time

From the great talk of Douglas Crockford about Quality:

Screen Shot 2013 04 28 at 10 18 02 PM

This is so true in my experience... that is why I don't get why people are argueing over and over again that  typing is one of the most important skills of a programmer (the latest is example from Miguel de Icaza and Scott Hanselman). 

Sunday, April 28, 2013

Quotes of the Week: Bugs

Software teams have to move away from the idea that bugs are a useful way to measure quality.

Software does not have enough self awareness to be afraid of bugs. That's why it works as well as it does.

Testing shows the presence, not the absence of bugs.

Bugs are like over-parented kids. They get a lot of attention. They might be born in the relative quiet of a developer's IDE, but the moment they are exposed to the rest of the world, they live their lives amidst a great deal of fanfare.

Maybe there’s no such thing as a bug. Maybe there are just things that work well and things that don’t work well.

Unfortunately, in the celebration of testing artifacts (such as counting the number of bugs) we forget about the software. All testing artifacts have value to the extent that they impact the source code and therefore the product.

Comprehensive statistics of past bugs are no more useful for software quality than financial accounts of a chophouse are useful for a steak sandwich.

Wednesday, April 24, 2013

Tidbit: Readings from the Book of Geek

Highly recommended: the first 5 minutes of Dan North reading from the Book of Geek. Its funny and poignant:

In the beginning the software was without form, and void.
The Architects said "Let there be light" and they separated the light from the darkness.
And they called the light Architecture and the darkness Hacking.
And Maven brought forth a Plague of Apache Commons, and there was a flood of all the Libraries of the Internet as a judgement upon the people.

Hard Things Made Easy (Part 1.2) - Dan North

Sunday, April 14, 2013

Tidbit: Cake Mix Analogies

It's funny how cake mix analogies pop up in interesting speeches lately.

Dan Ariely speaks about the IKEA effect that gives meaning to our work, which was essential for the success of cake mixes:

Dan Ariely: What makes us feel good about our work?


In her hilarious talk Christin Gorman shows how cake mixes are stupid and make us not enjoy our work any more, like many generic frameworks we use as programmers:

Hibernate should be to programmers what cake mixes are to bakers: beneath their dignity.

Thursday, February 28, 2013


In his presentation "Designing For Rapid Release" (slides) Sam Newman points out an ugly fact that we often try to ignore: SOA and DRY are to a large extent opposed forces.

Of course this is not a new break-through discovery and I guess it is also nothing new for most battle-proven enterprise developers. But I also have the experience that in most SOA projects this topic is treated like the crazy uncle in the attic: You don't talk about it and you certainly don't plan for it.

The result is usually a schizophrenic feeling: The architecture postulates nice decoupling, but in reality we end up with the feeling that we are not doing it right: either we are using shared logic in several services which negates idea of decoupling or we have a lot of code duplication.

In the presentation Sam illustrated this conflict with two services that share a common domain model:

Screen Shot 2013 02 17 at 4 53 06 PM

In the above picture, since service A and service B are both using a common model from a shared library, they get tightly coupled. On the other hand managing the development and releases of the shared library all of a sudden gets much more complicated under the premise that service A and service B should be decoupled.

He further brings the incompatibility of SOA and DRY to the point with the following quote:

Ending up with tightly bound services because of code-reuse is significantly worse than to copy & paste that code.

I like that Sam makes the conflict between SOA and DRY explicit. Not ignoring this fact is the first step to objectively balance the tradeoffs and to honestly plan how to deal with the drawbacks of either approach.

Friday, February 15, 2013

Quotes of the Week: Developer Testing

Nothing makes a system more flexible than a comprehensive suite of tests! Far above good architecture and good design!
- Robert C. Martin,
Oredev 2008 Keynote
We have as many testers as we have developers. And testers spend all their time testing, and developers spend half their time testing. We're more of a testing, a quality software organization than we're a software organization

TDD is a discipline for programmers like double-entry bookkeeping is for accountants or sterile procedure is for surgeons..
Tests should be made a first-class citizen and treated like any other feature.

TDD, BDD and other high-ceremony techniques are not recommended for startups! Code is not important in the beginning!

I see TDD as a valuable and important development technique, but there are contexts in which it shines and others in which it is a hindrance.

Insisting on unit tests won't make those unit tests valuable.

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence.

If I don’t typically make a kind of mistake, I don’t test for it.

Testing is overrated!

A survey of all the studies on TDD has shown that the better the study done, the weaker the signals to its benefit.

Thinking you can improve quality by doing more testing is like thinking you can loose weight by weighing you more. […] If you want to improve your software, don't test more; develop better.

- Steve McConnell, Code Complete

You cannot inspect quality into a product. The quality is there or it isn't by the time it's inspected.


Much of the essence of building a program is in fact the debugging of the specification.


Related Posts Plugin for WordPress, Blogger...