"I will learn it when I need it"! I've heard that phrase a lot over the years; it seems like a highly pragmatic attitude to foster when you're in an industry as fast-paced as software development. On some level it actually IS quite pragmatic, but on another level I am annoyed by the phrase. It has become a mantra for our whole industry which hasn't changed said industry for the better. The problem is this, in the guise of sounding like a wise and practical developer, people use it as an excuse to coast. There is too much stuff to know, it is necessary to be able to pick certain things up as you go along – part of the job. But, there is a difference between having to "pick up" some knowledge as you go along and doing absolutely everything just-in-time.

The whole industry has become a bunch of generalists, maybe it has always been this way, I just wasn't around to see it, either way I don't like it. Noone wants to invest the time to learn anything really deeply, not computer science fundamentals, not the latest tech you're working with, not even the language you've been coding in every day, for the last few years. Why bother, it will be replaced, superseded, marginalised and out of fashion before you're half way done. I've discussed this with various people many times, but noone seems to really see it as a problem. "Just being pragmatic dude". In the meantime we've all become clones of each other. You want a Java developer, I am a Java developer, you're a Java developer, my neighbour is a Java developer. What differentiates us from each other – not much! Well, I've got some jQuery experience. That's great, so you know how to build accordion menu then? Sure, I Google it and steal the best code I find :). In the meantime, if you need to hire a REAL expert (in anything, maybe you're writing a fancy parser or need to visualise some big data), I hope you've stocked up on beer and sandwiches cause you're gonna be here a while.

Ok, there are ways to differentiate yourself, I have better communication skills, which is why I do better. That's important too, but, developers differentiating themselves based on soft skills rather than developer skills – seems a bit twisted. We all communicate really well but the code is a mess :). Hell, I shouldn't really talk, I am a bit of a generalist too. Of course I'd like to think of myself as a T-shaped individual, but if we're completely honest, it's more of a dash-shaped or underscore-shaped with maybe a few bumps :). To the uninitiated those bumps might look like big giant stalactites – T-shaped indeed. You seem like an expert without ever being an expert, just one advantage of being in a sea of generalists.

Investing In Your Future

I don't want to preach about how we should all be investing in our professional future, everybody knows we should be. Most people probably think they are infact investing, they rock up to work, write a lot of code maybe even do some reading on the side, surely that must make them an expert in about 10 years, and a senior expert in 20 (I keep meaning to write more about this, one day I'll get around to it :))? But, if that was the way, every old person would be an expert in a whole bunch of stuff and that is emphatically not the case. Maybe it is just that people don't know how to build expertise (there is an element of truth to this), but I have a sneaking suspicion that it's more about lack of desire rather than lack of knowledge. What was that saying about the will and the way – totally applicable in this case?

I've gone completely off-track. "Investing in professional future" is just one of those buzzword things, the mantra is "I will learn it when I need it". It was good enough for my daddy and it has served me well so far. Let's apply this thinking to finance, "I will invest my money when I think I need the money". Somehow it doesn't quite have the same kind of pragmatic ring to it.

You Don't Know What You Don't Know

We've all had those moments where you're going through major pain trying to solve a problem until someone comes along and tells you about algorithm X or technology Y and it makes everything fast and simple. It was lucky that person just happened to be there to show you the "easy" way, otherwise you would have spent days/weeks trying to figure it out and it would have been a mess. You can't be blamed for this though, you don't know what you don't know. For me, this is where the "I will learn it when I need it" mentality falls over. You can't learn something if you don't know it exists. Google goes a long way towards mitigating this problem, but not all the way. There are plenty of problems you will encounter in the wild where you can beat your head against the wall ad infinitum unless you know what class of problem you're looking at (e.g. if you know a bit about searching and constraint propagation, solving sudoku is easy, otherwise it's really quite hard). You can't learn about an algorithm if you're not aware of it or its applicability. You can't utilise a technology to solve a problem if you don't even realise it has that capability. You're not going to always have someone there to point you in the right direction. I am willing to bet there is a billion lines of code out there right now which can be replaced with a million lines of faster, cleaner, better code simply because whoever wrote it didn't know what they didn't know.

I seem to be making a case for the opposite side here, if knowing what you don't know is the ticket then surely we should be focusing on breadth of knowledge. Superficial awareness of as much stuff as possible should see us through, we'll be able to recognise the problems when we see them and then learn what we need more deeply. Except it doesn't work like that, skimming subjects doesn't allow you to retain anything, our brain doesn't work that way. If we don't reinforce and dig deeper into the concepts we quickly page that information out as unimportant, it is a waste of time (think back to cramming for exams, how much do you remember the next day?). However if you focus on building deeper understanding of a subject – in an interesting twist – you will gain broad knowledge as well (which you will actually be able to retain). My grandad is a nuclear physicist, several decades of working to gain deeper knowledge of the subject has made him an expert, but it has also made him an excellent mathematician, a decent chemist, a pretty good geologist, a fair biologist etc. Just some empirical evidence that seeking depth leads to breadth as a side-effect.

Can You Learn It Fast Enough

Some stuff just takes a long time to learn. I am confident I can pick up an ORM framework I haven't seen before without even breaking stride, I've used them before, the concepts are the same. But what if you need to do some speech to text conversion, not quite as simple, not enough background. Hopefully Google will have something for us to copy/paste. That was a bad example, only research boffins at universities need to do that crap. How about building a website then, we all know how to do that, but what if you need to do it for 10 million users a day. We just need to learn everything about scaling, I am sure the users will wait a month or two for us to get up to speed :). Yeah, I am just being stupid, all we need to do is hire an expert and … errr … oh wait, we're all out of beer and sandwiches.

Why Should I Care

Working with experts is freaking awesome. You may have experienced it before, everything they say is something new and interesting, you learn new tricks with every line of code, you can almost feel your brain expanding :). You want to learn from the experts, so it's really sad when you can't find any. Since everyone is only learning when they "need it", noone can teach anything to anyone. The chunk of wisdom here is this, you want to work with experts, but the experts also want to work with experts, so what are you doing to make sure the experts want to work with you? Being able to learn something when you need it is a good skill to have, but you can not let it be your philosophy as a developer. Yes it is a big industry you can't learn everything, so pick something and make sure you know it backwards, if you're curious enough to follow up on the interesting bits, you'll find you have a decent grasp of a lot of other stuff at the end. And if you do a good enough job, other super-awesome-smart people are going to want to come and hang around you cause they'll be able to learn something from you and you'll be able to learn much from them. Everybody will be a winner.

Image by SamueleGhilardi and SpecialKRB

Related posts:

1. The Difference Between A Developer, A Programmer And A Computer Scientist
2. Here Are Some Words That Rhyme With Orange!
3. Building Software Development Expertise – Using The Dreyfus Model

Something has always struck me as a little bit off, about that "statistic" (or its equally unlikely brothers, 199 out of 200, 19 out of 20 etc.). I remember reading Joel's post alluding to this back in the day, then Jeff's a couple of years ago, there were a few others, most recently this one. And as much as I want to just accept it (for reasons of self-aggrandisement), I can't. I've been in this industry for a few years now, in that time, I've met some really good developers, a bunch of average ones, even the odd crappy one, but I am yet to meet the veritable army of totally useless non-programming programmers that must surely exist if those numbers are accurate (the "architects" don't count :P).

