"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

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 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

Have you heard that term? I happened upon it purely by accident about a year ago and after reading and learning a bit about it I found that I could identify with it quite a bit. You can read Jason Gorman’s post Post-Agilism Explained (Pretentiously) as well as Jonathan Kohl’s massive post – Post-Agilism Frequently Asked Questions for a great discussion of what the post-Agile movement is all about. Jonathan and Jason independently coined the term at about the same time so they are an authority on the term if anyone is. I am going to attempt to give my humble views on the topic and hopefully you will identify with some of what I say.

For those of you who’ve decided to learn about post-Agilism after they finish reading this post (thanks!), post-Agilism is basically a movement in the software development community of people who see themselves as moving beyond Agile methods. They have used Agile and not-so-agile methodologies and have moved beyond both to using an amalgamation of tools and methods that best facilitate them doing their job. Post-Agilism is not about evangelizing a particular process or a set of practices or even the Agile Manifesto, it is about getting to the core of the issues that process in general tries to address and solving them in the best ways possible. At least, this is the way I see it.

Post-Agilism is not about rejecting the Agile practices, it is about not limit yourself by Agile practices. I think the original spirit of the Agile movement has now become the spirit of the post-Agile movement as Agile is becoming less about the spirit and more about pushing a particular Agile process as the best one (there are so many to choose from now). At first it was Agile vs heavyweight; now it is still that, but it is also Agile vs Agile (we are an XP team we are the best, no we are clearly superior for we are a Scrum team!).

I for one get extremely annoyed sometimes at process vs process discussion (be they Agile or not), I see them as completely pointless. One of the core ideas behind Agile which most often seems to be forgotten is the fact that you’re meant to adapt, to ‘bastardise’ the process and practices until you get something that works for you. This makes any kind of process/practice purist argument meaningless. This very agile idea of being adaptable, of chopping and changing to fit your needs is now also at the core of the post-Agile movement.

To me, the most important thing about a process is the ‘spirit’ of it, not the practices. Quite often these days Agile teams seem to loose sight of the agile spirit and I think the post-Agile movement is more about the spirit. When I say spirit I mean things like:

• respecting the individual
• communicating effectively
• doing work (writing code) that you could be proud of
• not getting bogged down in minutiae
• having some backbone when dealing with those around your team (i.e. stakeholders etc.)
• etc.

And all of these at the same time, not one by one.

If these sound suspiciously like the Agile Manifesto, they are meant to, the spirit of the Manifesto is very sound. If some of these sound strangely unlike the Agile Manifesto they are also meant to, the Manifesto is not the be-all, end-all of commandments that we live by.

This I think is also at the heart of the post-Agile movement, it is not about the process, it is not about the practices, it is about the spirit of agile, it is about the ideal. Use your knowledge to select the most appropriate tools, processes and practices, whatever they happen to be. There is no best length for an iteration, there is no best retro format, pick whatever works and discard it if it doesn’t, as long as you stay true to the ideal, you won’t go too far wrong.

Here is an example that might help make my meaning a little bit clearer. I’ve been interested in distributed Agile for a while now. So, what do you do if you ever find yourself working in a distributed environment with multiple teams that are not co-located? Trying to make the best of a bad situation while all the while moaning about how much better things would have been had the teams been located in the same place. That is NOT staying true to the agile spirit (alright, you can moan a little bit, good for the soul and all). Trying to find ways to effectively collaborate, to make things work better, to innovate solutions, to get to know the people on the other teams (rather than complaining about their ‘crappy’ code). That would be living up to the ideal, staying true to the spirit of agile, or post-Agile as the case may be.

I found myself in very strange territory of not being able to find the words to adequately get my point across with this post (I can usually express myself pretty well, and loudly, just ask anyone who knows me). Parts of this post seem overly existential to me while others just seem to tread over the same ground. I guess it comes from trying to express ideas that are almost subconscious for me. Hopefully this will have resonated with people on some level or at the very least given people some food for thought.

