The long way round...

We are currently recruiting for a tester at the moment and as ever, this is proving to be a very difficult role to fill. This is partly due to this mentality from development snobs that 'Testers are Idiots'. I've only every recruited a couple of good testers and quite a few bad ones. They're a rare breed of technologists.

So what are the properties of a good tester? To be honest, I simply don't know. However, the best testers I've come across are quirky. They do have an eye for detail. They are passionate about technology. They do develop software and build stuff. They do know how to program using C++, or Java, or .NET, or whatever. They are NOT just 'simple' scripters. They do like to solve complex problems. They are NOT idiots.

But their focus is somewhere else. And this is part I don't get. I love to build stuff using interesting tech for the sake of it. Just to see how it works. To experience it. To see how it feels in comparison to other stuff I know. That's the sweet spot. In the end, what I build it is not as important as the tech that I used to create it with. Sure, I get the, that was a cool project and we hit all the milestones and deadlines. But what I'll take away from the project is the journey, not the destination. And the tech is large part of the journey.

I need to ask that question of a few testers I know and see what they come back with. Maybe that would help. Are testers results-driven? Do they pride themselves in being instrumental in raising the quality of software? Do they like getting the most of teams? Working them and/or working in them? I don't know.

Now if you're a tester, not a developer in a testing role, but a tester, I would love you to comment on the above and put into words why you love testing?

Oh, and if you're looking for a cool place to work, we're recruiting...

This is my last post using serendipity. I never really got to grips with the blogging software and I feel that my move away from wordpress was a mistake. So I've moved back. Problem solved. Here's the new site: http://www.clevegibbon.com/wordpress. Be sure to update your rss readers.

I think I have caught the Ruby bug (always last to the party cleve, always the last to arrive!) in a big way. In between my day job, I have been reading (Programming Ruby, Agile Web Development with Rails, Everyday Scripting with Ruby) and writing (currently re-writing clevegibbon.com) Ruby. However, today I was seriously impressed with RSpec.

RSpec has come on some over the last few months. Armed with RSpec, today was the first time I've completely writing a bunch of new features for a web site, without once using the site directly. Let me put it another way, I didn't fire up my browser once when developing the new features. It was all done via RSpec and Rails built-in support for functional/integration testing. And when I was happy that I had spec'd out the features and all the examples were passing, I fired up the browser, traversed to the site and hey presto, it worked as specified. I had to really shake myself, because I was preparing myself for a troubleshooting and/or debug session. I was simply not ready for it working as specified. So I now have time to write this blog entry...

Oh, before you go, here is the rspec for my Rails controllers for my new features (there are also some for the models, views and helpers). You can probably work out what I'm doing by just reading it. Nice!

AdminController for authorised users
- should have access to secured pages

AdminController for unauthorised Users
- should be re-directed to the login page

HomeController for all users
- should allow anonymous users access

InprogressController for authorised users
- should have access to secured pages

InprogressController for unauthorised users
- should be re-directed to the login page

LoginController for anonymous users
- should log in a known user and send them to the admin page
- should not permit unknown users to login in

LoginController for authorised users
- should log them out and direct them to the home page
- should log out users who attempt to login with a GET request

RubyController for all users
- should allow anonymous users access

StuffController for all users
- should allow anonymous users access

Finished in 0.260431 seconds

11 examples, 0 failures

...MacTeX! Wonderful. Going to back to basics. I used to managed my knowledge portfolio using BibTeX and typeset using either LaTeX or troff. Thank you to all those people that contributed to MacTeX and in particular those that provided a nice BibDesk GUI view of bibTeX files that comes in a handy from time to time.

When I started out on my PhD I was given a great piece of advice from a someone who had just completed theirs: whatever you do, whatever you read, document it! Oh, and one more thing Cleve, make sure you read one article, every day, until you have completed your thesis. This was quite a commitment back in the early nineties, when articles were either stored on microfiche and/or you had to send off for hardcopies to research papers that were maintained by other libraries. Believe it or not, not everything was online. There was no Google Scholar! However, I did this and I religiously spent the first 2 hours of every day in the University library reading, researching and reviewing other peoples work. Then, I documented it. At the end of my thesis I had read just under a 1000 research papers in the area of abstract data types, modularity, object-oriented design, software quality and metrics and met some very interesting people.