Why Should Top Developers Seek You Out?

Whenever I see the latest post about how hard it is to hire good people, because x out of y developers are useless, one question immediately springs to mind. Is that x out of y applicants, or x out of y working developers? There is a massive distinction. Unless you're a company trying to compile stats by doing an industry-wide study, you can't really comment on the skill levels of all working programmers in any authoritative fashion. So, we must be talking about x out of y applicants. But once again, it's not applicants in general it's applicants to YOUR company. All of a sudden the headline is:

X out of Y Applicants for Positions Advertised By My Company Can't Program

That's a whole lot less impressive/sensational and whole lot closer to reality. But, let us dig a little deeper. It's not just the one company, too many other people/companies have had the same pain. Which is perhaps why these posts receive so much attention. It's cathartic to have a bit of a whinge along with a bunch of other people who feel your pain :). My question for everyone is this, what makes your company so special? How much time did you spend making sure your ad was sufficiently attractive to the star developers and a sufficient deterrent to the crappy ones? I can tell you right now the fact that you're the "world's leading enterprise wodget provider", the latest "well-funded social startup" or pay "above industry rates", is not going to bring the coding elite knocking on your door. I guess it comes down to this, if you try to attract talent in a generic fashion you will attract a generic response, meaning that there is a decent chance your 200 applicants were ALL a bunch of discards.

Blame Your Interview Process First

Go back to that article of Joel's that I mentioned above where he talks about the 199 useless programmers who apply for every job thereby inflating the applicant numbers. I don't think those 199 wannabe programmers exist, I think the pool is much larger. There is a whole bunch of, let's call them "aspiring programmers" who are totally crap and either can't get a job or can't keep one, which doesn't stop the from trying. A significant percentage of your applicants are those guys and yeah they can't program, but then again I wouldn't really call them "programmers" either. It wouldn't take long to get discouraged and cynical about the whole industry when dealing with those guys for days on end. But let's say you can screen all those out via resumes or whatever and only end up with seemingly legitimate applicants, how come so many of those can't code their way out of a paper bag?

Firstly, you didn't really screen all the discards out via the resumes, that's not possible, I've seen some highly impressive resumes from some highly unimpressive people. All our stats are already suspect at this point, but let's plow on anyway. Likely the next course of action is to screen further via phone or face-to-face or both. We ask simple coding questions like the fizzbuzz, but our applicants still fail – even ones that shouldn't:

"Here is the question that the vast majority of candidates are unable to successfully solve, even in half an hour, even with a lot of nudging in the right direction:

Write a C function that reverses a singly-linked list.

That’s it. We’ve turned away people with incredibly impressive resumes (including kernel developers, compiler designers, and many a Ph.D. candidate)…"

That's from the RethinkDB post that I also mentioned above (I am not picking on the RethinkDB guys, it is just conveniently the latest post on the subject that I have read :)). Kernel developers, and Ph.Ds can't reverse a list? That seems entirely unlikely. Perhaps it is not the people who are to blame but the process. We have learned, especially over the last few years that it is often the process that prevents a software team from being productive. These days most teams would cast a critical eye towards their process when looking for causes of dysfunction, before they start pointing fingers at each other. So, why not cast the same critical eye towards the interview process? Perhaps the objectives of the interview are unclear, or you're not communicating well enough, or you're using the wrong medium for what you're trying to achieve (e.g. coding over the phone), or you didn't prepare thoroughly enough as an interviewer added to the probable unpreparedness of the interviewee (this chronic unpreparedness is endemic in our industry and deserves a post of it's own). Sounds like the same kind of issues that cause software projects to go off the rails :). My point is, it is not necessarily the fact that the candidate is crappy it could be that you're just doing it wrong.

Just Because It Makes Us Feel Good Doesn't Make It True

As I was thinking about all this stuff I found myself referring to the X out of Y "statistics" as "feel-good numbers" because they make us all feel good about ourselves. I mean, it's pretty sad for the 99 out of 100 poor schlubs, but not you and me – we are coding ninjas. How does it feel to be special :)? Somehow though I don't reckon there are 99 working programmers sitting there reading those posts thinking "…yeah I am a bit of a failure, I wish I was one of those 1 in a 100 dudes". As a decent programmer, look around yourself. Can you really honestly say the vast majority of the developers you're working with have trouble with loops or basic arithmetic? If you can, I fail to see how your company can produce any kind of working software and why are you hanging around that place anyway, it surely is not healthy for your career not to mention your sanity.

If you've read anything I've written before, you know that I am not one to shy away from a generalisation, but in this case I believe it gives a skewed picture that needlessly makes the whole industry look bad. There is no denying that lack of skill can be a problem in software, but then again this is one of the few professional disciplines where you can read a book and "wham bam thank you ma'am", you're a programmer, or at least think that you are (and might even be able to find work if someone is desperate/stupid enough and you're smooth enough). Try doing the same thing in the medical profession or law, or accounting. This is one of the problems that is unique to IT (other industries have their own), we deal with it to the best of our ability. This issue will always make the hiring process difficult, which makes it doubly as important to think long and hard about how to attract decent people and tweak your interview process to make sure you're getting what you need out of it. And yes it will be time consuming and difficult and will make you feel like you're wasting time instead of doing "real work", but then again you know what the other side of the coin is.

Image by nitot

Related posts:

1. The Best Way To Interview A Developer
2. High Academic Results Make Better Programmers
3. How To Be A Real Elite Programmer And Make Sure Everybody Knows It

I have strong opinions regarding software consulting and consulting companies, which is probably no surprise as I seem to have a strong opinion about most things :). It's not a bad thing, makes for some lively conversation over drinks, but it is also a bit of a pain as it makes it hard to choose what to write about. I'll regale you with my serious thoughts regarding consulting in another post (don't forget to subscribe to my feed so you don't miss it) – today we'll try to maintain a bit of a lighter tone.

