What has caught my attention more is something else though. I’m pretty sure that my friend asked me about this because of some unkind words for TDD. So let me get the record straight:

• First of all, it’s just wrong to say that TDD is “the notion that a development team’s automated tests are even more important than the actual software they write, and should be written first” (Jon Evans himself) => no TDD practitioner in his right mind would describe TDD in that way. In particular, nobody would consider the tests more important than the actual software. So, yes, we TDDers think that testing is important, because for us testing is first of all a design technique and tests are a nice byproduct of this technique, one that allows you to evolve your code without breaking existing behaviour in an uncontrolled way. But none of us would try to say that tests are more important, please! If you write about something that is clearly not your forte, at the very least you should not make such a gross mistake.
• I don’t know where I’ve lived in the last 10 years, but TDD has never “seemed almost sacrosanct” (Jon Evans again). I’d argue that still only a minority of developers actually test their code in these days. TDD practitioners then are a minority of a minority. So, please, spare me the drama about the industry changing its mind about TDD.
• With regards to the two linked posts, I have to confess that I have no idea who are the authors. That doesn’t necessarily mean anything per se, just that I don’t have any prejudice about the authors. I’ve never read anything from them before.
• Pieter Hintjens seems to recommend that rather than testing your code, you should throw it out in the open and have people (users) testing it for you. It seems that his main argument is that, even if you think you know how to test your code, you don’t know if your code is valid in the hands of users. Apart from the fact that it doesn’t seem a very professional approach, this is mostly nonsense to me: testing and validation are two different things. Sure, you need your software to do something useful for your users, otherwise it can be correct but it would be of no purpose at all. So, assuming that your software solves the right problem, how do you know that it solves it correctly? Testing to the rescue. In the end the author even admits that he uses TDD for his APIs…
  Having said that, remember that TDD is first of all about design and evolution. So I think that this point is totally wrong.
• Peter Sargeant rants about dogmas and Agile Testing Experts recommending to always write your tests first. The term “Agile Testing Expert” is funny enough already: there are no such people, there is no agile testing, thank God at least there is one aspect of XP that the Agile crowd has not been able to jeopardize with their brand (oh, they tried, but they also failed miserably – some people cover TDD, BDD, ATDD and other practices together under the umbrella of Agile Testing, but it seems quite fictitious to me and it has never been accepted in the community in that way). So, if you talk about Agile Testing Experts I’m already suspicious. Once again, this post seems to miss the point of TDD: it’s about design and evolution, testing is a collateral, an important one but still a collateral. Do I always write my code following TDD? No, I don’t. I rarely use TDD if I’m spiking or prototyping. I never use TDD for one off pieces of code that won’t survive to see the light of a new day. I very rarely use TDD for pure UI code, especially when it’s about HTML and views and layout and CSS… (you get what I mean I guess). And I never use TDD when I don’t know what I’m doing, when I’m exploring.
  Anyway, Peter Sargeant’s blog is in the end about promoting testing automation, so his rant is more about breaking away from dogmas and using your head to judge when to use a tool, so it doesn’t seem to me to be such a big deal.

In conclusion, yes, things may get a little better and no, I don’t think that there is a whole movement against mainstreamed (!!) TDD in the software industry.

Some rights reserved, by Felix E. Guerrero

I’ve read Dan North post Programming is not a craft and I have to say that I have mixed feelings about it.

I’ve always been against recognizing beauty in software in general and in code in particular. I don’t think that coding is an art and I don’t think that any programmer can be characterized as an artist. Code has no aim beyond solving a problem and providing some utility to a user (where a user can be another system, an organization, etc., not necessarily the end user alone). Good code is code that solves a problem AND it’s easy to change, highly cohesive and decoupled, without duplications, etc. Bad code is code that doesn’t express those qualities. So it would be a stretch to talk about good code in terms of beauty, IMO.

And I agree with a lot more from that post. For example, I like and agree with the analogy of the samurai. And I do actually believe that: “It takes a real expert – a real craftsman – to see the elegant simplicity buried away inside the mess we call enterprise software, for instance, and tease it out.”

