WallyLawless.com

Sep

2010

I Just Test-Drove My First Development

I’ve been hearing about the benefits of Test Driven Development (TDD) for awhile now, but have never taken the time to try it out with any of my own work.

That was until this past week.

The code that I work in with my job doesn’t really lend itself to TDD simply because it’s all straight-through procedural code. The few functions that do exist would only be able to be tested by checking the raw HTML that the emit against an expected result. It’s possible, but extremely tedious so we just avoid it completely.

Recently though, I had the opportunity to write some new code, a small module completely independent of any of our existing code. I decided to give TDD a shot and see how things went.

It took a bit to get PHPUnit up and running on my dev machine, but once I did things started to progress nicely. I stubbed out some of my initial functions and got my tests failing, it was pretty exciting in the way that playing with new tech usually is.

I’m by no means a TDD expert, but here’s some things I noticed with my experience so far:

I REALLY need to refresh my Object Oriented design skills, it’s been too long since I’ve used them
By doing just the minimum to make the tests ‘green’ I wrote far less code than I thought I would
My current code is far too coupled, I need to watch out for that because it’s hard to test
Once some tests are in place, refactoring is awesome, you know instantly if you broke something
TDD feels like another safety net above source control
Writing tests isn’t as hard as I thought
TDD is a completely different way of thinking about writing software

I’m pretty excited to continue on this path and fully explore what TDD can offer. I’m thinking some continuous integration and maybe, just maybe, some automated UI testing down the road. It’s a brave new world!

What’s your experience with TDD been like? Any tips PHP specific or not? Please just leave a comment below.

Mar

2010

After 10,000 of software development

At some point in recent history I hit a milestone and didn’t even realize it. It wasn’t a certain birthday (although next year is the big 3-0) or a 6 figure salary (sadly), but something a little more practical. The milestone I passed was 10,000 hours as a professional software developer. According to some it typically takes 10,000 hours of actively pursuing a skill before becoming successful at it. I don’t know if I can yet call myself a ‘successful’ developer, however recently I have come to a number of realizations that may be related to my 10,000 hours of experience. I’m not going to come up with 10 things just because it sounds good in a title, and I rather like the number 7, so lets see if I can put together 7 good realizations that can hopefully be useful to somebody.

Realization 1: The first production code I wrote was REALLY bad
It wasn’t exactly littered with GOTO statements, but the first thing I noticed when I went back to look at it was that it was really hard to read. My variables were all over the place, their names didn’t make any sense and the comments were essentially useless. Now that I have had Realization #5, I don’t write code like this anymore.

Realization 2: I really sucked at estimating how long things would take
I used to look at a problem and say ‘Ah, that’s pretty easy, it should only take a day or so’ (I still hear new people say this from time to time and cringe) However once I get into it, the time seems to melt away. I may get my original function up and running, however there’s certainly a bunch of edge cases I never thought of. Or, my favourite, the data I thought I had access to wasn’t actually available to a specific part of the code I’m working on, so I suddenly have to write a bunch of plumbing code. Perhaps the UI sucks once I see it working, or maybe I’ll be lucky and it’s just slow as hell.

Realization 3: A hack that works, in the end, still works
There’s doing it right, and there’s making it work. In the end, your customers don’t care how you do it, as long as you make it work. If it doesn’t work but it’s done right (which is possible by the way) then you wont have any customers so you’ll be screwed anyway. So, if you need a hack to fix something, go ahead, just note it in the comments and your bug tracking tool so that you can plan for it when you come back to refactor.

Realization 4: Deleting code is AWESOME
When I started programming, it was all about writing code, as fast as possible, so that I could see things moving forward. Now, my priorities have changed. I’ll look at some code and ask myself “Does this really need to be here?” The most exciting part of my day is when I get to hit the DELETE button on 100+ lines of code. Deleting code for me generally leads to more flexible software so that the next time I have to actually write some code, I often need less of it to get the job done.

Realization 5: Being able to read code is much more important than knowing how to write it, and reading code is harder than writing it
Let’s face it, unless there’s been a drastic development in cloning technology that I’ve managed to escape, there’s only one of you. There’s a LOT more of everybody else. You can be as efficient as you want, but you will NEVER be able to write more code than all of them. You don’t think the same as everybody else does, so you probably wont think about problems the same way others do. You NEED to be able to read someone else’s solution to a problem and understand what’s going on. If you don’t you’re very likely to introduce some pretty painful bugs into the system. I’ve been reading through Coders at Work and one of the primary skills each of the interviewees advocates is being able to read code. They’re way smarter and more experienced than I am so their advice is worth listening to.

Realization 6: Code doesn’t have to be perfect, more often then not it’s impossible
This is somewhat related to #3, but from a different perspective. It’s not worth it to hold on to code until you’ve convinced yourself that it’s perfect. Your users will tell you when it is perfect, so get your code out to them fast to get their feedback. If you’ve spent a month working on something and you feel it’s perfect, but your users have never seen it, you’re going to be a lot more apprehensive when you release it just because if they hate it you have just wasted a lot of time. I hate wasting time, it’s just not worth it. So, get your code out quick, get feedback, and iterate. It’s a bit of a cliche, but small course corrections are much less painful than large rewrites.

