We were writing a recruitement ad yesterday and were thinking about the kind of skills and experience we wanted for 2 senior developers.
My colleague showed my the web site of a guy presenting himself as Erlang code. This was really funny and I had the idea of writing acceptance tests for the ad!
It went like that:
public class CandidateAcceptanceTest extends TestCase{
Developer candidate;
public void setUp(){
candidate = new Developer();
}
public void testTechnicalSkills(){
assertTrue(candidate.isJavaExpert());
assertTrue(candidate.knowsJDO());
}
public void testMethodologySkills(){
assertTrue(candidate.canTeachAgileMethodologies());
..... and so on
}
We were even arguing about how writing the acceptance tests that would best describe the "optional" skills: the ones that were desired but not mandatory.
The result was indeed quite interesting because I thought: the guy (or gal) that will read this ad, understand it and like it should be on the right track for the job!
20 April 2006
Dynamic languages are scary?
I have noticed a post on the Ruby on Rail mailing list that catched my attention today:
This thought catched my attention since I have been programming a lot on my free time recently with Ruby (as an attempt to prototype some ideas that I found revolutionnary for our product).
While programming, I had many times the impression that I would accidently misname a variable or a method and that my program would fail at run-time. No more compile-time safety. This is like jumping from a plane without knowing if your parachute will open at the right time. And this really made me feel uneasy.
Think about it: you program in java with Eclipse or whatever advanced IDE. Every class name or method name can be safely completed, researched, refactored,... This was a real advance for day-to-day programming. With Ruby, or Python, this is all gone. Scary, isn't it? How can you build large systems, knowing that a single mistyped name could bring the whole system down without you even knowing it right now!?
I was indeed scared! However I could also recognize that I had been able to program a quite complex infrastructure in Ruby that was doing the job! So, what are the keys to more confidence in dynamic languages?
The keys to get more confidence are interesting since they are anyway the foundation of better development practises.
TDD virtous circle
I have been practising TDD for this project, I have been checking my coverage (with rcov) all along and I have paused enough to consider refactoring each time the tests were green.
So the first key is "start the vertuous circle of using TDD". You can start using TDD, just because you're afraid to break anything, anytime. The added benefit is a Test Driven Design.
Ruby is your best refactoring friend
The second key is "use Ruby capabilities to refactor to the maximum". Ruby on Rails has really shown that "less is more" and that duplication could be avoided up to the limit. Most of this magic is done thanks to Ruby. Ruby helps factoring code well beyond what can be done with Java (without AOP and all that metadata stuff). The added benefit is a readable code, aiming at representing the domain and nothing more.
Good engineering is here to stay
The third key is "use your object and architecture skills". Whatever the language, if you design carefully your system, with encapsulation, delegation over inheritance, layers, patterns,... you should end up in a system where undesired effects can not ripple too far. The added benefit is a maintainable and evolvable system.
Fragility turned into strength
So, basically the lesson here is that Ruby (and al.) fragility practically forces you to sign for sound development practises. You get more confidence in your development and the added benefit is that you develop it faster!
> I somewhat agree with you, but I recentlyIt was about implementing financial transaction systems with Rails.
> realized I don't even know *why* I feel that way. Is it because
> dynamic scripting languages, by being way less chatty than something
> like Java, somehow feel more fragile? I seriously wonder.
This thought catched my attention since I have been programming a lot on my free time recently with Ruby (as an attempt to prototype some ideas that I found revolutionnary for our product).
While programming, I had many times the impression that I would accidently misname a variable or a method and that my program would fail at run-time. No more compile-time safety. This is like jumping from a plane without knowing if your parachute will open at the right time. And this really made me feel uneasy.
Think about it: you program in java with Eclipse or whatever advanced IDE. Every class name or method name can be safely completed, researched, refactored,... This was a real advance for day-to-day programming. With Ruby, or Python, this is all gone. Scary, isn't it? How can you build large systems, knowing that a single mistyped name could bring the whole system down without you even knowing it right now!?
I was indeed scared! However I could also recognize that I had been able to program a quite complex infrastructure in Ruby that was doing the job! So, what are the keys to more confidence in dynamic languages?
The keys to get more confidence are interesting since they are anyway the foundation of better development practises.
TDD virtous circle
I have been practising TDD for this project, I have been checking my coverage (with rcov) all along and I have paused enough to consider refactoring each time the tests were green.
So the first key is "start the vertuous circle of using TDD". You can start using TDD, just because you're afraid to break anything, anytime. The added benefit is a Test Driven Design.
Ruby is your best refactoring friend
The second key is "use Ruby capabilities to refactor to the maximum". Ruby on Rails has really shown that "less is more" and that duplication could be avoided up to the limit. Most of this magic is done thanks to Ruby. Ruby helps factoring code well beyond what can be done with Java (without AOP and all that metadata stuff). The added benefit is a readable code, aiming at representing the domain and nothing more.
Good engineering is here to stay
The third key is "use your object and architecture skills". Whatever the language, if you design carefully your system, with encapsulation, delegation over inheritance, layers, patterns,... you should end up in a system where undesired effects can not ripple too far. The added benefit is a maintainable and evolvable system.
Fragility turned into strength
So, basically the lesson here is that Ruby (and al.) fragility practically forces you to sign for sound development practises. You get more confidence in your development and the added benefit is that you develop it faster!
Subscribe to:
Posts (Atom)