Object Mentor Blog: Good things come ... eventually

Good things come ... eventually

Tim Ottinger — Tue, 23 Jan 2007 16:19:00 +0000

There is an old adage that good things come to those who wait, provided they work real hard while waiting.

I read a blog article today that made me sad. The blogger mentioned that they were doing TDD and using Clean Code techniques and building a working system. His company, apparently distrustful of the newness of his approach, hired a consultant to come and critique the team’s code. I like that the company lets the team try new things, and that they decided to check on the team’s results. So far, this is all good.

Here’s the sad thing: the consultant (allegedly) made a number of old-school recommendations based on practices that have been obviated.

He suggested having comments and name warts and other ugliness. It was almost like he was recommending regression based on the idea that "normal" programmers aren't able to deal with good code, being accustomed to ugly code with apologies scattered throughout.  That's unfortunate, and I suspect it's extremely good-intentioned.  I would call it a "misplaced kindness."

I don’t know the blogger’s company and wouldn’t ask, but in general I am always surprised at how slowly transition takes place in larger companies. Body inertia (in the F=ma sense) is hard to overcome so people are using expensive version control systems that are two generations behind the times, old-fashioned waterfall methods, code documentation practices that are completely obviated, a total sense of denial toward open-source tools, and rigid frameworks whose owners have abandoned them for more workable systems. It’s an ugly situation, but on the other hand countless fads and bad ideas have caught fire only to die out. Those companies nearer the trailing edge didn’t jump on the wagon only to jump off painfully later. There is an advantage to being a late adapter.

The trick in working with the slow transition is that we mustn’t confuse frustration with failure. Ultimately, the world does move forward and new practices are eventually accepted. It is an issue of patience with those who drag behind and perseverance in moving them forward. It’s primarily a matter of education and evidence and time.

Somehow OO and dynamic languages and version control and CM and all of various other breakthroughs eventually permeate the work-o-sphere. Few of us need to ask permission to use OO or to draw UML on a whiteboard or to use color syntax highlighting or “intellisense” or word processors or our favorite text editors, but at one time we had to fight about it.

If the Agile ways are better (and I think they are) then we’ll eventually see these techniques as the mainstream and the idea of naming warts, long functions with long comments, and test-last programming will seem laughable and quaint to the most conservative organization. Refactoring tools will be the least we expect from our IDEs, and open source servers and libraries will be prevalent. I think that day is coming.

"Good things come ... eventually" by Wilhelm Schwarz

Sun, 04 Mar 2007 21:29:05 +0000

I would think about this the other way around:

If some companies know how to do better and some companies are still in the stone age, this is good for the companies that know better.

Companies compete among themselves, so it is important that most of them fail for others to succeed. If they choose to use older practice, which has shown to make projects fail, that is good.

Just choose a company that is willing to succeed and to pay the price for success, which mostly means that it lets its developers learn new techniques and feel responsible for what they are doing.

"Good things come ... eventually" by Martin Jul

Wed, 24 Jan 2007 13:56:03 +0000

Let me provide some more background on the case.

One that particular project I was a consultant (architect/tech lead) working with a customer’s team. Our customer itself was another consulting company working for an enterprise organisation. The project was to replace their legacy mainframe with a .NET application. The enterprise organisation had hired a code reviewer to check the project. He came from yet another consulting company.

We used standard, but modern techniques like TDD, an inversion-of-control container (Castle Project) and an OR-mapper (NHibernate).

The consulting company we helped learned to appreciate our agile practices – initially there was the normal resistance to change but in the end it is hard to argue against results.

For example, when we introduced the OR-mapper (NHibernate) the DBAs put up a fight since myth has it that Stored Procedures always perform better. Only when we measured and showed that it did in fact perform well and that it would free up four DBAs from writing SPs for many months did the resistance die out. It is hard to argue against facts like that.

The resistance from the code reviewer was basically due to his assignment. He was asked to review the documentation. The intention was to check the documentation to make sure that the enterprise organisation could hire someone else to work on the application afterwards. The underlying agenda was to avoid supplier lock-in. This, of course, is perfectly reasonable.

The problem was that the reviewer had almost fourty years of experience in application development but none with unit testing, mocks, inversion-of-control, OR-mappers and Selenium (automated web integration testing).

From that perspective, documentation is the green comments in the source code – the XML that can be extracted to a help file. And – since comments provide the only value from this perspective – no value was assigned to properly named methods or simple, readable code with tests that document the expected behaviour.

He actually managed to find one piece of code in the system that he liked. It had comments (apoligies!) – it was a complicated business rule reverse engineered from the legacy system.

To make a point I refactored it to its simplest extreme and removed all the comments and at that point it became apparent that the business rule was specified in a way that made no sense.

From my perspective that proved the case for readable code.

However from the perspective of the organisation paying for the project all they saw was consultants disagreeing about the right approach.

Eventually however some Asian consultants were in-sourced to the project to write a bunch of data export jobs and after we proved that we were able to get them up to speed quickly we did not have any more interference from the code reviewer.

So the story ends well.

There will be resistance to new ways of working, but it is possible to overcome it by showing good results.

The big lesson learned was that if code reviews or other external factors are allowed to interfere there is good wisdom to be found in the principles behind the Agile Manifesto – “customer collaboration over contract negotiation”. Focus the work on proving that the method is sound by showing good results.

For non-developers direct experience is much more powerful than quarrelling over abstract concepts of “good code”, so demonstrating that their concern about vendor lock-in was addressed properly removed the obstacles.

That’s another facet of agile development.

thanks for the extra detail – tim