Realization 7: I feel like I know less now than I did when I started
I think this applies to any field, not just software development, but now that I have a bunch of experience at my back, my eyes have been opened to how much I DON’T know. When I started I felt that I was getting closer and closer to fully understanding what this is all about. Looking back that was incredibly nieve. Like an episode of LOST, each new thing I figure out exposes all these additional questions that I didn’t even realize existed. There’s just no way to know EVERYTHING. So don’t try.

While I started this post with a plan for 7 realizations, it’s not an exhaustive list, so if you have something you have realized with your experience, please let me know in the comments. Also, I’ve been writing this blog for awhile now, but I’m curious what others think of my writing, so feedback of that sort is greatly appreciated as well.

Feb

2010

Don’t Forget to Ask Why

As programmers we are constantly worrying about the ‘hows’ of things.

How am I going to make this function faster?
How can I write this query without joining 16 tables?

More often than not though, when writing code we forget to ask the really important question, WHY? We take instructions from our clients and users and immediately get to figuring out ‘how’ we’re going to make it work. We plan out how we are going to set the IDs for our DIVs and whether or not we want to use jQuery to make it work. We get so excited to dig in and start writing code that we forget to ask that critical question to figure out why we need to write it in the first place. Perhaps the reason that your client is asking to change the colour of a block of text is actually because the page layout doesn’t make sense for the situation. Maybe they think a help button is needed next to your feedback form because your form labels aren’t making it clear what you’re asking for.

Sometimes the answer to ‘Why?’ will be an unjustified ‘Because that’s the way I want it to be.’ The thing is that is totally OK, at least you asked the question. There will be plenty of other times where the answer will reveal a deeper issue, and it’s sometimes even easier to fix those instead of making the change that was requested. Which as a programmer, should appeal to your genetic desire to get more done by doing less.

So go ahead, the next time you get a change request, ask why, the answer may surprise you.

Nov

2009

The attack of the zombie hard drives

I don’t know what has been going on with the world lately, but being the only computer guy in my close group of friends with an IT support background definitely has it’s down sides. Since August I have experienced 5 catastrophic hard drive failures. I wish I could blame them all on one common factor, like bad firmware or something, but I simply cannot. The drives were of different ages and from a variety of manufacturers and system builders. Only one of these drives was mine, the rest belonged to friends and family. Care to take a guess at how many of these drives were backed up?

Zero.

Luckily for me, my drive that failed was in an external enclosure and was only used for backup anyway. The rest though, were the main system drives from my friend’s primary PCs. I was able to get most of the data off of one of them, but the other 3 were completely toast. Based on the look that shows up on people’s faces when I tell them that I can’t restore any of their pictures or home business files from a failed drive, I might as well be a surgeon informing family of an unfortunate surgical outcome for a family member. It’s absolutely gut-wrenching. I don’t wish it on anybody.

I’m a firm believer that if your data does not exist in at least 3 places, it doesn’t exist at all. Burning DVDs of pictures or copying them to an external hard drive are great, but you need to have a copy OUTSIDE of your home as well. The method that works for me is that I have an external hard drive that I leave in my desk at work, every other weekend I bring it home and copy my data onto it. Monday morning I put it back in my desk at the office and I feel much more protected. Some people like to ‘cloud’ option as well, however with Cogeco having a 60gig per month bandwidth cap, it’ not an option for me (my backup drive is almost 200gigs.)

Really though, I don’t care how you do it, just BACK UP YOUR STUFF!

Jul

2009

Diving into iPhone development

After many long months of decision making and cash saving, I have finally decided to dive head first into the wonderfully complicated world of iPhone application development. It is something that I’ve had in the back of my mind since I first got my iPhone almost a year ago, but at the time with my wedding and everything I wasn’t in the market to get myself started.

The first step on this journey involved me purchasing my first Mac ever, the 13″ Aluminum MacBook. I was tempted to go with the Mac Mini instead, however for the money the MacBook just offered too many advantages.

I have to admit, after giving it an honest shot, I’m really starting to like how OS X does things. It definitely isn’t perfect but it is a refreshing change for somebody who has been looking at a Windows desktop for the last couple years. The mental workflow took some getting used to, though I’m now feeling nearly as comfortable on my Mac as I do on my Windows machine, with only a couple of exceptions that I don’t need to get into during this post. Maybe some other time.

So far I have really liked the Xcode development environment as well, like everything else on the Mac, it just takes some getting used to. Before you know it everything just makes sense. Even though I’m sure there’s a ton of stuff included in Xcode, it all sort of hides in the background instead of being right in my face and adding to the confusion. I was able to build and execute a simple iPhone simulator app very quickly without having to resort to a tutorial. I’ll admit that was a pretty exciting moment for me!

I still have an absolute TON of things that I need to learn before I start releasing stuff on the iTunes App store, but I’m going to do my best to document what I learn as I go. I’ll also try to point out any useful resources that I find along the way. I’m sure there will be plenty of surprises, it’s all very exciting!

Wish me luck! Hopefully I don’t suck at this…