A little while ago I read an interesting book called "The Nomadic Developer", if you are considering going into consulting I recommend you read it (although you would appreciate it more if you've already worked in software consulting). The book has some decent advice and information for budding/existing software consultants, but the thing that really caught my eye was the humorous classification of consulting firms found at the beginning of the book. It was titled "The Seven Deadly Firms" and I thought I would share it with you for a bit of fun as well as adding one more classification of my own to bring the total up to eight. I will quote and paraphrase as necessary – here we go.

BOZO Consulting

BOZO is a place with well-intentioned people who really want to please their clients. The only downside to BOZO is it doesn't have the slightest clue about how to achieve that goal. BOZO says yes to everything: "Yes, of course we will cut the estimate." "Yes, of course, we will lower our bill rate." The idea is to get the deal at all costs. To summarize, BOZO has a sales-driven culture that lacks the ability to leverage any sort of delivery capability it accidentally hires (thought from Skorks: that would have to be one of the most buzzword driven sentences ever, how can we "leverage" that).

FEAR Consulting

Firm founded on its ability to motivate software developers by fear. Micromanagement, abuse and/or Machiavellian management techniques are the tools this firm uses to generate mundane and uninspired results for clients. The best way to describe how FEAR stays in business despite such deplorable working conditions and treatment is to reference what is known as the Stockholm Syndrome (thought from Skorks: the funny/sad thing is that any consultancy can accidentally/purposely take on aspects of FEAR Consulting in certain situation (financial/project pressures etc.)).

The Body Shop

Contracting firm that pretends to be a consultancy. Sadly, not all consultants involved have been informed of this "minor" detail. The Body Shop has zero corporate culture. No events, no infrastructure and no interaction with fellow "consultants". Working for a Body Shop you run significant risk of getting the sack after completing your first gig if there is no work immediately available (thought from Skorks: does anyone else find it funny that the body shop is an actual company, unfortunately all they do is sell skin care products, but who knows software consulting could be in their future).

CHEAP Consulting

Some firms compete on quality. CHEAP consulting isn't one of those firms. This is a great place to work as long as eating and having a roof over your head are not huge priorities for you. CHEAP Consulting firms execute entire projects using hordes of low-cost developers, rather than small numbers of good ones. Ironically, this makes their projects, after all is said and done, come in far more over budget than the firms they competed against in the first place. The main feature of CHEAP is the heavy use of the word resource. (thought from Skorks: and you know how I feel about the word resource, anyway, probably not too many of these around in the first world even cheap developers are reasonably expensive if the cost of living is high enough).

Personality Cult Consulting

The only drink that this firm has in the refrigerator is kool-aid. And if you refuse to drink it – that is, decide not to indulge in the cult of local hero worship – you might not have a future here. Critical thinking skills are not the highest priority. Frequently, a person who combines charisma with a good measure of talents finds himself able to start a consulting company that capitalizes on these traits. What starts out as a small group of like-minded people with a mission grows into a creature called PC Consulting. Discussions in such a place are rife with appeals to authority; that is, if the cult leader says something, it not only is given a lot of weight, but is treated as gospel (thought from Skorks: you know what I said about me having strong opinions, I cringe at how quickly I, and most decent developers I know, would get their ass handed to them in a place like this).

Smelzer and Melzer Accounting

Even the owners of this place, an accounting partnership, wonder how they ended up in the "computers" business. They know they make money from it but are unsure why, and frankly, they are not sure they trust these "kids" who have a lot of scary ideas. In most cases, accounting firms are run by accountants. And accountants frequently have significant issues with the way software tends to be developed. Software development methodology is chosen, based on what is perceived as predictable and developers often become the scapegoats when the expectations of predictability fail to materialize (thought from Skorks: this one is easy, Big Four anyone?).

"Push the SKU" Consulting

"Services" arm of a product company that ends up acting as a de-facto sales force for the product, while at the same time, getting paid by the hour from the client to sell…ahem, I mean… "provide independent advice". The incentive system tends to make this not the place for development of software that works independent of a particular product. Such an organization is not always a good place for software developers who have the interest of the client at heart first and foremost (thought from Skorks: does your software do X? "Sure, sure it does, it just needs some minor configuration …").

Band Of Freelancers (My Contribution)

A bunch of friends decide to form a company to build the next great product. But of course building products takes time and you have to live in the meantime, so everyone picks up some occasional consulting work to "keep the lights on". The only problem is, occasional means pretty much permanent and it is difficult to write a product while working full time on something else. So, all the "founders" keep on consulting and no product ever materializes, so the company turns into a perpetual band-of-freelancers consulting company. The real danger is that the "founders" actually do well as consultants and are able to hire more people at which point there is a real danger of this company turning into BOZO, Body Shop or Personality Cult consulting.

There you go, humorous – yes, but also rather accurate, wouldn't you agree? Of course all those are examples of potentially dysfunctional consulting companies. There are plenty of big and small consultancies (admittedly mostly smaller) that are great places to work, treat their people well and approach their software development with skill and wisdom. The thing to be aware of is that no matter how good a consulting company is, most will exhibit at least some aspects of the above 8 at one point or another. The trick is to know whether or not, it is just a bad patch – soon corrected and forgotten – or whether it is becoming more of a permanent situation. Anyways, go check out the book if you want to get the full descriptions as well as tips for recognising if you might, infact, be working for one of these companies. If you do work for a software consultancy, how would you classify the company you work for? Does it by any chance fall into one of the 8 categories above?

On an even lighter note, is it just me or does anyone else ever misspell the word consulting as consluting, can be a little embarrassing if you do it in any kind of semi-official document. The other one is conlusting which also works but is not quite as good :).

Images by orkboi and Venn Diagram

Related posts:

1. Software As A Destination vs Software As A Journey
2. Fitness for Software Developers (and Other IT Professionals)
3. If Software Development Was Like Medicine: Part 1

A little while ago I started thinking about math. You see, I've been writing software for quite a few years now and to be totally honest, I haven't yet found a need for math in my work. There has been plenty of new stuff I've had to learn/master, languages, frameworks, tools, processes, communication skills and library upon library of stuff to do just about anything you can think of; math hasn't been useful for any of it. Of course this is not surprising, the vast majority of the work I've been doing has been CRUD in one form or another, that's the vast majority of the work most developers do in these interweb times of ours. You do consulting – you mostly build websites, you work for a large corporates – mostly build websites, you freelance – you mostly build websites. I am well aware that I am generalising quite a bit, but do bear with me, I am going somewhere.