Having said that, I also disagree with his characterization of craftsmanship, especially in artistic terms. I think that our work, the way I see it, the way I do it every day, has a lot in common with what master craftsmen used to do in Italy during the Renaissance. And a lot of it clearly wasn’t art at all, it’s just good work well done.

Back in 2002, I had a lot of troubles trying to communicate to friends and family my passion about writing code. Passion is not even the right word, “care” is more appropriate. I do care a lot about the code that gets written. And for me, the idea that code must solve a problem, is a given. Speculative coding is like onanism: you get tired of it very soon. So, taking for granted that code must solve a problem, why do I care about how the problem is solved?

Literature to the rescue. In that period I was reading a book from Erri De Luca, callend Montedidio (by the way, it has been translated in English, I recommend it). A passage just drilled in my brain:

Mast’Errico mi ha messo a stendere il turapori e a carteggiare. Alliscio le ante di un armadio per vestiti. [...] Oggi ha provato la chiusura della prima anta e quella ha combaciato così bene che ha fatto il rumore del soffio, l’aria se n’è scappata da dentro. Mi ha fatto mettere la faccia vicina al battente, ho sentito una carezza d’aria. [...] Poi mast’Errico l’ha smontato e l’ha coperto, è un’opera importante, aggiusta tutta un’annata. I cassetti sono di faggio, gli incastri a coda di rondine, una soddisfazione vederglieli uscire da sotto le mani. Controlla gli squadri molte volte, ingrassa le guide, sfila e riinfila i cassetti senza rumore, come la lenza in mare, dice, che sale e scende muta in mano a lui. Mast’Errì, dico, siete un fenomeno, un ebanista pescatore.

A rough translation in English would be:

Mast’Errico put me to spread the filler and sanding. I smooth the doors of a wardrobe. [...] Today, he tried closing the first door and it matched so well that it made the sound of the breath, the air has escaped from inside. It made me put my face close to the door, I felt a caress of air. [...] Mast’Errico then has dismounted it and covered it, it is an important work, it fits an entire year within. The drawers are made of beech, the joints are shaped like dovetails, such a pleasure watching him crafting them with his hands. He checks out the alignments many times, he greases the rails, and he pulls the drawers back and forth without noise, as the line at sea, he said, rising and falling silent in his hand. Mast’Errì, I say, you’re a phenomenon, a cabinetmaker fisherman.

So, this is my take at software craftsmanship almost 9 years ago, recorded in a message to the Italian XP mailing list on 12/3/2002, years before anybody even started talking about it. 
My message back then ended with the following:

A software engineer is a postmodern version of a craftsman. The death of a craftsman can be violent (due to lack of competence, negligence) or because of starvation (overengineering, gold plating). When a technique is overcome a skilled craftsman must reinvent itself or die.

PS: I’ve stopped trying to explain to people my work. In a social context I typically say: “I work with computers”. If I’m really in a good mood I may even say: “I write software”. That’s it. I get less frustrated this way. 

After Fowler’s keynotes, this is the best session that I have attended. The main reason is that its speaker, Michael Norton, was very good: sharp, clear, concise, as a speaker should be.

The presentation was focused on the concept of Technical Debt, conceived by Ward Cunningham back in ’92 and touched by Fowler as well in his third part keynote.

Norton’s intents are to clarify what the metaphor means and which is the proper way to use it. The point is that it’s ok to cut corners in the short timeframe to gain an opportunity (for example, for a demo), but things have to be fixed up properly as soon as possible immediately afterwards. The power of the metaphor lies primarily in the concept of debt and the need of repaying it:

• Every corner that you cut for a specific purpose, for example in terms of code that you know should be done in a different, better way, is debt
• All the debt adds up very quickly and it slows you down
• If you don’t fix that code potentially you’ll end up in a situation where development slows down to a halt and the system needs to be rebuilt from scratch

We should always remember, however, that this is just a metaphor and we can’t stretch it beyond its intended use. It’s indeed a way to think about our own work, it doesn’t magically replace our work with its own laws because we are leaving in a delusion. Norton uses the term metaphorphosis for this kind of phenomenon. In Cunnigham words:

• “[Many] have explained the debt metaphor and confused it with the idea that you could write code poorly with the intention of doing a good job later.”
• “The ability to pay back debt [...] depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem.”
• “Dirty code is to technical debt as the pawn broker is to financial debt. Don’t think you are ever going to get your code back.”

Hence, the important things to remember are:

1. Debt is bad => if you can get away without it, just do it
2. Tech debt is a strategic tool => use it under specific circumstances (eg: I need to change this thing and deploy it in an hour, I’ll refactor it right after the deployment), not as an excuse to do sloppy work
   • Remember Fowler => only the quadrant Deliberate/Prudent is acceptable and only for very short timeframes
3. I’d say that 99.99% of your daily work should be debt free
4. Unintentional dirty code, missing tests, bad choices will happen anyway, that’s why Norton called it cruft => it’s physiological, but it’s not technical debt
   • In my team, for example, we do code reviews also to catch that
   • Intentional cruft is always a bad choice, something that you need to avoid and that when done shows a lack of professionalism
5. You have to deal with cruft every day/hour/minute, don’t let it accumulate, because big incremental fixes don’t work => the complexity keeps growing up at the same rate
6. Clean constantly & follow the Boy Scout Rule: Leave the campground cleaner than you found it (of course campground=code)
7. Monitor your tech debt, also by means of metrics like test coverage, procedural complexity (aka cyclomatic complexity, McCabe number) and cohesion/coupling

I’m not a huge fan of slideshare & viewing slides without attending a presentation, but FWIW Norton has uploaded his slides and they are actually good/helpful. As usual, here you can find my mind map as well.

This is the mind map that I have taken live during Norton's presentation

For me, the big highlight of the day was Martin Fowler‘s keynote. Let me rephrase: Fowler gave 3 keynotes in one, which is nice because it’s not too boring and it flows smoothly.

The essence of Agile

In the first keynote Fowler wanted to clarify his view on Agile, talking about its essence. His motivation was to steer clear of a phenomenon that he calls Semantic Diffusion: when you start being successful at innovating and modulating a message, people try to copy you without deeply understanding what you’re doing, just by mimicking your work and distorting your ideas badly. There’s not a lot that we can do about it, with the exception of reminding people about the core principles at the root of what we are doing.

So he wanted to characterize Agile first of all by difference, talking about traditional plan driven methods. In a plan driven method, success is achieved when you do something according to the plan. This is not absolutely impossible per se, but it requires at the very least that the requirements are stable. The bad news is that outside of very limited and insignificant niches, there is NO such thing (and we all know it very well).

So Agile methods are characterized by adaptive planning, which means continuous planning and release early and often. These qualities together constitute an evolutionary design approach, which I’d prefer to define differently and at the software design level in terms of responsive design, but that’s fine, I can take this.

Fowler also briefly mentioned a quote from the Poppendiecks, which sounds more or less like this: being able to deal with a lot of changes in requirements is a competitive advantage. This is a fairly powerful tool in your hands, so use it wisely.

Another fundamental quality of Agile is its focus on people. We all know that after the industrial revolution the way we intend work has been shaped too much and for too long by Taylor and his stopwatch, the so-called system process. This has greatly slowed down the evolution of knowledge work and it has taken a long time and great minds like Deming and Drucker to correct these problems and show a different path. As Deming said, “A bad process would beat a good person every time”. So Agile methods are characterized by putting that good person at the core of the method and allow her/him to shine and do great things, rather than suffocating her/him with bureaucracy.

Because of this, Agile methods need to be adapted to the specificities of the people and their organization, while maintaining the other characteristics mentioned above (while this is fundamental, it is also another contributor to Semantic Diffusion, but again we can’t do much about it). So, Agile methods are characterized by self adaptivity. As Kent Beck says, “In software development, “perfect” is a verb, not an adjective”. This means that the process is never static, but it is continuously verified and improved, always striving for perfection (but of course never achieving it fully).

This is the mind map that I have taken live during first Fowler's keynote

Continuous integration & delivery

In the second keynote Fowler focused on continually adding value to a system.