Perhaps some comments might help clarify matters for everyone. I’ve tried to explain my thoughts, so what does post-Agilism mean to you? Would you consider yourself a post-Agilist or are you still firmly in the Agile camp (or god-forbid, heavyweight)? Any relevant thoughts would be appreciated.

Related posts:

1. The Current State Of The Agile Nation – Agile Process Adoption
2. Rules Of Standup – You Don’t Need To Justify Your Own Existence
3. The Real Measure Of Code Quality

If you’re a serious Java (or possibly even .NET) developer you’ve most likely used the Spring Framework before for all you dependency injection needs. You therefore probably know that there are 2 common ways to inject dependencies into your spring beans:

• setter injection
• constructor injection

But, did you know that there is a lot more to it than that? Spring has some extremely powerful capabilities that allow you to do a lot more than just call constructors and setters when creating Spring beans and injecting dependencies.

I am going to attempt to show you some ways that will allow you to create spring beans and inject dependencies in all sorts of different ways, which should let you get a lot more out of using Spring. If you’re a Spring guru then you probably won’t get anything new out of this, however everyone else should hopefully learn something new and become a much more versatile Spring developer.

Different Ways To Instantiate Beans And Inject Dependencies

The Standard Way

The simplest way is to create a bean with no dependencies using a default constructor:

<bean class="my.crazy.example.SampleBean" id="sampleBean" />

To inject some dependencies we can use setter injection, constructor injection or a mix of both. If our SampleBean is:

public class SampleBean
{
   private int intValue;
   private float floatValue;
 
   public SampleBean(int value)
   {
      intValue = value;
   }
 
   public void setIntValue(int value)
   {
      intValue = value;
   }
 
   public void setFloatValue(float floatValue)
   {
      this.floatValue = floatValue;
   }
}

The Spring configuration could be something like:

<bean class="my.crazy.example.SampleBean" id="sampleBean">
    <constructor-arg value="25" />
    <property value="0.57" name="floatValue"></property>
</bean>

All pretty standard stuff, on to more interesting things we go.

Using A Static Factory Method

We can use the ‘factory-method’ attribute to tell spring to call a static factory method to instantiate our bean. So, if we have a SampleBean:

public class SampleBean
{
   public SampleBean()
   {
   }
}

and a SampleBeanFactory with a static method:

public class SampleBeanFactory
{
   public static SampleBean createEmptySampleBean()
   {
      return new SampleBean();
   }
}

we can do the following:

<bean id="sampleBean" class="my.crazy.example.SampleBeanFactory" 
                            factory-method="createEmptySampleBean"/>

This will only create a simple bean with no dependencies and what if we want to pass parameters to our factory method? Simple, if our SampleBean is now:

public class SampleBean
{
   private int intValue;
   private float floatValue;
 
   public SampleBean()
   {
   }
 
   public void setIntValue(int value)
   {
      intValue = value;
   }
 
   public void setFloatValue(float floatValue)
   {
      this.floatValue = floatValue;
   }
}

and our SampleBeanFactory is:

public class SampleBeanFactory
{
   public static SampleBean createSampleBeanWithIntValue(int value)
   {
      SampleBean sampleBean = new SampleBean();
      sampleBean.setIntValue(value);
      return sampleBean;
   }
}

We can create a bean in the following way:

<bean id="sampleBean" class="my.crazy.example.SampleBeanFactory" 
                          factory-method="createSampleBeanWithIntValue">
    <constructor-arg value="25"/>
    <property name="floatValue" value="0.57"/>
</bean>

The constructor arguments will be passed as parameters to our static factory method and the property elements will be set on the SampleBean. Obviously you can’t use setter injection to inject parameters into the factory method and you can’t use constructor injection to inject dependencies into the SampleBean.

You can see how this would come in useful, especially if you’re working with existing code that you can’t change that uses static factory methods to create objects. You can now wire in objects created by static factory methods as spring dependencies. But what if the factory methods are not static, but still create objects that you want to wire in?

Using An Instance Factory Method

We can use the ‘factory-bean’ attribute along with the ‘factory-method’ attribute to call instance factory methods to create our beans. Let’s say our SampleBean is still:

public class SampleBean
{
   private int intValue;
   private float floatValue;
 
   public SampleBean()
   {
   }
 
   public void setIntValue(int value)
   {
      intValue = value;
   }
 
   public void setFloatValue(float floatValue)
   {
      this.floatValue = floatValue;
   }
}

Our factory on the other hand is now a SampleBeanInstanceMethodFactory:

public class SampleBeanInstanceMethodFactory
{
   private int uselessParameter;
 
   public SampleBean createSampleBean(int value)
   {
      SampleBean sampleBean = new SampleBean();
      sampleBean.setIntValue(value);
      return sampleBean;
   }
 
   public void setUselessParameter(int uselessParameter)
   {
      this.uselessParameter = uselessParameter;
   }
}

So, we can create our SampleBean by defining our SampleBeanInstanceMethodFactory as a bean and then using it as a value to the ‘factory-bean’ attribute:

<bean id="instanceMethodFactory" 
    class="my.crazy.example.SampleBeanInstanceMethodFactory">
</bean>
 
<bean id="sampleBean" factory-bean="instanceMethodFactory" 
                              factory-method="createSampleBean">
    <constructor-arg value="25"/>
</bean>

We can also now pass parameters to our factory when we create it and still pass parameters to our factory method and the SampleBean as well:

<bean id="instanceMethodFactory" 
    class="my.crazy.example.SampleBeanInstanceMethodFactory">
    <property name="uselessParameter" value="123"/>
</bean>
 
<bean id="sampleBean" factory-bean="instanceMethodFactory" 
                               factory-method="createSampleBean">
    <constructor-arg value="25"/>
    <property name="floatValue" value="0.57"/>
</bean>

This is all similar to what we did with the static factory method, but it gives you the extra level of flexibility to be able to work with instance methods that create objects. But what if I don’t like any of this factory method nonsense and still want to be really advanced?

Using A FactoryBean

You can instantiate objects by creating a factory class that implements Spring’s own FactoryBean interface. This means that you can treat your FactoryBean as if it were itself the object that you’re trying to create, so you would wire in the FactoryBean anywhere you want to use the actual object you’re trying to create and Spring will automatically call the right method on the FactoryBean and use the return of that method as the object. This is best demonstrated with an example. The FactoryBean interface has the following methods on it:

• Object getObject()
• Class getObjectType()
• boolean isSingleton()

You have to implement all three. So, our SampleBean is now:

public class SampleBean
{
   public SampleBean()
   {
   }
}

Our FactoryBean to create the SampleBean will look like this:

public class SampleBeanFactoryBean implements FactoryBean
{
   public Object getObject() throws Exception
   {
      return new SampleBean();
   }
 
   public Class getObjectType()
   {
      return SampleBean.class;
   }
 
   public boolean isSingleton()
   {
      return false;
   }
}

When we want to wire in a SampleBean as a dependency of a FunkyBean that looks like this:

public class FunkyBean
{
   private SampleBean sampleBean;
 
   public FunkyBean(SampleBean sampleBean)
   {
      this.sampleBean = sampleBean;
   }
}

we would do the following:

<bean id="sampleBean" class="my.crazy.example.SampleBeanFactoryBean" />
 
<bean id="funkyBean" class="my.crazy.example.FunkyBean">
    <constructor-arg ref="sampleBean"/>
</bean>

As you can see we just wire in the SampleBeanFactoryBean in place of a SampleBean and let Spring do its magic by calling getObject() and returning the output of that as the bean to wire into the FunkyBean, pretty sweet.

Why is this useful, you ask? Well in our contrived example above it doesn’t really add much value, but let’s say you needed to create an object in some really complex fashion. For example, let’s say you obtain your object, by establishing some kind of network connection and getting some xml sent over-the-wire which you then de-serialize into your object. You then want to treat you new object as spring singleton (yeah I know, not contrived at all :)). Well, FactoryBean is a perfect way to do this. It provides you with a factory method type of approach to creating your object and then lets you easily manage your new object as a Spring singleton. So, if our SampleBean still looks like:

public class SampleBean
{
   public SampleBean()
   {
   }
}

Our SampleBeanFactoryBean would look like this:

public class SampleBeanFactoryBean implements FactoryBean
{
   private SampleBean sampleBean;
 
   public Object getObject() throws Exception
   {
      //ignore the fact that all of this is basically pseudocode
      if (sampleBean == null)
      {
         NetworkConnection connection =
            NetworkConnectionFactory.getFunkyNetworkConnection();
         String beanAsXml = connection.getSampleBeanAsXml();
         sampleBean = DeSerializer.deserialize(beanAsXml);
      }
      return sampleBean;
   }
 
   public Class getObjectType()
   {
      return SampleBean.class;
   }
 
   public boolean isSingleton()
   {
      return true;
   }
}

We would be able to wire in our SampleBean in exactly the same way as before. Ultra useful, but you have to implement a Spring interface which couples your code to Spring somewhat, that’s the price of power. So, consider carefully, if you don’t mind being tied to Spring, then there is no problem, but if you want your code to remain unaware of the container you’re using, you may need to consider a different solution.

Using Lookup-Method Injection

I thought I would include this one because it is pretty cool and a good feature to be aware of. Essentially, Spring can dynamically override methods on container managed beans. This is actually explained pretty well in the Spring documentation, but here is the quick and dirty version. If you have a singleton bean (SingletonBean) that needs to work with an instance of another bean (which is not a singleton – PrototypeBean) every time a method on the singleton is invoked, you can do one of 2 things. You can either make your SingletonBean BeanFactoryAware so that you can fetch a different instance of your PrototypeBean every time your singleton needs it or you can use lookup-method injection.

The first solution is fine but is not ideal if you don’t want to tie your code to Spring, so this is where the second solution comes in. If your SingletonBean looks like this:

public abstract class SingletonBean
{
   public Object process(String someState)
   {
      PrototypeBean prototypeBean = grabPrototypeBean();
      prototypeBean.setState(someState);
      return prototypeBean.doPrototypeBeanStuff();
   }
 
   protected abstract PrototypeBean grabPrototypeBean();
}

and your PrototypeBean is as follows:

public class PrototypeBean
{
   private String state;
 
   public Object doPrototypeBeanStuff()
   {
      // do whatever here
      return "";
   }
 
   public void setState(String someState)
   {
      state = someState;
   }
}

Spring can actually override the createPrototypeBean() using lookup-method injection to provide a new instance of a PrototypeBean every time that method is called. Spring does this by using bytecode instrumentation with CGLIB to dynamically subclass the SingletonBean and provide it with an implementation for the createPrototypeBean() method (obviously you will need the CGLIB library in your classpath somewhere). The Spring configuration would be as follows:

<bean id="prototypeBean" class="my.crazy.example.PrototypeBean" 
                                        scope="prototype">
</bean>
 
<bean id="singletonBean" class="my.crazy.example.SingletonBean">
    <lookup-method name="grabPrototypeBean" bean="prototypeBean"/>
</bean>

You can see how this one could come in handy in some situations if you want to keep managing your beans through dependency injection but don’t want to tie your code to Spring. Plus, it sounds really impressive when you tell people how you were "using bytecode instrumentation to facilitate dynamic lookup-method injection" :).

Well, that’s it, hopefully you got something new out of this and have more of an understanding of the powerful features that you have at your disposal when you use Spring even for basic things like dependency injection.

If you would like me to expand on anything that I covered here then please let me know by leaving a comment and I will create a new post or extend this one. Also let me know if you feel like this post should have covered some more ground, perhaps more relevant examples, or possibly there is another cool way to instantiate beans in Spring?

Related posts:

1. Ruby Access Control – Are Private And Protected Methods Only A Guideline?
2. Write A Function To Determine If A Number Is A Power Of 2
3. True, False And Nil Objects In Ruby

There was a comic going around a few weeks ago about code quality, you remember the one:

Pretty amusing, but it got me thinking, what IS a good measure of code quality? Quality after all is very subjective, what I might perceive as being great, you might perceive as crappy for a host of reasons. A pet pattern wasn’t used quite right, the unit tests aren’t “real” unit tests, you know of a library that would have made the whole thing 10 times easier, etc.

There are all sorts of different measures that might relate to code quality, the level of coupling, the testability of the code, the test coverage, adherence to standards and many others and yet all of these are still subjective to a degree. There are times when not adhering to standards is best, just as there are times when a low level of coverage is good enough, it is all different from system to system, situation to situation. So is there no one good measure of code quality?

I contend that there is only one measure of code quality that is worth anything. We can argue all we want about numbers and patterns but in the end, one thing will always be true for every good developer:

Every good developer intrinsically knows if his/her code is good enough!

That’s right, you already know if your code is good enough, if you think that you don’t then you’re deceiving yourself and need to ask yourself the following questions.

If you were to think of a developer you admire, would you be proud to show your code to that person or would you cringe in shame if they were to see it? By extension, if that person were to criticise your code for whatever reason, would you vigorously defend it with all your heart or would you put in a token defensive effort for appearance sakes?

Due to the nature of our work, developers are part artist, part craftsman and part scientist and the one thing that all those people share is the ability to know if what they’ve produced is worth anything. Therefore, before we go and try to find an external way to validate our code for quality (and that includes getting it reviewed by other people) we need to be completely unequivocal about our answer to the question:

Do I think the code is good enough?

If the answer is not unequivocally yes, then there is no point going any further and you have some work ahead of you. If the answer IS yes, it doesn’t mean the code is perfect and can’t improve, it means that only more knowledge and/or experience can make it better. This is when involving someone else is a good idea, sharing knowledge and experience is (partly) why we work in teams after all.

The above works even better for pair programming, but the question becomes:

Do we as a pair think the code is good enough?

This works better because as a pair your internal threshold for quality will most likely be higher than it would be for each of you individually and you’re already sharing knowledge and experience. The threshold becomes higher still if you regularly rotate pairs. Although I do believe there will be diminishing returns if too many people have a stake in the code, but if the story size is small enough, this should not be an issue.

Well, those are my thoughts on measuring code quality I wonder what everyone else thinks. Do you agree with me or do you perhaps think that I am way off base? Do you know of a better way of measuring code quality (no, WTF per minute doesn’t count)?

Related posts:

1. Are You Actually A Post-Agilist?
2. How To Be A Real Elite Programmer And Make Sure Everybody Knows It
3. Effective vs Ineffective Pair Programming

Lately, I’ve been thinking about what makes a software developer a good software developer. All the generic things that you would expect came to mind, knowledge, skills with tools/frameworks, memory, teamwork skills, caffeine etc. But all of those are boring and predictable, noone wants to be boring, so I thought harder, I thought and thought “till I couldn’t think no more”. Then I had some tea, then I watched “The Simpsons”, now I am writing this article, but I digress, which actually illustrates my first point fairly well (in a roundabout sort of way, so bear with me).

1. Creativity

While drinking my tea and munching on my crumpets (that’s a figure of speech I wasn’t actually eating crumpets, I was having a croissant … I think I just made it worse). Where was I, oh yeah, while doing something completely unrelated I was able to come up with some interesting points about what makes developers, developers. Unlike what TV and certain other elements would have you believe, most good developers are not just single-minded calculatory automatons obsessed with algorithms, but are rather very creative people. Notice how I made up a word in a very sentence preceding this one, I bet most of you didn’t even realise “calculatory” wasn’t a real word.

The point I am trying to make is that the ideas for this article came to me not through rigorous calculation and formulaic thinking but through inspiration. I stopped focusing on what I wanted to do and let the universe fill me with its goodness (in a completely figurative way) and then all of a sudden KABLAMO! Inspiration strikes and I am able to go and paint a painting (if I could paint), or create a little application to help me manage all my passwords (which I certainly can do), or write an article about developers (which I am doing right now). I bet you missed how I made up another word, kablamo, yeah I know, I am plagiarising it from someone, but plagiarism is the reality TV generation’s brand of creativity so it still counts.