As soon as I left academia, and went full-time, this all stopped. Boy do I regret this. No, I didn't stop reading but I did stop taking care of my knowledge portfolio. After reading the Pragmatic Programmer, in which they discuss the need for everyone to maintain their own knowledge portfolio, I feel I need address this. However, you've got to understand, within academia I had invested 10 years of my life to C++. When I got my first job, I left both academia and C++ behind (a big relief), and entered the rather simple in comparison world of Java 1.x (and so on), that pretty soon became .NET. Sure, there was other stuff, but those two technologies pretty much had my undivided attention.

That's all changed now...and over the next couple of months I hope to explain all...

The Random Mango! Great site. I was introduced to this by my 7 year old daughter and her mates. Damage - I lost 5 hours of my life. Personal favourites - Draw Play and Spank the Monkey.

It's rare that you read a tech rant and LOL, but this one by Zed Shaw on why he thinks Rails is a Ghetto shows no mercy what-so-ever. Have a read and let me know what you think? There's always a flip side to everything, seth/jedi, ham/pigs, optimus prime/megatron! I just found the timing funny as I am in the midst of picking up Ruby and RoR.

Oh, please turn off your profanity filters, take a pinch of salt and get comfortable...you're in for an adults only ride!

Well I had to dive in and try Rails. Although Ruby is completely independent of Rails, we live in a web-based world, and as a result you can't talk Ruby with hearing about Rails.

First impressions, pretty cool. To learn it, you need a damned fine book. I wouldn't recommend poking around on the web and reading Introduction to Rails types of tutorials. I did this and found it to be too time consuming to find out what I needed. Rails is deep and you need to commit the time it takes to read a book to get a rudimentary understanding of what it is all about. Tutorials can't do this.

Just like in the Java world, if you wanted to learn about servlets, there was one book you just had to read, Java Servlet Programming by Jason Hunter with Will Crawford. For Rails, it's Agile Web Development with Rails by Dave Thomas and David Heinemeier Hansson, et al. I'm taking my time with this and flicking between the PickAxe book (now in the 3rd edition, ahhh just bought the 2nd).

There's a lot to learn.

Before we go there, personally, I think that Perl is clever language. Damned clever! The magical tricks you can do in Perl's land of plenty is unreal. As such, Perl tends to attract clever people that wrestle with this huge bunking behemoth of a language in a vain attempt to wrestle it under their total control. Many fail, c'est la vie! However, those that succeed never really let go for fear of being trampled underfoot. Just take a look at the poor fella below. That's gotta hurt!


Up until about a few years ago I used to accept my fate and jump back into the Perl saddle only to be battered senseless until I got what I needed from it. Then, a broken man, I ran like hell, never looking back, for fear that would Perl would find me! More importantly, everything I learnt whilst in the saddle, stayed in the saddle. As is always the case with my battles with Perl, I took away very little from each encounter. Nowadays, there are alternatives to Perl, so I don't need to seek it out any more. Why would I? It hurts! In fact, I haven't touched Perl for nearly 12 months now and I feel whole again.

So if Perl is a clever language, used by clever (or stronger) people, then is the resulting software clever? I hope not. Why? Because clever software requires clever people to evolve/maintain it. And as you probably know, there is a distinct lack of clever people in the software industry, so why on earth would I want to go there?

I want a language that is fit for the masses. I don't think that this is Perl. Java and C# are for the masses, whereas as Visual Basic, what can is say, it's all Dim, Dim, Dim!

