All posts filed under “programming

Please don’t let yourself go stale

I’ve written before about the notion of developers going stale. Day in day out I see examples of ydiw, but not of the “You’ve made a mistake, let me fix that for you” nature, but more of the “The 80’s called, they want their program back” type. I can forgive bugs and mistakes, but I just find it very hard to not get annoyed with antiquated and long-winded ways of doing things, especially when there are far better/easier/quicker ways of achieving the same goals with other tools.

Burying your head in the sand about different techniques and technologies does no one any favours, especially yourself. You don’t need to learn each new shiny language in depth or even at all, but just reading a bit about it or even trying it out will propel your game so far ahead of the pack that you’d be foolish not to do it. Now maybe you don’t care, maybe you’re just not interested and that’s fine, it’s not for everyone, but then don’t make others suffer because of your laziness/lack of enthusiasm. I don’t come over to your house and shit in your living room, so please don’t do it in mine.

It just pains me so much when I see things being done wrong. You can call me a fanboi if you want, but I don’t simply bang the drum of the technology I use because I’ve been brainwashed, but because I’ve been where you are now and discovered something better. Now you can always ignore my advice, after you’ve investigated it yourself, but don’t just dismiss it out of hand. So many people make out like it’s such a great sacrifice to try other technologies. But how long would it really take to try something? Not even a few hours. You’re not willing to give up a couple of hours for potentially days and days of re-couped time? Get out of here!

Finally, if not for yourself, do it for your clients. Would you trust a doctor who used methods from the 15th century? No? Then why should your clients trust you if you’re still using crazy old ways to get stuff done.

So let’s make the world a better place and make my life easier at the same time. Right, I’m off to play with HTML5 and CSS3.

It’s the polish that takes the longest

After spending a few hours in Photoshop trying to get some buttons to just look “right”, I started to think about how I seem to spend the majority of my time adding “polish” to applications. Getting features in is easy, getting them working nicely and looking great is hard. It’s the 80/20 principle, it’s that final 20% that makes the difference between good and great. Apple is the obvious choice of reference here when it comes to polish. Their products are polished to such a high degree, that can’t help but I wonder what percentage of time they spend getting it right over getting it done.

who.removed.me

I had the worst tooth ache last Thursday so couldn’t sleep. So while being up for most of the night I thought I’d whip up a small app to track my Facebook friends using the new Facebook Graph API. I’m always curious to see who has removed me on Facebook, and now I can finally see who has. Check it out here http://who.removed.me

What we all need is understanding

There’s always that storyline in films and TV shows. Parents despair as they become more and more distant from their angst ridden teenage son/daughter who complains of just being mis-understood. There all the signs of neglect on the parents side, by not spending enough time/showing enough love, then there’s normally some sort of event that brings them all together again to be one big happy family. Think John McClane in Die Hard and his daughter Lucy, or Sean Archer in Face/Off and his daughter Jamie. The parents and the teenager are living separate lives and there’s a clash when they come together, because neither understands where the other is coming from.
As a developer one of the ways this problems often occurs is when working with people not from a technology background. Warren Buffett’s famous advice is to simply “Invest in what you understand.”. Many people take the time to understand their market, but do not take the time to understand the technology/process. It’s no surprise to me that the only company that I’ve worked for that’s actually achieved a measure of success is run by people who not only have a very clear understanding of their market, but also have a very clear understanding of the technology they provide. And what of the others that are no longer around? It’s no surprise I spent a lot of time at those places trying to explain how things worked and why things couldn’t be done. Yes, and while some businesses needs to be about pushing the boundaries and innovation, to do so also requires a knowledge of the limitations of what currently exists.
I have been as guilty of this sin as everyone else. As a developer it’s very easy to take no interest in the customer side of things and care only about the technology, and perhaps to a degree this is an even worse situation to be in over having management that don’t understand technology. When this happens solutions that are unusable by anyone can end up being delivered. I know for a fact I have delivered plenty of products without ever asking myself who the product is actually aimed at, all the while being feature focused. Where as now, rather then only caring if something can be done or not, I try and ask myself who will be trying to achieve a task and what is the best way for them to go about doing so. As with anything, there is a balance that needs to be found.
Managers, understand the technology. Developers, understand the market.

There’s always that storyline in films and TV shows. Parents despair as they become more and more distant from their angst ridden teenage son/daughter who complains of just being mis-understood. There all the signs of neglect on the parents side, not spending time with them or not showing enough love. Then there’s normally some sort of horrible event that brings them all together again to be one big happy family and they all live happily ever after. Think John McClane in Die Hard and his daughter Lucy, or Sean Archer in Face/Off and his daughter Jamie. The parents and the teenager are living separate lives and there’s a clash when they come together because neither understands where the other is coming from.