Eventually you get a little tired of it, as I did. Don't get me wrong it can be fun and challenging work, providing opportunities to solve problems and interact with interesting people – I am happy to do it during work hours. But the thought of building yet more websites in my personal time has somewhat lost its luster – you begin to look for something more interesting/cool/fun, as – once again – I did. Some people gravitate to front-end technologies and graphical things – visual feedback is seductive – I was not one of them (I love a nice front-end as much as the next guy, but it doesn't really excite me), which is why, when I was confronted with some search-related problems I decided to dig a little further. And this brings me back to the start of this story because as soon as I grabbed the first metaphorical shovel-full of search, I ran smack-bang into some math and realized exactly just how far my skills have deteriorated. Unlike riding a bike – you certainly do forget (although I haven't ridden a bike in years so maybe you forget that too :)).

Broadening Horizons

Learning a little bit about search exposed me to all sorts of interesting software-y and computer science-y related things/problems (machine learning, natural language processing, algorithm analysis etc.) and now everywhere I turn I see math and so feel my lack of skills all the more keenly. I've come to the realization that you need a decent level of math skill if you want to do cool and interesting things with computers. Here are some more in addition to the ones I already mentioned – cryptography, games AI, compression, genetic algorithms, 3d graphics etc. You need math to understand the theory behind these fields which you can then apply if you want to write those libraries and tools that I was talking about – rather than just use them (be a producer rather than just a consumer – to borrow an OS metaphor :)). And even if you don't want to write any libraries, it makes for a much more satisfying time building software, when you really understand what makes things tick, rather than just plugging them in and hoping they do whatever the hell they're supposed to.

The majority of developers will tell you that they've never needed math for their work (like I did a couple of paragraphs above :)), but after musing on it for a while, I had a though. What we might have here is a reverse Maslow's hammer problem. You know the one – when you have a hammer, everything looks like a nail. It is a metaphor for using a favourite tool even when it may not be best for the job at hand. Math is our hammer in reverse. We know the hammer exists but don't quite know how to use it, so even when we meet a problem where our hammer would be the perfect tool, we never give it serious consideration. The screwdriver was good enough for my granddaddy, it was good enough for my daddy and it is good enough for me, who needs a hammer anyway? The trick with math is – people are afraid of it – even most programmers, you'd think we wouldn't be, but we are. So, we turn our words into a self-fulfilling prophecy. It's not that I don't need math for my work it's just that I don't really know it and even if I do, I don't know how to apply it. So I get by without it and when you make-do without something for long enough, after a while you don't even notice it's missing and so need it even less – self-fulfilling prophecy.

Here is some food for thought about something close to all our hearts – learning new skills. As a developer in the corporate world, you strive to be a generalizing specialist (read this book if you don't know what I am talking about). You try to be decent at most things and really good at some. But what do you specialize in? Normally people choose a framework or two and a programming language and go with that, which is fine and worthwhile. But consider the fact that frameworks and to a lesser extent languages have a limited shelf life. If you're building a career on being a Hibernate, Rails or Struts expert (the struts guys should really be getting worried now :)), you will have to rinse and repeat all over again in a few years when new frameworks come along to supersede the current flavour of the month. So is it really the best investment of your time – maybe, but then again maybe not. Math, on the other hand is not going away any time soon. Everything we do in our field is built upon solid mathematical principles at its root (algorithms and data structures being a case in point), so time spent keeping up your math skills is arguably never wasted. And it, once again, comes down to really understanding something rather than just using it by rote – math can help you understand everything you do more deeply, when it comes to computers. Infact, as Steve Yegge said, what we do as programmers is so much like math we don't even realise it.

What/Who Makes A Difference

You don't believe me, then consider this. Most of the people who are almost universally respected  in our field as great programmers are also great mathematicians. I am talking people like Donald Knuth, Edsger W. Dijkstra, Noam Chomsky, Peter Norvig. But then again these guys weren’t really developers, they were computer scientists, so it doesn't really count right? I guess, but then again, maybe we shouldn't really talk until our output in pure lines of code even begins to approach 10% of what these people have produced. Of course, you can be successful and famous without being a boffin, everyone has heard of Gavin King or DHH. That's kinda true (although it's an arguable point whether or not many people have heard of Gavin or DHH outside their respective niches), but "heard of" and universally respected are different things, about as different as creating a framework and significantly advancing the sum-total of human knowledge in your field (don't get me wrong, I respect Gavin And David, they've done a hell of a lot more than I have, but that doesn't make what I said any less of a fact). How is all of this relevant? I dunno, it probably isn't, but I thought I'd throw it in there anyway since we're being introspective and all.

The world is getting filled up with data, there is more and more of it every day and whereas before we had the luxury of working with relatively small sets of it, these days the software we write must operate efficiently with enormous data sets. This is increasingly true even in the corporate world. What this means is that you will be less and less likely to be able to just "kick things off" to see how they run, because with the amount of data you'll be dealing with it will just grind to a halt unless you're smart about it. My prediction is that algorithm analysis will become increasingly important for the lay-programmer, not that it wasn't before, but it will become more so. And what do you need to be a decent algorist – you guessed it, some math skills.

So, what about me? Well, I've decided to build up/revive my math skills a little bit at a time, there are still plenty of books to read and code to write, but I will try to devote a little bit of my time to math at least once in a while, because like exercise, a little bit once in a while, is better than nothing (to quote Steve Yegge yet again). Of course I have a bit of an ace up my sleeve when it comes to math, which is good for me, but luckily with this blog, we might all benefit (I know you're curious, I'll tell you about it soon :)).

Where Do You See Yourself In 5 Years

So, is all this math gonna be good for anything? It's hard to say in advance, I am pretty happy with where I am at right now and so might you be, but it's all about potential. End of the day, if you're a developer in the corporate world you don't really need any math. If you're happy to go your entire career doing enterprise CRUD apps during work hours and paragliding or wakeboarding (or whatever trendy 'sport' the geeky in-crowd is into these days) during your off time then by all means, invest some more time into Spring or Hibernate or Visual Studio or whatever. It will not really limit your potential in that particular niche; you can become extremely valuable – even sought after. But if you strive for diversity in your career and want to have the ability to try your hand at almost any activity that involves code, from information retrieval to Linux kernel hacking. In short if you want to be a perfect mix of developer, programmer and computer scientist, you have to make sure you math skills are up to scratch (and hell, you can still go wakeboarding if you really want :)). Long story short, if you grok math, there are no doors that are closed to you in the software development field, if you don't – it's going to be all CRUD (pun intended)!

Images by Beni Ishaque Luthor, Scott Laird and arturodonate

Related posts:

1. The Difference Between A Developer, A Programmer And A Computer Scientist
2. The Greatest Developer Fallacy Or The Wisest Words You’ll Ever Hear?
3. The Best Way To Interview A Developer

I saw a great post this afternoon by Rob Walling of Software By Rob, where he talks about Competing With Open Source. His main point was the fact that while there are some great open source projects, most open source software suffers from usability, support and documentation issues (amongst other things) and this is where commercial software can have the upper edge. While I could see the point he was trying make, I found that over the last few years I have developed pretty much the opposite view. Of course, it all depends on the segment of the software market that you’re looking at (enterprise, mass market etc.), but lets start with the big ones.

Enterprise Software Development

If you’ve done enterprise software development for any length of time you would have heard of or used some of the biggies (note I have predominantly been doing Java development):

• Websphere
• Weblogic
• Oracle (Database)
• etc.

All commercial, all owned by big companies, all established players in the market place with years of development effort put into them. So, let us examine these against some of the more pertinent points:

• Easy of installation – I don’t know about you, but I would say all three that I mentioned above get a massive fail for this one (if you disagree please, I’d love to hear you explain how all those are easy to install)
• Great documentation – Sure there is a LOT of documentation for all of them, the value of it however is marginal. Most of the information is probably there, finding what you need is a whole other story. Another big fail.
• Usability – yeah all right, they are usable (sort of), but they have nothing over their open source counterparts in this department. Maybe not a fail, but certainly far from brilliant.
• Support – well, it is certainly there somewhere. You know it exists, getting your hands on some of this support is a whole other matter. Even if you do manage to get through the layers of bureaucracy and get a hold of someone who knows what they are talking about, it gets you precisely nowhere if you found a bug with the software. It’s not as if IBM will be rushing out a new Websphere release just to fix your little issue any time soon and even if they did, let’s see you easily upgrade.

Notice that I only named 3 big commercial products, that’s not by accident. Undoubtedly there are hundreds of others used in enterprise software development, but the number pales in comparison to the sheer amount of open source libraries and products that are in general circulation. Lets see how many I can list off the top of my head in 5 seconds:

• Linux
• Open Office
• Java
• Eclipse (IDE)
• NetBeans (IDE)
• Ruby
• Rails
• Mongrel
• Spring
• Hibernate
• Apache (web server)
• Ant
• Maven
• Ivy
• Hudson (CI)
• GWT
• Struts
• Anything Apache Commons
• Bugzilla
• Quartz
• Tomcat
• XPlanner
• Groovy
• Scala
• Acegi (Security)
• JUnit

Pretty impressive, and that was the very tip of the iceberg. And the interesting thing about most of those that I listed is the fact that they have decent documentation (for the most part), are reasonably easy to use, are reasonably easy to install (if you know what you’re doing, at least a little) and have great support not only from the developers but from the community. Which is the truly awesome thing about open source products, even the smallest ones will often have a community form around them, a community that is usually vociferous, helpful and that includes developers who actually wrote the product. This is something that even the biggest commercial products usually lack – a helpful community. And consider that with open source software if you do find a bug, you sometimes actually have a chance of getting the products fixed and a new version released pretty much just for you. Granted, this will never happen with the bigger open source products but at least you have a chance and at the end of the day, you can always just patch it yourself and build your own copy (and submit your fix to the developers) because the source code is right there (difficult yes, but at least possible). And to get back to documentation, if you really think about it, open source software is the best documented software of all because you always have the god’s own truth to have a look at – the code. If you don’t understand the doco for an open source product, you can read the code as a last resort; for a commercial product – good luck!

Software For The Masses

Of course we have so far been happily ensconced in developer land, but what about the average Joe Bloggs out there, what’s the landscape like for him/her (Joanne Bloggs :)) when it comes to open source vs. commercial. The field is a little more even here, Joe is not going to read the code, he pretty much wants his software to just work and you know what more and more often these days open source software just does. Sure, commercial products probably have the majority of the market at the moment when it comes to mass-market software, but I would guess that their market share is shrinking. Open source developers have learned that they need to build for the consumer and not for other developers and they’re slowly starting to do so. And the abundance of open source tools and frameworks is making this easier and easier for them.

