Posted by Uberto Barbini on May 2, 2008
Nice reading, especially the comments. Anyway these are more or less “incomplete agile”.
Maybe partial Junit coverage is not agile, but it’s definitely better than no unit tests at all.
Nightly build are worse then continuous integration but are better than weekly builds, etc.
I agree that there is a kind of “click”, aka “when the team jells”, that happens when you’re correctly doing agile. Mmhh, I said one? Maybe there are several, one fore each step of agile you reach.
Not really sure anyhow, my personal experience is that when agile start to work, organizations reacts and dismantle agile teams.
Anyway I want to add other two Agile AntiPatterns I saw myself:
First signs: 40 hours a week is not a practice but a wish that will never came true. Iterations are fixed both in time and features, there’s no time for pair programming, spikes, crc/mindmap sessions.
Consequences: high turnover, personality problems, quality doesn’t improve much over the time. It’s like a tipical sofware sweatshop but usually managed by some “agile guru” with a bunch of underpaid newbies.
It happens when the Customer change his mind every iteration, and the Team continue to provide new estimates for more or less the same functionalities. At the end the project is cancelled because it’s too late on schedule but it’s still a “technical success”, that is a business failure. The best description I heard of this was at a Jeff Patton seminar at the XpDay2007 in London.
Posted in agile | Tagged: agile, agile sweatshop, anti-patterns, software development, technical success | Leave a Comment »
Posted by Uberto Barbini on April 13, 2008
As usual, latest Martin Fowler’s post is a quite interesting reading.
As Programming Techniques are becoming more and more mature, we should consider to enter in a new arena: instead of bragging each others about what’s the correct way to program, we can jump on the brand new “School of Software Developing” concept.
I already have done the next step and borrowed some ideas from old jap movies. Let me clarifies with an simple example.
How do you place yourself on the eternal question about exceptions? Should they be checked or unchecked?
Speaking for myself (and whoever else?) I like the way Java let you to create an exception that *MUST* be explicitly handled by your class users. But I don’t like the way checked exceptions are used by Java libraries. That is 99.9% checked exception and 0.1% of unchecked.
I think that one should be very vary to pose such a burden on other programmers. 99% of exceptions are really cases in which something did spectacularly wrong (OutOfMemory) or some nasty bug in your code makes impossible to continue (DivByZero, TypeCastError).
Being forced to manage and exception, should be an extremely rare event. When a casual programmer would encounter one of them, there ought to be a very good reason. And he should feel ice-cold drops of sweat run down the spine while considering how to check the exception.
It’s only logical to assume that everything that can goes wrong will do it, eventually. So connection problems, allocation of spare resources, etc. should be always be protected by try..finally blocks.
Generally speaking using exception for completely predictable failures, like a files that doesn’t exist or wrong values from users, is a bad practice to begin with.
OK, stop blabbering. Now the funny part. Maybe you’re agreeing with me, maybe you’re thinking I’m nuts, or maybe you’re not knowing what I’m speaking of. No problem!
I’ll declare that this is the CleanWater School of handling exception, kiyomizu 清水 in Japanese. Because certainly you want a super-cool name for your school.
You don’t like it? Create your own school about handling exception and we can duel each other at dawn next to the waterfall. Or maybe we can meet for breakfast at Starbucks.
Posted in programming | Tagged: agile, checked exception, exception handling, exceptions, martin fowler | 2 Comments »
Posted by Uberto Barbini on March 31, 2008
I’m in debt to Giovanni Asproni for this new acronim. But the fact behind the term is very well known here.
Let’s start saying that it’s a matter of fact, although a sad one, that a lot of enterprise projects are poor designed.
But, as strange it may seem, in my career I (almost) never saw a simplicistic design, they are all wrong on the over-complicated side.
So why is this happening? If they were all producted by morons, they ought to be equally distributed on both side of the Gaussian. Also I have anectdotical evidence that not everybody in the contractor world is a moron (honestly!).
So, as you may have guessed, the reason behind it is a little more complicated and it has Darwinistic-like reasons.
As contractors’ life goes, you need to keep your resume always updated to the latest hype and keywords in order to be recruited. And simply you don’t have enought spare time to learn everything, so…
a solution appears misteriously in front of you: Put whatever is the current buzzword in your next design document.
Add some new fancy framework or library to your current project, and learn it, test it, experiment with it at your usual tariff. It’s brilliant and convenient!
I’m not sure to blame only the contractors, it’s a response to the market absurd rules. If customers were looking for developers who know how write simple and elegant code, they would get exactly that.
Instead they usually hire developers with the most buzzwords complete CV. And at the end, they will obtain CVDD applications. Unnecessary complicated, with tons of once-popular frameworks, often misused, etc. etc.
Disclaimer: in case you’re considering to hire me, I would never do anything of this sort! 🙂
Posted in agile, programming | Tagged: agile, cvdd, yagni | 2 Comments »
Posted by Uberto Barbini on March 23, 2008
I know I’m late, actually I’m always late so there’s nothing new here.
Anyway, some days ago, a post of mine in Milano Jug mailing list, has been quoted by .MOz on his blog.
This is his translation (my actual post was in Italian):
“Blockheads, agile or not, will never produce good code, just as even if you can produce the best software in the world but you don’t understand the domain your project is doomed: technical success is a foolish illusion.”
Maybe “blockheads” and “foolish illusion” are a bit too euphemistic for my tastes, but ok, the meaning is there.
Anyway if you don’t know me, you can think of it as a critique of Agile methods from my part, but it is not. I’m still regarding Agile Methodologies as the fastest and the most cost-effective way to develop software.
It’s only that they’re not a goal per se.
Being fair, probably 99% of Agile practitioners do agree here.
Moreover, methodology is not the Most Important Thing in Software Development, and neither the second one… probably it is the third one MITSD.
It’s like having a race between an old Fiat 500 and a Ferrari Maranello: if the Ferrari driver doesn’t know which way to turn, or if he doesn’t know how to drive a car… he simply cannot win.
Posted in agile | Tagged: agile, software development | Leave a Comment »