As a developer this problems often occurs when working with people not from a technology background. Warren Buffett’s famous advice is to “Invest in what you understand.” and while many managers take the time to understand their market, they don’t take the time to understand the technology/processes of their business. It’s no surprise to me that the only company that I’ve worked for that’s actually achieved a measure of success is run by people who not only have a very clear understanding of their market, but who also have a very clear understanding of the technology they provide. What of the others that are no longer around? It’s no surprise I spent a lot of time at those places trying to explain how things worked and why things couldn’t be done. And while some businesses are about pushing the boundaries and innovating, to do so requires a knowledge of the limitations of what currently exists.

As a developer I have been as guilty of this sin as everyone else. It’s very easy to take no interest in the customer and to care only about the technology. Perhaps to a degree this is an even worse situation to be in over having management that don’t understand technology, as when this happens, solutions that are unusable by anyone are usually delivered. I know for a fact I have delivered plenty of products without ever asking myself who the product is actually aimed at, all the while being completely feature focused. When I think back to those products, it’s a wonder they survived any sort of usage at all. Now, rather then only caring if something can be done or not, I try and ask myself who will be trying to achieve a task and what is the best way for them to go about doing so. As with anything, there is a balance that needs to be found.

Managers, understand the technology. Developers, understand the market.

Broken Window Policy of Programming

There comes a point in every software projects life where everything just feels wrong. No one wants to touch the code as it stinks and everyone working on the project just feels demotivated and would rather just go home then have to do anything more on it. On projects like this, when it comes to adding new features or bits of code, because everything else is such a mess, the changes are just hacked in rather than being properly thought out and coded up well.

We’ve all been there and the frustrating thing is that our opinion of the project, from good to bad, seems to happens over night. If you sit down and think back, you can probably pick out all the things that were just shoved in that eventually led to the project becoming a mess, but at the time we never chose to do anything about. It’s almost always a case of deferring better solutions or a round of refactoring to some point in the future. “I’ll knock this up now and come back to it later.”. The problem is that later never comes. This is the essence of technical debt. You may only go into debt by a fraction, but do it a few times and eventually all those fractions add up. Until one day when you go to check your balance, you find yourself swimming in the middle of the ocean with no land in sight.

Implementing a broken window policy can go a huge way towards keeping a project healthy. If there is a broken window (bad code) fix it as-soon-as-possible. It doesn’t have to be that instant (although if you can, you should), but fix it. Part of the policy also means trying not to break windows yourself. Write the best code you can, as often as you can. Set the benchmark of quality for the rest of the team, even if they don’t follow suit. The danger is that many people are very “me too” about things. “Well if such-and-such can do it like this, then so can I *hack* *hack* *hack*”.

Of course we all write crap from time to time. TBH most of the stuff I write is crap. But I honestly feel more motivated to work on code that’s been loved and looked after, rather than something that’s hanging together by a thread.

Essential reading for developers

I’ve been meaning to write up a list of what books I think every developer, aspiring or seasoned should read. So let’s cut to the chase, and in no particular order:

Code Complete
If there was ever a bible for coding, this is it. It’s even Bible sized. A nice size to chuck at those annoying developers who just have no clue.

Clean Code
I would consider this book the “Ten Commandments” of coding and compliments Code Complete very very very well. If Code Complete teaches you how to be a Christian, then Clean Code teaches you how to be Jesus.

Refactoring to Patterns
What I love about this book is that it you learn the fundamentals of refactoring at the same time as design patterns. The GoF Design Patterns book is quite heavy going. The examples aren’t well laid out and can be confusing especially if you’re not familiar with SmallTalk The examples in refactoring to patterns all take pretty familiar real world bits of code and walk you through the process of refactoring them into sensible patterns.

Three books? Is that it? Yup. In my mind those are the only three books that are essential reading, no matter what form of development you do. If you even remotely care about coding, then go to Amazon now and buy these books. Read them and take a good long hard look at your own code. If on the other hand you feel “You can’t be bothered” to read, learn and improve, then why are you doing something you don’t love or care about? You’re in the wrong industry if you’re not prepared to take time, all the time, to learn new things. Once you’ve read those, then you’re ready to move onto more specialised books. Here are some of my other favourite development books from over the years:

The Productive Programmer
The Art of Agile Development
Practices of an Agile Developer
Joel on Software
Unix Power Tools
Programming Perl
Essential Java
Well Grounded Rubyist
Design Patterns in Ruby
CSS Mastery
Prioritizing Web Usability

From TextMate to Vim

I’ve finally done it. After months and months of on-off usage of Vim, I’m now finally using it 100% of the time. It’s been a long and hard road getting here, but let me tell you, it’s been well worth it. I now feel like I absolutely fly through my code. I’ve read many a time, people saying that watching someone using Vim is like watching something mystical, and I can see why. Looking at how I edit code in Vim now, makes me feel clumsy when I think back to using other editors like TextMate. Don’t get me wrong, TextMate is a wonderful editor, but there is just something about the speed and finesse of editing in Vim which I have just fallen in love with.

I wrote about trying MacVim before and how I just felt it lacked the spit and polish that TextMate does. But now, I can’t remember why I originally felt that way. There’s a simple elegance to the Vim, yet with this awesome power available to you. Switching wasn’t easy in the slightest. I would load Vim up for an hour, tinker around, get frustrated and go back to Textmate. Then a month later I’d try again, learn a new command, last two hours and go back to TextMate. A few more months and hours turned into a full day, then the full day turned into a couple of days, and then I never looked back.

One of the keys to hitting the ground running is having a good config. I originally used jferris‘s vimfiles but moved to scrooloose’s files not long ago. It practically has every plugin you could ever need to make life in Vim sublime.

Some other handy references I’ve used along the way have been vimtutor, the Vim Recipies Cookbook, the Vim Tips Wiki. To aid my own memory of useful commands I’ve even started my own Vim tumblr.

Vlad 2.0 Not Finding Tasks in deploy.rb

When I restalled all my gems on Snow Leopard, vlad refused to find any of the tasks I had defined in my deploy.rb. I thought this was a SL issue but turned out a week before it’s release Vlad had been updated to version 2 which used a new plugin system. Looking for vlad rake tasks returned an error:

To solve the problem just required an install of the new vlad-git gem.

Now all my tasks were appearing properly. Vlad 2 always brought around a few changes in it’s deploy.rb and use. Here is my deploy.rb for reference:

Now invoking Vlad for my staging environment works as such:

The Code Shall Set You Free

I was recently asked why I don’t comment my code. It’s a fair enough question. There was a time when commenting your code was the done thing. I was once a great believer in commenting code as much as possible and would bash those that didn’t, but now I vary rarely comment my code at all. In my current project of over 1,500 LOC, there are only a handful of comments. Many people will argue this is irresponsible. Well how is anyone supposed to pick up and understand my code, if it’s not commented?

The code should comment itself.

That just sounds silly. It’s like saying a car should drive itself. But it can be done. A lot of this change of heart about comments has come from my commitment to becoming a better developer and spending countless hours reading about the practice of great development, which is something I’ve written about in the past. I’m a big believer that most of the time if you need to comment a piece of code, then it’s either bad code or too complicated. Of course that’s not true 100% of the time, but for the other 99% it really is. There are cases where things need to be explained and especially warned of, but a lot of the time, commenting is just an easy escape from having to do “proper” coding. It took me years and years to get a basic understanding of proper OO and I’ve still got a long way to go to reaching Journeyman levels of understanding, but I would always create large objects with huge and complex methods, when really what I needed were more concise classes with more responsibility for what they should be able to do. It’s not object orientated when you’re focus is on the method and not the class.

A simple example of commented code:

Most comments can be done away with. If we split out functionality into more concise bits, then just reading the code should explain what’s happening better:

This isn’t a great example as once again the validation of whether the food can/will be eaten should move into it’s own method or class ever. If we’re follow Uncle Bob’s SOLID principles, the above examples breaks the OCP (Open Closed Principle) where entities should be open to extension and closed to modification. If more validation rules were needed, then that would require the code to be modified.

rake spec fixtures failing

For some reason my rspec fixtures were not loading into my development database when doing spec:db:fixtures:load. An extra parameter to db:fixtures:load is all that’s needed.

Fixed by:

RSpec + Autotest + Growl + Doom Guy

I spent this morning playing around with autotest, but was getting really flaky results with the Growl notifications. I tried about four different autotest configs, but none of them seemed to consistently worked. I remembered that the Growl notifications at Thursday’s Coding Dojo worked pretty well, so after some digging around I found the config on their github. After a tiny tweaking I was even able to get it to work with Przemysław Kowalczyk’s Doom Guy. I’ve packaged it all up and put it on Github. Enjoy.