The only commercial software I have on my machine is … well the operating system (I am a gamer so Windows is a must), and even there my machine is dual boot :). Aside from that, everything else I need to do with my machine is done by free or open source software:

• Firefox
• VLC media player
• 7-Zip
• Open Office
• WinSCP
• Putty
• Windows Live Writer (I am using this right now :))
• Notepad++
• Ruby
• ImgBurn
• Foxit Reader
• and many others

All of these were easy to install (they just worked), intuitive to use and have decent documentation as far as I know (never had to look at any). And as far as support goes, well once again we have the community which is more passionate and helpful around all of the apps that I listed than around most commercial products.

But, I am a developer, I hear you say, I know how to use and tweak all this stuff, surely Joe Bloggs would find things much tougher. Well, to that I have this to say, the only commercial software my parents have on their machine is … once again the operating system, and only because I didn’t want to confuse them too much (they are not developers :)). They’ve been using it fine and I haven’t heard any complaints about lack of documentation, support or usability, the machine does everything they want it to do, what else do you need?

This day and age commercial software is going to find it harder and harder to compete as the world is getting more connected and more savvy. Sure they can make the documentation great (which historically has not been the case), but so can open source software, and the 80/20 rule applies where it all becomes moot after a certain point. Commercial can be more useable, but once again 80/20 rule and you really need to innovate hard to stand out. Easy of installation is getting tougher and tougher to compete on as open source tools get more savvy about this one. Finally support is left, and honestly, no commercial software company has the same type of flexibility to offer support as a great open source product with a strong community. The only thing that you end up competing on is price and ‘nothing’, is going to beat ‘something’ every time.

Image by BL1961

Related posts:

1. Java and .Net Taking On Contenders And Winning
2. An Interview Question That Prints Out Its Own Source Code (In Ruby)
3. Rules Of Standup – You Don’t Need To Justify Your Own Existence

Design sessions is one practice that most agile teams will find themselves engaging in from time to time. For some teams it will be completely informal (just get everyone together for 10-15 mins whenever you think it is warranted), for others it becomes more of a ritual where most non-trivial features get a once-over in a design session before implementation proceeds.  There are many benefits to having regular design sessions with your team mates:

• an opportunity to share knowledge about a particular area of the system with the whole team
• an opportunity to validate design decisions before implementation gets too far
• promotes collective ownership of code as everyone has some stake in most non-trivial design decisions
• gives an opportunity to brainstorm (brainstorming is not used nearly enough)
• an opportunity to identify areas that are potential refactoring candidates
• gets everyone more personally invested in the solution
• gives people a break from cutting code and gives them an opportunity to engage in an alternative but still useful activity
• an opportunity for the team to bond and ‘gel’ further

At least those are all the benefits that a design session SHOULD provide, but more often than not the potential of design session goes sadly under-utilised by many teams. Any sort of design session will provide some of the above benefits to some degree, however our goal as software developers and agile practitioners should always be to get the maximum benefits from all the practices we employ. So is there anything we can do to ensure we get the most out of a design session?

A Typical Design Session Scenario

A typical design session is a pretty informal affair and usually occurs when a pair would like some input from the rest of the team into the best way to implement the feature they are currently working on. When a pair calls a design session the rest of the team gathers in one place (usually in front of a whiteboard) where the team would proceed to outline the problem they are looking at as well as potential solutions that they have come up with. The pair running the session would normally use the whiteboard as a visual aid to help represent the problem and their solution (or solutions).

Ideally the rest of the team would have some insight into the problem and would offer better solutions or critique and improve the solutions that the pair running the design session has proposed. After some back-and-forth a solution that most people are happy with would emerge and everyone goes back to what they were doing before while the pair that called the session proceeds with the implementation.

While there is nothing overtly wrong with this scenario (and many teams would do well to even have that as one of the practices they follow), I believe there are many opportunities lost when a design session similar to the above occurs:

• not everyone is an extrovert and since no particular effort was made to engage the more introverted people their knowledge/ideas may go unheard/unused
• it takes a while to switch mental gears, since no particular effort is made to snap everyone out of the mode they’re thinking in, interesting ideas/solutions may not occur to some people until long after the design session is over
• only visual clues (whiteboard) and audio (verbal explanations) are used to represent the problem and the solution, many people work better with tactile clues (use physical objects to represent the problem), or by seeing themselves as part of a larger abstraction (acting it out)
• by presenting a solutions at the start, potential creative solutions are stifled as it puts the team into an analytical mode (analysing the presented solutions) rather than creative mode (coming up with innovative solutions)
• design sessions can sometimes be a serious affair and so an opportunity for “play” (while still doing something productive) is lost (this is a fluffy one but worth a mention I think), a design session can be light-hearted while still providing all the value

A Much Better Design Session

A pair calls a design session in very similar fashion to the above. However before jumping into the problem, call for someone from the team a tell a joke or tell one themselves. It is unexpected in a work environment and will force people  to snap out of thinking about what they were just doing, it is also a playful start to the discussion which I think is never a bad thing as it gets everyone more relaxed. This also has the potential to turn into a design session ritual that everyone on the team can look forward to which will be something they share that brings the team closer together.

Before we draw the problem on the whiteboard, we explain it using just words and then we try and represent the problem using a tactile abstraction (i.e. build what you mean using lego blocks or chess pieces or anything that people can move and touch). This gets people thinking about the problem domain before you draw it i.e. forces them to think about it before seeing it in a familiar medium. The other thing you can do at this point, either before or after drawing, is to act the problem out using people as objects in the system. Many people learn and appreciate problems a lot better by actually doing rather than seeing or hearing about it. As an added benefit, this provides another opportunity for play, gets the less extroverted people more relaxed in a fun and friendly atmosphere and gets everyone primed to participate.