He started by describing an experience so common if you have developed software for a living in the previous millennium: if you have worked in an environment that doesn’t adopt continuous integration then you know that a project can be easily doomed, staying in integration mode for a very long time.

The idea is simple:

• Individual developers work on their own code, that is they develop feature independently
• Towards the end of the project they put everything together and of course nothing works

The metaphor is having 2 teams digging a tunnel into a mountain from 2 opposite sides and failing to meet in the middle. I actually have seen something like this happening in big construction work in Italy. It’s scary.

Even when versioning systems became popular, people tended to do feature branching more than anything else:

• Every developer has his/her own branch, defined for the feature that he/she is developing
• Because integration is difficult and painful integrate less often
• Because integration happens less and less, when it actually happens is more difficult and painful

This brings to what Fowler calls big scary merges, where you merge together a lot of files, even through sophisticated tools that do that automatically for you and from a text perspective the code seems good, but what about the semantics? You need tests to tell you whether the merge was good or not. And you have a lot of red bars for a very long time, because no tool can automate a slight change in the semantics of the protocol between two classes, for example.

The amount of pain that a team gets grows exponentially with the amount of time that incurs between integrations. I mean, more pain = more time & more bugs = more costs & fewer opportunities to generate revenues.

In the Agile world, typically when something hurts you wanna do it more often. What does this mean? It means that when something is problematic, we want to make it simpler, less expensive, so rather than hiding our head in the sand and try to procrastinate the pain as much as possible, we prefer to tackle it right away and make it better before it’s too late.

So, we want to do continuous integration many times a day, which is exactly what happens at my main gig (my beautiful day job) and in many other companies. I’d say that continuous integration has become more or less mainstream these days, which is good. For example, yesterday we have integrated our code something like 30 times. Integrating means compiling, building all the artifacts, running various kind of checks and thousands of tests. All this is entirely automated.

A bad consequence of feature branching, by the way, is that it encourages avoiding code/design improvement (because it’s painful). So the code quietly rots, day after day, to the point where it becomes a big steaming pile of PUT HERE YOUR FAVOURITE EXPRESSION. Been there, done that, never want to do it anymore in my life.

En passant, Fowler recommended Paul Duvall book on continuous integration.

Towards the end of this part Fowler spoke about continuous delivery, which is a big topic. For the non technical people out there the basic idea is to stretch continuous integration into the actual deployment. How can you do that? By building a pipeline of machines where:

• The code is automatically compiled and unit tested => this should take less than 10′
• Artifacts are generated into a repository
• Artifacts are taken and deployed in a different environment where all functional/acceptance tests are executed in a timeframe that can be measured in hours for complicated systems
• The next stage is typically the one where performance tests are executed to ensure that the system is still executing in an acceptable way and again it can take hours, even more than the previous stage
• If everything is fine the code can be automatically deployed in production in a controlled way, where you do smoke tests to see that nothing is horribly broken

Fowler emphasized that while the last step can be typically controlled manually, and it may vary a lot from org to org (eg: you can’t do it automatically if you have to ask for permission to a committee in a bureaucratic organization), the infrastructure should be in place to do it automatically, with a simple click of a button. As Fowler said: “There should be no technical reasons impeding an automated deployment, while it’s perfectly reasonable that there are business reasons to batch many commits in a single deployment controlled manually”.

Of course Fowler recommended Jez Humble book.

This is the mind map that I have taken live during second Fowler's keynote

A sketch of continuous delivery pipeline depicted by Fowler

Effort, quality and feature development

This third part can be summarized with the following quote: We need to put less effort on quality to put more effort on feature development

At a first glance, this seems sacrilegious, but if you think about it, it doesn’t talk about results, it talks about effort. Hence, it’s actually good to achieve high quality without putting into it much effort, so that we can concentrate on devoting this effort to more labour intensive feature development. Or anyway let’s put effort where our labour is more likely to pay us back directly.

Fowler started by mocking Uncle Bob and his preaching attitude towards quality. It was actually very funny and I think that Fowler is right. Nevertheless, in all fairness Uncle Bob makes the point that all effort devoted to quality pays you back in terms of sustainability and efficiency over time. But certainly he deserved to be mocked, even though with a great deal of sympathy.