doomguy-growl-autotest

Goodbye Grails

It finally came time to un-subscribe from all the Grails feeds I used to read. As I’ll no longer be doing any Grails it makes little sense to really keep up with what’s going on in the Grails world. Grails has a lot going for it, but even after over a year of doing it, it just never felt as smooth or dreamy as Rails always has. It managed to replicate some of the core that made Rails so wonderful to begin with and did a good job of it most of the time. Perhaps if I had more experience of the Spring and Hibernate core I could have got more out of the Framework, which is fine and that is on my head, but in the end it just got more and more frustrating as features available in Rails were just impossible at the time in Grails. I’m not saying that Grails is lacking, as at the end of the day, there’s nothing you can do in Rails that you can’t replicate in Grails.

In hindsight I was perhaps the wrong audience. Groovy/Grails is the perfect Java answer to Rails. I chose it to stay consistant with our other apps, so that everything ran on the same JVM and was all containted within the same application server. There were no constraints on the technologies that had to be used. Consistancy, perhaps, was the wrong reason to choose it. Maybe I should have chosen it if I had more knowledge of Spring and Hibernate. Maybe I should have chosen it if I had to to run in the same server and on the JVM. Who knows. I wish the Grails team all the best. Who knows, I may end up coming back to it one day. Stranger things have happened.

So much to learn

I could tell you how I still continually fight the demons that encourage me to rush instead of following a disciplined course. I could tell you about all the tests I don’t write. I could tell you about the constant allure of shortcuts and my imperfection at avoiding them. I could tell you how often I look at that green band on my wrist and shudder at how imperfectly I follow it’s urgings.

Robert Martin – Glory and success are not a destination, they are a point of origin.

Reading that even the masters feel the same way that I do about developing sometimes, must mean I’m on the right track?

TDD is Hard

TDD is hard, seriously hard. Perhaps that’s a bit of an overstatement, but for me, after years of “skill neglect”, it’s been a real struggle to pick up and get right.

The problem isn’t writing the tests, it’s writing code that’s testable. I’ve dabbled a bit with unit testing in the past but never really got the “unit” part of it. My tests would dive into a class that relied upon other classes and I would assert some value passed all the way through the call stack. In hindsight this is totally wrong (unless we’re talking functional testing) but at the time, my only concern was getting a passing test, which I was successfully achieving. It was testing, but not as I now know it.

So now I know better. Now I know that a unit test should only really concern itself with the class at hand. The results returned should be a direct product of the method called and should not have been meddled with by a third party class/library/what-have-you. Before really taking some time to learn the subject of testing, I would have looked at my testee, thought “Well this class relies upon this other class here, what can I do but let the call happen.” and as such my unit tests turned into functional tests. But now I know I can substitute those called classes out for fakes, dummies, stubs or mocks.

I started out by writing tests for some existing legacy code (TDD arse about face really) and really struggled with working out how to use my mocks as callees for my target testee. I was instantiating classes inside methods and then making calls out to it. There was no way of substituting the concrete class out for my mock. But now I know I can substitute classes using dependency injection.

The nice thing about mocks and dependency injection, is that you’re not just able to verify the result of your testee, you can also verify it’s interaction with the mock. If your testee is only supposed to call getAmazingValue() once, you can fail if the method is called more times than that, or perhaps even called with the wrong parameters. I would have taken it on almost blind faith that the interactions I had been creating were correct. But now I know I can record, replay and verify these interactions. *

The hardest part for me was writing code I could test. TDD forced me to think about the design of my classes all the time, every time. When doing TDD I start with the test. I think about how I would like the call to work and then I code up something just to make the test pass. Then I’ll think about how my class relies upon a call out to some other class. So I’ll create a small mock for the testee, go about injecting it to get the test working again and then make sure the interaction between the testee and mock happened exactly as it should of. TDD is a beautiful thing, but it has its thorns. Just like everything in computing, on the surface the concept is deceptively simple. But when you really start to look into it and try and do it properly, what seemed like just a piece of floating ice is really the tip of a huge iceberg. The pain of doing it right is well worth it with the reward of less bugs and easier changes. It’s a hard concept to keep going and feel like it’s worth it, as the benefits sometimes might not be seen for some time. It’s only in that moment of changing something that you see straight away that it’s broken other pieces of implementation, do you really feel glad that you made the effort.

  • While mocks allow for the testing of the interaction between the testee and the mock, this doesn’t always mean the relationship is correct. If I mock a class and expect a call to getAss() but the real concrete class expects a call to getArse(), then the whole thing falls apart when run in the wild. This might not be such a problem when the mock is derived from a common interface, but in dynamic languages, there is that margin for error.