Do not present potential solutions you have come up with to the team, get the team to brainstorm first and come up with solutions of their own. Chances are they will probably come up with something similar to what you had, but they will have a lot more stake in it having thought it up rather than just validated the solution that the pair that called the session contributes. By not forcing your potential solution on the team you also have a much better chance of the team coming up with something truly innovative that you haven’t thought of (remember it’s analytical thinking – validating a solution, vs creative thinking – brainstorming a solution). Of course if noone can come up with anything interesting present your solution, you don’t want to get stuck in design paralysis.

At this point everyone discusses and agrees on a way forward and the design session is concluded. The difference is:

• the team was a lot more engaged
• everyone had fun
• people had a break from the routine
• everyone was heard (there were no chickens in the design session, only pigs)
• everyone goes back to their work feeling a lot more fulfilled
• the team has bonded together that little bit more

Agile Chickens And Pigs

At The End Of The Day

I have very strong opinions on design sessions. I believe they are an extremely valuable tool in the arsenal of any agile team. However I also believe that unless you can fully engage everyone on the team (who is present at the design session) and get everyone thinking creatively (and potentially in a different mode than they would normally) you’re wasting a large part of the benefit that a design session can provide. Do you use design sessions in your team (if so do you use them as fully as you can) and do you get a lot of value out of them? I’d love to hear what other people have to say on the matter.

Related posts:

1. Effective vs Ineffective Pair Programming
2. Who Deserves The Credit For Software Craftsmanship and Great Design?
3. Why Your Developers Don’t Want To Swap Pairs – Practical Agility

Pair programming has always been one of the more controversial agile practices. Mostly because it is damn hard to sell to management (at least the unenlightened kind of management), we’ve all heard the old “double the cost for the same work” excuse. To those in-the-know that excuse is patent nonsense, those who’ve done it are well aware of the benefits that it brings even if they do sometimes find it hard to verbalise just exactly what those benefits are.  Pairing brings all sorts of benefits:

• organic code review
• less bugs, which means less maintenance effort
• detecting problems early
• more focused effort (harder to procrastinate when person next to you)
• etc.

The most important benefit in my opinion is the fact that pairing is highly conducive to organic knowledge transfer (“pairing is knowledge sharing” for the poet in you). I believe this is key since in a large system there is literally no other way to do this well.

It is however interesting to ask exactly why pair programming brings those benefits and this would directly lead us to ask if there are any situations where pair programming can be less effective and what we can do to mitigate that.

What’s So Good About Pairing And Why It Works

The  reason I think pairing works so well is the fact that the “driver” and the “navigator” are mentally in completely different places. Andy Hunt explains this really well in his “Pragmatic Thinking & Learning – Refactor Your Wetware” book. The driver is focused on the nitty-gritty of the code, his mind is in its analytical mode (his left brain is more engaged) and he is more focused on the “small picture”. The navigator on the other is more focused on the bigger picture and due to the fact that he is not actually busy driving his mind is in its more intuitive mode (his right brain is more engaged). This means that the navigator is more able to see patterns and abstractions that the more analytically engaged driver will tend to miss.

However in order to be able to see the patterns and notice the abstractions, good system knowledge is invaluable (and the best way to gain it is through pairing so this is sort-of cyclical), which brings us to 4 situations where pairing can be either less or more effective.

The 4 Pairing Situations

The 4 situations are as follows:

• the driver and the navigator both know the system/area well
• the driver knows the system/area well, while the navigator does not
• the navigator knows the system well while the driver does not
• both the driver and the navigator do not know the system/area well

Driver and the navigator both know the system/area well

This is the ideal situation (obviously), and there is no need to say to much about this, when pairing having both people well versed in the system will ensure maximum effectiveness.

Driver knows the system/area well, while the navigator does not

This is a lot less ideal, in this case the person with the most knowledge of how the system works is in their analytical mode and is a lot less able to see the bigger picture and pick up on the appropriate patterns and abstractions. More than that, since as the driver they are focused on the task at hand and are actively busy/engaged they are potentially less able to share their expertise with their partner. The navigator is also extremely hampered by their lack of system knowledge, not only are they limited in their ability to help the driver, but they will also tend to feel frustrated and unfulfilled.

Navigator knows the system well while the driver does not

This situation is a lot better. In this case the person with less system knowledge is fully engaged as the driver, the navigator on the other hand is able to guide the pairing effort and is still able to see the code from a right-brain perspective. The navigator is also able to maintain a stream of commentary about the system for the driver to absorb. The downside here may be that the work proceeds somewhat slower due to the lack of system knowledge on the part of the driver. This can however be mitigated by discussion between the members of the pair before proceeding to do the next step in the work.

The driver and the navigator do not know the system/area well

From the perspective of getting some work done this is the worst situation to find yourself in. It can however be quite a lot of fun to dig through code you don’t know, as well as find and recover from mistakes together. The danger here is due to the fact that neither person is potentially able to appreciate the bigger picture -  the quality of the work can suffer and it can be inconsistent with the rest of the code in the system.

It is difficult to mitigate lack of system knowledge, there is always a significant amount of time and effort involved when the system is of reasonable size. I believe there are 2 ways to ensure that pairing brings benefit no matter what the situation:

• the person with the most system knowledge should spend the majority of their time being the navigator rather than the driver, in this way they can bring the most benefit to the system as well as to their partner
• both members of a pair need to ensure that they are constantly proactive both in learning and in teaching

Do you think there are other ways to make sure that our pairing efforts are always optimally successful? Feel free to leave a comment and let me know.

Related posts:

1. The Real Measure Of Code Quality
2. Why Your Developers Don’t Want To Swap Pairs – Practical Agility
3. How To Get The Most Out Of Your Design Sessions

I love reading fantasy, I’ve even written about some of my favourite fantasy series on this blog. One of the things that I have always found interesting about fantasy literature (besides unworkable economies and unsustainable population densities – I tend to over-analyse when I read :)) was how they come up with the names for all the characters. Large fantasy series often contain hundreds of characters – that’s a lot of names. This line of though naturally led me to think of what I would do if I ever needed to make up a bunch of names and being the software developer that I am the answer was naturally – get my computer to make up the names for me.

If you do a search around the web for name generators you get quite a few results, unfortunately most of those don’t tell you how they do what they do and even that is besides the point since I wasn’t really happy with the results that most of these name generators produce. Either the results are way too random (how about 6 consonants in a row) or they are not random enough with clear traces of human intervention (i.e. choosing from a list of pre-made names). Then I found Chris Pounds excellent name generator page. One of the things that he has on this page is his language confluxer (lc) script so for my first attempt at writing a name generator I decided to basically take his script and clean it up a little bit. There were two reasons for this:

• he uses a pretty clever algorithm for his name generator, it is completely data driven and is therefore able to avoid the 6 consonants/vowels in a row issue while producing output that sounds similar to the data it is based on
• it was a yucky Perl script and nobody wants to work with that (except Perl programmers), so I felt it was my duty to make it a little bit nicer and since I’ve been playing around with Ruby lately, well you get the picture :)

The Name Generator Algorithm

As I said the script is completely data driven in that it takes a list of words (names in our case) as input and uses these to produce a bunch of randomised names that hopefully sound similar to the original input. It does the following:

• produces a list of starting letter pairs from the input data (all our names will start with one of these pairs)
• produces a map of which letters can follow which other letters based on the input data
• generates words/names by randomly selecting a starting pair and then appending to the word by randomly choosing a letter from the map based on what the last letter in our new word currently is
• this continues until the word length falls into a particular range (this range is hard-coded in the script)