Fowler wondered whether quality is tradable. He makes the distinction between internal and external quality:

• Internal => It’s not visible, it’s about software design, cohesion and coupling, code, architecture, etc. It’s like the engine of the car, it’s a kind of magic, hidden under the hood, if it’s not in order all of a sudden the car will break and you’ll be left counting on your feet only
• External => It’s the classic concept of quality in terms of visible behaviour or features of a system, what customers and end users experience out of it

Fowler’s point, and I can’t agree more, is that while external quality is tradable, internal quality is not. Now, we should open a big parenthesis here, related to the differences between startups and sustainable development, the cost of missing opportunities, but for now bear with me. Let’s just say that in the long run, internal quality is overall not tradable. I think that we would all agree on that.

Fowler goes on with his Design Stamina Hypothesis, in order to explain what I just briefly synthesized. The graph from Fowler’s article says it all I suppose.

The idea is that beyond a certain critical mass, the only way to have your system growing linearly with your effort is to keep things in order in the house. Otherwise, development slows gradually.

Then Fowler talks a little bit about the Technical Debt metaphor, that I will explain more in details when talking about another session. Just think that every bit of cruft that cripples into the system is going to sediment and accumulate and you’ll have to pay it back like accrued interest on the principal. It’s a very powerful metaphor that explains well certain phenomenons happening on aging code bases.

Lastly Fowler put up a nice table that tries to classify the different ways in which a team can get in Technical Debt.

I think that he was being nice, because I would have used Incompetent instead of Inadvertent. Anyway, the only quadrant where eventually can be temporarily acceptable to be is Deliberate/Prudent, but you don’t wanna stay there for very long. Certainly never Reckless.

So, in the end, the conclusion is that to put more effort into feature development you have to put more continuous effort into internal quality, without compromising in the long run, or this will slow you down more and more and more. I don’t remember if Fowler explicitly said that but that was clearly the whole point.

This is the mind map that I have taken live during third Fowler's keynote

To recap, an enjoyable keynote, or series of keynotes if you prefer, delivered by Fowler in a very pleasant way. For me, they keynote alone was well worth attending the conference.

Photo by Fyffe

Recently, Ron Jeffries blogged about Scrum and the Scrum Alliance in Scrum is OK. Let’s get to work! => while I agree with the spirit of his post I think that Ron is too indulgent with certain Scrummers and the Scrum Alliance in particular. In any case, this post is not about that.

This post is about something that Ron’s post made me remember. Specifically, the idea of inclusiveness. Some years ago, the illuminated CEO of a software company hired me, impressed by the sense of novelty that most of the things about XP were inspiring at that time (and they still do, to some extent). We were green, surely naive, but genuine and we put all ourselves into it.

As usual, people matter more than anything.  Some colleagues were surprisingly positive and cooperative. Some other a huge disappointment. To my surprise. As I’ve just said, I was green. There was a guy in particular, not so young anymore, who was bullying anybody around and who kept making pointless observations about the fact that XP wasn’t covering explicitly a specific situation that one can encounter under some not so common circumstances. My replies were always that, no, XP in fact wasn’t addressing that problem as stated, but by using some logic and referring XP’s values and principles I was always able to come up with some decent strategy. I tried to talk about adaptation and positive/negative feedback. We could have started from that, if that was a real discussion, a genuine attempt to discover something together. But of course it was not. The guy was just trying to put me down. The irony is that this was a person who couldn’t describe his work in any sensible way, and for which the most sophisticated admissible software method was just slam some code together and we’ll figure it out. Yeah, right.

I guess that this story teaches a few things:

• Don’t feed the trolls (have I mentioned already that I was green?) => this seems obvious but especially in an organization where you start sensing hostility, not only you have to pick your fights but also your genuine discussions
• There will always be somebody trying to find some holes in your proposals and ideas, some aspects that what you’re proposing doesn’t cover => dig a little bit, to check if you’re dealing with a troll or if behind some roughness there’s an inquiring mind, but don’t waste too much time