It’s an Improvement Adventure

It’s amazing how easy it is to be a programmer/developer/code monkey without having to do it properly. I got my first programming job when I was 17, a whole ten years ago, and now after recently reading Clean Code and Refactoring to Patterns, I can’t help but wonder what the hell I’ve been doing all this time. I’ve been writing code, but I sure as hell haven’t been programming. Looking at the code I’ve written as recently as only a few weeks ago now makes me cringe. “Why am I calling this method here?”, “What the hell is this comment?”, “Is this a joke?!?”.

I took a job as a developer for a mobile phone voicemail to email provider four years ago. I was only there for a few months but I still feel like I learnt more about programming while there then I had previously and ever have done since. I’m a firm believer in the notion that you’re only ever as good as the people around you. If you come in at a lower level you’ll soon pick up the pace, and if you come in over those around you, you’ll soon slow down to match your co-workers. As always there are exceptional circumstances. Sometimes if you’re too low, you’ll never be able to perform to the same standard, and if you’re too high, you probably won’t stick around long enough to get bogged down. I’m in a bit of a unique situation in my present role, because I work in pretty much complete isolation from other developers. Which means I have to set my own benchmark. I remember when I started, I was still so full of energy from my previous job (the one mentioned above) that I wrote some pretty cool code, which even impresses me when I look at it four years on. But as time went by I became more and more rusty and the quality of my code decreased dramatically. I stopped reading computing books altogether and took more of an interest in general business subjects. I took an interest again when Rails came on the scene, but none of the coolness or wow factor of doing Ruby could be applied to my day job doing Java, so that area of my life still continued to dwindle. The discovery of Grails changed that to a large degree, but by then I had lost the sparkle for Rails and my code became the same mess, just in a different language. I constantly think to myself that there has to be a better way. Rails and Grails felt like an answer to a certain degree, but the same underlying issues of design and brittleness remained. While features were quick to implement, changes were slow and painful to make. Simple requests became complicated hacks built upon other hacks to fill in holes left by other feature requests. Rails and Grails, while eye openers and moral boosters, didn’t solve my problems.

I was naive and blamed the language, the framework or the previous developer for my issues. I felt that my designs were sound and the code of a high standard. It “felt” tidy and the functionality all there, neatly sectioned off into different places. But Clean Code and Refactoring to Patterns showed me how wrong I had been. Regardless of the language or the framework, without well designed, robust and agile coding practices, you eventually hit a very hard brick wall. To say they were an eye opener is an understatement. It felt more like a programming re-birth. In hindsight, all the signs of bad code were there, I had just become totally blind to it.

Not very long after reading both books, I tasked with making some changes to an old legacy Java system. In the past I had absolutely detested working on it. Everything felt like a mess and that the slightest change would bring the whole system to its knees. But I felt confident this time. I started writing tests, which I had never done before, and started using the absolutely brilliant refactoring capabilities of IntelliJ. I spent a lot of time refactoring code so that the new functionality existed, wrapped up, in a state that it should, rather then in a shoehorned/hacked state. No doubt it too me longer then if I’d just shoved it in, but the system became better as a whole for it. The long reach of the masses of refactorings I performed have left parts in a greatly improved state. Perhaps in some cases, with added complexity – a small price to pay for better testability, design and extensibility. I would rather have an added degree of complexity over a brittle design any time

Anyone can knock out code, anyone can cut-and-paste a system together if they tried hard enough, but writing code alone is a solution to a small fraction of the overall problem. Anyone can churn out new features for a v1 release, but what about v1.1 or v2 or v3. As developers we dig our own graves. Clients don’t understand why things used to happen so fast, but now it’s sometimes weeks before anything new is ever shown. Fast – Slow – Slower.

This is where good, clean code starts to come into it’s own. Code that’s light on it’s feet. Code that’s easy to move in and out. Code that isn’t a brick wall and requires you to code around. Good design and good coding practices are at the heart of delivering a robust solution. If you are a developer you need to read the books I mentioned above, or at least just Clean Code. Heck, as a developer you need to read books. FULL STOP. I know many developers who don’t read at all, which to me is just unthinkable. You maybe one of the few that shrugs their shoulders after reading something like Clean Code and says “Yeah, I know all this already.”, and if so, good for you, but even you will probably know someone who could do with reading it, probably more then once ;)