2. Insane Curiosity

Many people are curious, but I find that many good developers are overly curious even when compared to your average Joe Curious. I would certainly fit that description. You’ve probably guessed that I am writing all this while operating under the assumption that I am a fairly good developer, since I use myself as an example so much. So, if you could all just suspend your disbelief for a few minutes and share that assumption with me we’ll be able to proceed with the rest of this article.

This trait of curiosity doesn’t just begin and end with software but extends to all facets of the life of a software developer. This is why most good software developers that you meet have one, two or sometimes even more alternative “things” that they really like doing and could probably make a living in if they weren’t doing software. It is also a really helpful trait in the IT industry with it ever-changing landscape. If finding out new things and learning new skills was a chore, one would find it very hard to keep up with the pace of the industry. But when you take insatiable curiosity into account, keeping up with the industry becomes a natural thing, a result of the personality of a good developer.

Finally it certainly doesn’t hurt to be a curious individual when your job involves constantly trying to get to the root of complex problems. You have to have the “need to know” rather than just treating it as a job.

3. Finding Fault With Absolutely Everything

Good software developers are ornery and opinionated, it is a fact, accept it. And the special power that the lot of them share is the ability to always find something to complain about. When it comes to code this trait presents itself as the perception that nobody else’s code is ever good enough, not even your own.

No matter how well the code is written, when good developers get their hands on it, they will always find a reason why the code is crappy and should be re-written/refactored to be “better” and of course they are just the person to do it. In this light this may not seem like such a desirable attribute, but consider that this trait is synonymous with a constant desire to improve. Notice that I never said that good developers like to find faults for the sake of finding faults, but rather they are able to find areas where they can use their expertise to improve the situation and create a better/cleaner/faster/etc system overall.

You could only hope and dream that the person who is building your house has this kind of attitude, if they did we might be able get some damn decent construction once in a while. For the moment though we’ll just thank the all powerful spaghetti monster in the sky that construction workers don’t build software, and hope that this trait of good software developers gets the recognition it deserves.

4. Working Hard To Facilitate Laziness

Developers are the hardest working lazy people you’ll ever meet or possibly the laziest hard working people. Developers love to write little tools and find little ways to make everything more automated which would of course make our lives much easier. Our goal is to get to the point where we just sit there and our little automated tools do all the work, from writing code to calling home and telling our wife/girlfriend/robo-doggie that we’ll be late for dinner.

At least that’s the myth that we all perpetuate amongst ourselves. We are all well aware that the more we streamline and automate and find ways to make our life easier in general, the more work appears to fill that five minutes that we’ve saved. Applications become more and more ambitious and the good developers have to once try to flex their ingenuity to shave off some time in all the right places. And then the application will become more ambitious still and the cycle begins again.

This trait is the reason that the software industry has come as far as it has in such a relatively short time-frame. The good developers find ways to do stuff more efficiently, to automate and streamline, all in the name of supporting their laziness habit which allows more room for grander scope and vision. If it weren’t for this trait that all good developers share we’d still be writing the next greatest calculator application using LogoWriter and punch cards (Go LogoWriter!!! You shall live on in our hearts forever! Amen!).

Well that’s it, I had all this other stuff to say, it was all really awesome, but I can’t be bothered. Hmmm, an application that figures out what I can’t be bothered saying and notes it down anyway. That’s gold! I’ll make billions! Where is my drawing board…?

Would you like to share your thoughts on the unlikely traits that good developers have, or maybe you’d like to critique my thoughts? Leaving a comment is your opportunity, you could even try to automate the process and then I’ll have to put capchas in (*sigh* it’s a never-ending dance). Oh yeah, the RSS feed button is at the top of the page, this blog needs more RSS love.

Related posts:

1. Fitness for Software Developers (and Other IT Professionals)
2. 3 Things They Should Have Taught In My Computer Science Degree
3. The Real Measure Of Code Quality