So what about Ruby? I think Ruby is a little bit too clever at the moment. There are just too many ways to do the same thing. Too many Perl-isms in the language. Too many shortcuts (SGML vs XML again). I haven't looked but I'm sure there must be a set of standards and/or conventions for how best to the use the language. What you should/shouldn't do? The infamous gotcha list that many C++ programming masters continually beat the not-so-clever masses across the head with. We need a best practice for using Ruby language constructs. Even when reading through the PickAxe Programming Ruby book by Dave Thomas and Co, Second Edition (a great read), it's littered with these types of comments and caveats.

Now I ain't no language designer, but I can just imagine the forums are packed with I(H?)MO Ruby should. It's so much harder to take things out than put things in (unless you're talking about a box of chocolates or a jam-packed cake tin that is ). I don't know where Matz is with Ruby 2.0, but things are not going to change that much to simplify the language. Now I don't want to dumb down the language, but more just remove noise. Ruby is rightly expressive to arm us with the weapons to fight damned hard problems. But we need to keep tools like Ruby sharp, clean but free from crap and distractions.

What I'm looking for is more a RubyLite that standardises of best of breed language use, code style and syntax. I think our company's RubyLite will be comprised of a living document and/or supporting examples that developers can lookup and reference as they learn the language. These developer aids will contain gotchas, common idioms, scary features, and so on. The more the language designers can do to remove crap and distractions from the language, and there's not too much to do here, the smaller and more manageable these supporting documents/examples will be.

What do you think?

PS: I don't hate Perl and I love Ruby.

Well that was strange!

After following some rather smashing guides for configuring your Mac for Rails, I needed a good tutorials for writing your first Rails web application. The funny thing is that if you haven't got a web site that is database backed, most of the Hello World Rails Tutorials are pretty much no help what so ever. After the 17th Rails for Newbies tutorial, I felt like I was walking through treacle.

But then, I happened across this article, Rolling with Ruby on Rails that explained things from an HTTP request based principal, and then the database. Heaven!

Outside of work, I'm responsible for two sites really, clevegibbon.com and helent.co.uk. Both are very simple html sites that have been designed in DreamWeaver. I have decided to move away from DreamWeaver and implement clevegibbon.com in Ruby and helent.co.uk in php.

Now, I have recently dropped the Windows desktop and migrated over to Mac OS (Tiger), steering clear of Leopard for now, too many small issues cropping up. That's was when I first heard the term Mac OS X == Linux for Dummies. At first I thought it was a joke, but oh no, we have Linux Priesthood, who look down on lowly Mac Users. How I laughed!

I started using Unix nearly twenty years ago. I still remember my very first shell prompt. I logged into Unix and there it was, winking at me, daring me, I could hear it challenging me: "go on then Cleve, here's a prompt, show me what you can do?". That's Unix! So, being the young fool that I was (hmm, am?) I decided to do some damage. That's when I learnt all about permissions in Unix. I was boxed in and the only damage I could do was to myself and my own files. Unix 1, Cleve 0! Ever since, Unix (and it variants Linux, HP-UX, AIX, BSD and so on) and I have had a mutual respect for one another. Things have been fine. Now, after 10 years in the Microsoft wilderness, I have returned to Unix on my desktop.

So Mac OS X brings Unix to the masses. Great! It standardises and adheres to convention. Nice! It keeps things simple. Sweet! So is Mac OS, Linux for Dummies. No its Mac OS for Mac users. If a dummy can't use Linux, then who really is the dummy? And yes, I love Linux and for sure, there are some great Linux desktops out there, but Mac OS is just fine for me.

Anyway, I've got other issues to contend with. First things first, I need a ruby development environment set up. I'm hearing Xcode, Locomotive, Mongrel, which are new words for me. Time to read...

It's been a game of two halves, and we're entering extra time!

Our house renovation, well the major parts of it, centre around the kitchen. We still have the sitting room and kitchen to sort out before xmas. We need a floor, cabinets, oven, worksurface, sitting room floor and kitchen sink before we can cook xmas lunch. We have less than a month...

I'm reading a great a little book on "the myths of innovation" by scott berkun and came across this great quote by the prominent historian Edward Carr:

"It used to be said that facts speak for themselves. This is of course untrue. The facts speak only when the historian calls on them: it is he who decides to which facts to give the floor and in what order or context...a fact is like a sack - it won't stand up till you've put something in it."

Take a look at a couple of the following facts, and tell me just how much crap someone put in those sacks:

• With agile development, there is no need to document.
• Peanut butter and jelly tastes good (inconceivable).
• Software development is easy.
• Databases are slow, lets use the filesystem, it's quicker (still with us this one).
• Testing is a optional extra if we have time (sigh, why are people still doing this).

What are you then - a developer or an engineer? I think there is a difference the two, and not all developers want and/or make it to engineer.

A developer is someone who can write a piece of software, regardless of whether it works or not. That pretty much includes anyone who can (a) type (b) knows something about software development. If you wound back the clock, say ten years, I would add a few more things to the list like (c) knows what a compiler is (d) understands the fundamentals of hardware vs software (c) have used both dynamically and static typed languages. I understand that things have changed, and the technology focus has shifted somewhat. But let's face it, anyone can loosely be labelled a developer these days.

For me, the term engineer conjures words such as empirical, experience, senior, discipline, team and end-to-end, which are properties I typically find lacking in developers. Now before I get flamed, that's neither a bad thing nor a slap in the face to developers, but merely a clear indication for areas of improvement. I'm always looking for engineers but they are a rare breed. Why? Because, there is not short cut to becoming an engineer. You have to go the long way round! That takes time. However, engineers don't go round saying that they are engineers. You just know when you've met one. No label is required. Moreover, engineers morph in project managers, dads, executives, business analysts, or all of the aforementioned at some point. So when you find a good software engineer, that is still praticising and part of the development team, make sure you get as much from them as possible.

So if there is a shortage of engineers, what do you do? You invest in potential. You invest in talented developers. And this is where the hard work begins. Growing engineers is damned hard. Basically, you're dealing with talented developers that are probably better than you ever were at developing (way back when ), although they are lacking in the other areas, they see development as the primary benchmark against which to measure ability. Now, ability is important, but if I had to chose between an average, seasoned, disciplined, developer and a highly talented, rookie, upstart to join my team, 9 times out of 10, i'd opt for the former. But that's just me...

I really enjoyed watching this InfoQ post on "A Customer's Perspective of an Agile Team" because its good for people for like us, people who build stuff, to keep an eye on how we are perceived by our customers.

The timing of this talk was spooky for me. Recently, I've been running a number of internal projects where I'm the customer. As the customer, it was the first time I was beaten across the head with the agile developer's weapon of choice - cutting scope. When the developers unleash this weapon of mass destruction, it's typically on customers who don't know what they want. We say, "Those silly customers, they are always changing requirements. They never know what they want."

Luckily, because I have a little bit of technical knowledge, I was able to articulate my requirements in a different way so that the team understood (still not the right way round, because the dev team should be trying to understand it in business terms, so stuff to work on there I suppose). I was able to do this because I pretty much knew what I could get from technology. However, consider a real, non-technical customer. Just put yourself in their shoes for a moment. Here you're expected to communicate business value and features, to a team to implement, but you don't have a damned clue about what you can or can't get from technology. Furthermore, the team responsible for deriving business value from technology do not really understand the business, or communicate in business terminology. Instead the dev team break things down into technobabble.

Now of course this scenario never occurs, right? But humor me. The next time you find yourself in the situation where you're cursing the customer, ask yourself, is this because they don't know what they want or that they don't know what they can get? If its the latter, its your job to inform them.

Also, when you say to the customer, sorry but you're just going to have to cut scope, be sympathetic, because what your actually telling the customer is that they cannot get what they need. And as Alexia alluded to in the talk, when cutting scope is not an option, this is the place where creative solutions can be found. But if the agile scope cutting hatchet man is allowed to chop without challenge, these creative solutions will never be explored and customers never get what they need. Let's not go there...