In the end, colleagues are a bit like customers, and there will always be somebody who’s not happy with what you do. It’s the price to pay for innovation, whose alternative is stagnation. Especially when you’re trying to change an organization, the percentage of unhappy people may be significant, sometimes the majority. That’s ok, it’s part of the game. As they say, change the organization, or change organization.

I don’t want to make it necessarily such a big moral fuss, even though it’s quite important. Today I just want to focus on your investment, as a company, in hiring the right people regardless of their experience or job title. My friend Antonio Cangiano has brought to me an ideal occasion when he reported about his experience hiring two interns for the DB2 Team at IBM Toronto Lab. Specifically, I found some of the reactions in the comments very surprising, especially those commenting negatively about the effort that Antonio and his colleagues have put together to hire two interns, starting from about 100 resumes. What is even more depressing is that it seems that some of the comments come from developers themselves and they go along these lines: How can you possibly devote so much time/energy and ultimately money to hire two shoddy interns?

I wanna reply by telling a story. Between the last 5 years in Canada and 7 years before in Italy I have been ultimately responsible for hiring probably a total of 60 or 70 developers, with experience between 0 and 10 years of software development. While not every developer that I have hired was exceptional, most of them were great and I have to say that I have refined the process over the years. In the end, I have regrets only for one case: one of the very few cases where my gut was telling me “no”, I had some doubts (which is already a no-go in my books), but despite that I wanted to give a chance to the guy in front of me, full of energy and unfulfilled promises. Well, I should have listened to my guts. Nevertheless, one bad mistake in 12 years is not too bad, I think.

Three years ago my company wanted to hire one intern. We had a great respect for developers coming from CS at the University of Waterloo, Ontario. In fact, almost all the developers of the team were coming from there. So we thought that we wanted to give a try to their internship program. The only caveat: the internship lasts for 4 months only, so you have to carve the right amount of work, with the right degree of complexity, or the risk is to have an inexperienced developer to babysit all day without getting much out of her/him.

I’ve made very clear with my boss that I wanted to follow the same rigorous process that I used to follow with every other developer. Time after time, that process constantly showed us that in order to hire 3 developers we had to examine at least 100 resumes. That matched my experience in Italy too.

So, after the usual sing and dance we hired D. and we were quite confident that he would have done a good job for us, even under the very limited conditions imposed by such a short term. Nevertheless, D. exceeded our best expectations and he delivered much more. I guess that the feeling had been mutual, because he came back for more terms not only the year after but even two years later, long after I left the company.

A few months ago we had an opening at my company and I thought about D. almost right away. I have been lucky, in terms of timing, because he was about to graduate and finally he could take a fulltime job. D. has worked with us since then and he has demonstrated to be such a great player for the team. Paraphrasing S.R. Hadden character in Contact, I consider D. one of my best long term investments, entirely worth the time/energy and money spent four years ago to hire him.

It is done: a few minutes ago the English catalog of ThinkCode.TV has gone live! We are 2 days later on our original plan (oh boy, you have no idea of the amount of glitches, 3rd party service disruptions, personal tragedies, Murphy’s law manifestations… that we have incurred into in the last few weeks), but at this point it doesn’t matter anymore. What matters is that the catalog is out and we can finally get feedback outside of the Italian technical community.

While some videos are derived from our Italian catalog, translated and narrated by an English mother-tongue speaker (David B. Harris, who happens to be a colleague, a good friend and an outstanding author as well), there is some original content that is not available in the Italian catalog too. For example, Renzo Borgatti has updated his screencast about MacRuby and HotCocoa to the latest version and David, as hinted above, has started his course about FOSS Document Management tools.

We are proud to offer subtitles for every video. I personally know English-speaking geeks who like subtitles in any case, at the very least because they can be searched and they can provide an alternative way to browse a video. On the other hand, we are convinced that a lot of people who are not too comfortable with Enligh-only content will benefit from the possibility to read the subtitles to catch even the tiniest detail.

With regards to my stuff, the first lesson of the Guide to Test-Driven Development is available. I’m very excited to see what the reaction of the community will be. Only in the last few days we are starting to see some excellent screencasts popping here and there, but nothing yet to my knowledge that resembles a complete approach to TDD like this course. The Italian version of the guide is one of the bestsellers of the Italian catalog and I hope that it will go well in English too. There are currently 3 lessons available in Italian (with the 4th one coming very soon), so you can expect a steady flow of lessons.