There are a few more little twists that make this whole thing function but that is the essence of the algorithm.

Faithful Perl-to-Ruby Conversion

So first thing I did was to take the Perl script and do a direct conversion into Ruby, here is what I got:

require 'getoptlong'
 
data_file = 'data.txt'
words_to_generate = 10
 
min_length = 3
max_length = 9
 
opts = GetoptLong.new(
  ["--datafile", "-d", GetoptLong::OPTIONAL_ARGUMENT],
  ["--number-of-words", "-n", GetoptLong::OPTIONAL_ARGUMENT]
)
 
opts.each do |opt, arg|
  case opt
  when '--datafile'
    data_file = arg
  when '--number-of-words'
    words_to_generate = arg
  end
end
 
start_pairs = []
follower_letters = Hash.new('')
 
File.open(data_file, 'r') do |file|
  chars = file.read.chomp.downcase.gsub(/\s/, ' ').chars.to_a
  chars.push(chars[0], chars[1])
  (chars.length-2).times do |i|
    if chars[i] =~ /\s/
      start_pairs.push(chars[i+1, 2].join)
    end
    follower_letters[chars[i, 2].join]=follower_letters[chars[i,2].join]+chars[i+2,1].join
  end
end
 
def generate_word(word, follower_letters, min_length)
  last_pair = word[-2, 2]
  letter = follower_letters[last_pair].slice(rand(follower_letters[last_pair].length), 1)
  if word =~ /\s$/
    return word unless word.length <= min_length
    return generate_word(word[-1, 1]+letter, follower_letters, min_length)
  else
    word = word.gsub(/^\s/, '')
    return generate_word(word+letter, follower_letters, min_length)
  end
end
 
words_to_generate.times do |i|
  puts generate_word(start_pairs[rand start_pairs.length], follower_letters, min_length)[0, max_length].capitalize
end

At this point I had a bit of a shock at how eerily similar the Ruby version of the script looks compared to the Perl version (*shudders*). Anyways, you can just take the above script put it into a file and run it, you’ll need to give it a data file (here is the one I used).

Cleaning Up The Basic Name Generator

The problems with the above script are:

• it is not self-documenting
• it is hard to test
• it is hard to extend

Anyways, I decided to make it a little bit nicer and easier to play around with by breaking it up into a couple of classes (in the interest of object orientation and stuff):

• name_generator_main.rb – the script entry point
• NameGenerator – concerned with name generation (as you might expect)
• DataHandler – concerned with reading the input data and producing the maps and arrays on which the NameGenerator relies
• ArgumentParser – concerned with dealing with the command line arguments

You can download all of it here.

Now the main script looks much cleaner and you know exactly what’s happening just by reading it:

require 'argument_parser'
require 'data_handler'
require 'name_generator'
 
argument_parser = ArgumentParser.new
argument_parser.parse_arguments
data_handler = DataHandler.new
data_handler.read_data_file(argument_parser.data_file)
name_generator = NameGenerator.new(data_handler.follower_letters)
names = name_generator.generate_names(argument_parser.words_to_generate, data_handler.start_pairs)
names.each {|name| puts name}

This produces output similar to the following:

Jamin
Luce
Jevon
Fredy
Hamilinis
Emmano
Shamarcul
Gagaedric
Jary
Raelis

That’s pretty damn good for a random name generator. The best part of it, since it is completely data driven, if you change the input data you completely alter the output. So if you pass in a file with a bunch of French names, you will get French-sounding random names etc. Try it yourself!

Related posts:

1. How To Write A Simple Web Crawler In Ruby
2. How To Quickly Generate A Large File On The Command Line (With Linux)
3. Serializing (And Deserializing) Objects With Ruby

I was recently upgrading a couple of Ubuntu machines to the latest and greatest everything. It’s good to be up-to-date makes me feel like a no-nonsense, can-do developer :). Anyways one of the latest and greatest things that Ubuntu pulled in for me was the latest java 6 (JDK 1.6.0_14). All of a sudden my build started failing with strange coverage errors – I hate it when that happens. After looking around for a bit I found that there was a Cobertura issue with java 1.6.0_14, this one. So I though I’d try and downgrade Java 6 to the previous version (who needs to be fully up-to-date anyway, that stuff is for the birds, the real hardcore developers use the penultimate version, yeah!).

This of course was easier said than done, Ubuntu doesn’t really like it when you try to downgrade stuff. I thought that if I could obtain, or create, a debian package with the version of java that I was after I might just be able to manually install that one (yeah that might work). I was wrong, I did get my hands on the debian package that I needed, but Ubuntu spewed out some gaff about dependencies and … long story short, it didn’t work. Of course I could always forgo the use of the package manager and just manually install java and set up the PATH and JAVA_HOME and so forth but that would make me feel a little unclean so I thought I’d persist and do things the easy hard way.

Eventually (after searching around for ages and eating 2 pieces of candy – Vicks VapoDrops – good for the throat) I found a nice Ubuntu forum thread about how to downgrade a package (this one), so here is the summarised version of how to downgrade a Ubuntu package – more specifically my java 6.

Firstly, we need to find what lower versions of our package are available to us, we use the following command:

apt-cache showpkg sun-java6-jdk

This will produce output similar to the following:


Package: sun-java6-jdk
Versions:
6-14-0ubuntu1.9.04 (/var/lib/apt/lists/security.ubuntu.com_ubuntu_dists_jaunty-proposed_multiverse_binary-amd64_Packages) (/var/lib/dpkg/status)
Description Language:
File: /var/lib/apt/lists/security.ubuntu.com_ubuntu_dists_jaunty-proposed_multiverse_binary-amd64_Packages
MD5: cb47d4c49fa7317c472613b7010ef9d8
6-13-1 (/var/lib/apt/lists/au.archive.ubuntu.com_ubuntu_dists_jaunty_multiverse_binary-amd64_Packages)
Description Language:
File: /var/lib/apt/lists/au.archive.ubuntu.com_ubuntu_dists_jaunty_multiverse_binary-amd64_Packages
MD5: cb47d4c49fa7317c472613b7010ef9d8
Reverse Depends:
sun-java6-source,sun-java6-jdk 6-14-0ubuntu1.9.04
sun-java6-javadb,sun-java6-jdk 6-14-0ubuntu1.9.04
sun-java6-demo,sun-java6-jdk
sun-java6-demo,sun-java6-jdk 6-14-0ubuntu1.9.04
libnb-java2-java,sun-java6-jdk
libnb-java2-java,sun-java6-jdk
sun-java6-source,sun-java6-jdk 6-13-1
sun-java6-javadb,sun-java6-jdk 6-13-1
sun-java6-demo,sun-java6-jdk
sun-java6-demo,sun-java6-jdk 6-13-1
glassfishv2-bin,sun-java6-jdk
glassfishv2,sun-java6-jdk
Dependencies:
6-14-0ubuntu1.9.04 - sun-java6-bin (5 6-14-0ubuntu1.9.04) libc6 (0 (null)) libx11-6 (0 (null)) debconf (18 0.5) debconf-2.0 (0 (null)) sun-java6-demo (0 (null)) sun-java6-doc (0 (null)) sun-java6-source (0 (null))
6-13-1 - sun-java6-bin (5 6-13-1) libc6 (0 (null)) libx11-6 (0 (null)) debconf (18 0.5) debconf-2.0 (0 (null)) sun-java6-demo (0 (null)) sun-java6-doc (0 (null)) sun-java6-source (0 (null))
Provides:
6-14-0ubuntu1.9.04 - java6-sdk java5-sdk java2-sdk java2-compiler java-sdk java-compiler
6-13-1 - java6-sdk java5-sdk java2-sdk java2-compiler java-sdk java-compiler
Reverse Provides:


There are two versions available in the repository. As we can see the java version we are looking for (6-13-1) is here. However it is worth noting that had we wanted to downgrade several versions back, we would be out of luck as older versions are no longer in the repository.

Now that we see the version that we want we need to do the following to downgrade:

sudo aptitude install sun-java6-jdk=6-13-1

This will produce something along the lines of:


Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
The following packages are BROKEN:
sun-java6-jdk
0 packages upgraded, 0 newly installed, 1 downgraded, 0 to remove and 2 not upgraded.
Need to get 17.7MB of archives. After unpacking 1925kB will be freed.
The following packages have unmet dependencies:
sun-java6-jdk: Depends: sun-java6-bin (= 6-13-1) but 6-14-0ubuntu1.9.04 is installed.
The following actions will resolve these dependencies:
Remove the following packages:
sun-java6-fonts
sun-java6-plugin
Downgrade the following packages:
sun-java6-bin [6-14-0ubuntu1.9.04 (jaunty-proposed, now) -> 6-13-1 (jaunty)]
sun-java6-jre [6-14-0ubuntu1.9.04 (jaunty-proposed, now) -> 6-13-1 (jaunty)]
Score is 188
Accept this solution? [Y/n/q/?] Y
The following packages will be DOWNGRADED:
sun-java6-bin sun-java6-jdk sun-java6-jre
The following packages will be REMOVED:
sun-java6-fonts{a} sun-java6-plugin{a}
0 packages upgraded, 0 newly installed, 3 downgraded, 2 to remove and 2 not upgraded.
Need to get 50.7MB of archives. After unpacking 4096kB will be freed.
Do you want to continue? [Y/n/?] Y


If we now run:

java -version

We get:

java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed mode)

Which is the downgraded java that we were after, sweet!

Related posts:

1. What Everybody Should Know About Installing And Using Java On Ubuntu
2. Partitioning Your Hard Drive During A Linux Install
3. Java and .Net Taking On Contenders And Winning

A few days ago I was asked where I thought Agile adoption was at right now. After giving a long and no-doubt confusing answer I thought I would write it up as well. After all if I had to confuse one person I might as well confuse and bore a whole lot of others while I am at it. Therefore, here is where I think the agile world is right now (oh and by the way, the adoption rates below are my own opinion and are based purely on keeping a ‘finger on the pulse’ not any statistical evidence):

The SCRUM People

Scrum is by far the most well known and widely adopted process right now.  Scrum is becoming almost synonymous with agile with some of the biggest names (Ken Schwaber, Jeff Sutherland etc.) in the agile world pushing scrum as their process of choice. Scrum is one of the few agile process that has a certification path (as offered by the Scrum Alliance) and this is probably one of the main reasons why Scrum has become the most widely accepted agile process. Of course the fact that Scrum bundles the majority of XP practices into itself probably doesn’t hurt it much either, infact Scrum couldn’t exist without XP practices.

Adoption Rate: ~ 10%

The XP People

XP is probably the original Agile process if anything is. It is pretty much a set of common sense practices to make software development better. Many of the practices support each other but there is no common framework that ties them all together. This is probably why many management-type people don’t really like it much it makes them feel useless and unnecessary. But since we still have to work with all sorts of people including management-types, just about every single other agile process tries to wrap XP in just such a framework (see Scrum above).

Adoption Rate: ~ 7%

The Other SCRUM People

Of course when something starts to enjoy a bit of success and someone starts making a good living from it, other people get envious of that tasty pie and want to get themselves a piece. These people are disillusioned or simply want to make some cash without being bound by someone elses rules. This is what is happening to Scrum right now. With Scrum becoming more and more successful a lot of people come out all critical about how regular Scrum is not quite right and how they have a much better Scrum (Is Scrum Failing Us?). The Scrum certifications are all bad and how they have bigger and better certifications (Scrum Master Certification By Net Objectives).

Adoption Rate: ~ 2%

The Lean People

Then of course there are people who really want to be different so they come up with a whole different process and even give it a different name and since these people might even have a name within the community their ideas gain instant recognition (http://www.poppendieck.com/). No matter that the ideas they espouse were always part of the Agile spirit, just the execution may have been faulty (agile doesn’t kill agile, people kill agile). But hell, why not, let’s re-brand – it worked for SOA.  The point is to create a niche, so that more consulting can be offered and more books can be written and if we happen to help people write better software at the same time, well that’s just an extra benefit.

Adoption Rate: ~ 3%

The People Who Are Over It

Inevitably there are people who are sick of it. After all Agile has been around for a decade or more now, there are bound to be people who just can’t be bothered any more. I wrote about it before it’s called post-agilism. Sometimes you just get sick of arguing about process. You just want to write good software and deliver value. You know that you can’t please everyone, you know the good practices and the bad ones. You try to maximize the good ones and minimize the bad ones and do as good a job as you can under the circumstances.

Adoption Rate: ~ 8%

The Clueless People

For those of us who are into the whole Agile thing it might sometimes seem like the whole world is jumping on the Agile bandwagon. After all most of the job ads these days list Agile as a mandatory skills and everyone seems to be talking about it. Nothing could be further from the truth. The vast majority of people have absolutely no idea, they’ve heard of this Agile thing but they don’t know what the hell it’s all about and they don’t really care. They might be happy to bandy words but can’t really be bothered changing the way the work. This applies to both individuals and companies. Even if they are trying to pay lip service to the Agile way, they do it in such a half-arsed way as to make it completely meaningless (quarter-arsed).  Into here we can also bundle the people who think they are doing agile but they aren’t, people whose upper management says they are doing agile and a whole host of other types of dudes who make this bucket by far the biggest out of the ones I listed.

Adoption Rate: ~ 70%

Conclusion – Things Could Be Better

There you go this is the state of the agile process adoption world as I see it right now. That’s right, I didn’t include all the other agile and quasi-agile processes such as DSDM, FDD etc. ; that’s because I think we can either easily lump them with one of my categories (e.g. lump DSDM with the clueless people), or their adoption rates are small enough to neglect, or maybe I just don’t care to mention them.

The Agile world seems to be splintering into smaller and smaller bits as more and more people, disillusioned for various reasons, try to peddle their own brand of process.  While this is going on everyone seems to forget the fact that just about any brand of Agile is better than waterfall or ad hoc. Rather than presenting a united front and forcing crappiness, like waterfall, completely out of the software development profession we are like the Greek city states with the giant Persia sitting dismissively on our borders. Except there is no Alexander in sight to unite us all and show them what’s what.  I hope you enjoy that little bit of allegory.

Related posts:

1. Are You Actually A Post-Agilist?
2. Before There Was Lean, Agile Or Waterfall There Was Theory X, Y And Z
3. The Most Important Agile Practice Of All