There are a lot of other screencasts that I’d like to produce, touching mainly on topics like OOP, design, refactoring and testing. So many things to do, so little time.

Coming soon, apart from continuing on the courses that we have started, we will have a great introduction to HTTP, an excellent course on Smalltalk and an interesting screencast covering how to upgrade a webapp to upcoming Rails 3.0 release. So, enjoy, give us feedback, and stay tuned!

I’ve been extremely quiet in the last months, but for a good reason: together with some friends we have founded ThinkCode Labs Inc., a Canadian startup whose first project is ThinkCode.TV. Our mission is to deliver high quality technical screencasts, mostly about programming themes.

We have launched on the Italian market in November 2009 and it has been quite a success and a hell of a ride! Now we are on the verge to launch in the English speaking market as well. We will launch on April 19th.

I’m producing an 11 lessons course on TDD which is doing great with the Italian public. I’m touching on subjects like characterizing TDD’s microcycle, finding the next test, dependency injection & mock objects, responsive design, BDD and dealing with aspects like legacy code, handling time & databases. I can’t wait to see which reaction we will get with English speakers.

In the meantime, we are offering a free appetizer for anybody interested: a fantastic 19′ video about implementing a maze solver in Python. You can grab it here: please, let us know what you think about it and if you like it, by all means, spread the news.

Anyway, he told me that none of the persons replying to the job post in Spring 2008 that brought to my employment was actually a native English speaker. I was in shock. The posting was kind of hardcore and a bit silly at the same time, so I understand that not everybody could have been attracted by it, especially if you want to work in a typical big enterprise setup. But the idea that there were no Canadian-born technologists in Toronto willing to even reply to it and being able to survive a simple resume screening is kind of disarming.

Where have all the technologists in the GTA gone? Where are the hardcore developers? Have they maybe transitioned to a managerial path and they have totally lost the technical side of the job? Natively English-speaking software architects, development managers, XP coaches… where are you? Are you all doing consulting?

Hard to say. Certainly one of the things which motivated my decision to leave Italy was the increasing difficulty to find interesting technical jobs that could afford to pay my admittedly good salary (for Italian standard). But here the situation is different: there are still a lot of attractive jobs from a technical perspective, paying good money and yet, no old Canadians interested in doing them?!?

I find it fascinating. Good for immigrants and new Canadians I suppose, but nevertheless wrong. And this happens despite the presence of great Engineering faculties like Waterloo and UofT, just to name the first two that I can think about.

So, once again, where are you?

replacer.rb

exp_search = '<%=launchBean\.getCustomVersion\(\)%>'
exp_replace = '${xsession.info.launchBean.customVersion}'
directory = '**/'
file_mask = '*.jsp'

Dir.glob(directory+file_mask).each do |file|
  File.open(file, 'r+') do |f|
    content = f.read
    if /#{exp_search}/ =~ content
      s = content.gsub(/#{exp_search}/, exp_replace)
      f.rewind
      f.write s
      puts "#{file}: #{content.split(/#{exp_search}/).size-1} matches"
    end
  end
end

deleter.rb

exp_search = 'useBean.*launchBean'
directory = '**/'
file_mask = '*.jsp'

Dir.glob(directory+file_mask).each do |file|
  count = 0
  content = ""
  File.open(file, 'r+') do |f|
    while line = f.gets
      if /#{exp_search}/ =~ line
        count += 1
      else
        content = content << line
      end
    end
  end
  if count > 0
    File.open(file, 'w') do |f|
      f.write content
      puts "#{file}: #{count} lines deleted"
    end
  end
end

These commands are especially useful if you have to refactor a codebase that doesn’t provide direct support with refactoring tools. In this case, I was refactoring a few hundred JSPs of a legacy system.

Credits to RSF & Ruby One-Liners for most of the code & ideas. rcscript seems to be a bit too much for me at this time, I’m perfectly happy modifying replacer.rb and deleter.rb when I need it.