Development

The Myth of “Good Code”

There’s an interesting dichotomy in software development – anyone wh has spent any amount of time in the field knows it all too well. There comes a point in every project where you have to make a choice – good code or fast code. Sure, you’ll get those “sweet spot” projects that’ll let you work on the “good code” side of things for as long as you’ll need (maybe a personal project?) but more often than not, you’re going to fall on the “fast code” side of the line. It’s sad, really it is.

Every good developer knows that the world could only benefit from having more “good code” in the world. Applications would not only do what they’re supposed to to but they’d do it well and have better performance while doing it. Things would flow smoothly through the paths the user laid out in the planning stages and everything would be magically delicious. Right? Sadly, even when you have the time to make the “good code”, it’s still not that good.

First off, throw out those personal projects – the timelines of those don’t really apply anyway. You can hack away at a framework you’re developing for years and only get most of the way done with it. Unless it gets some kind of larger following, chances are people aren’t going to be putting the pressure on you to make updates and add new feature. The whole realm of personal project timelines is an interesting one – maybe something I’ll look into later on. For now, though, we’re going to focus on software someone else wants you to write. This is where the major part of the problem is – it’s someone else’s timeline, someone else’s thoughts you’re trying to put into code.

I can’t tell you the number of times that I’ve been working on a project and have hd nothing but the best of intentions of how it was going to turn out. I’d planned out the pieces, worked up descriptions of the objects involved and laid out how they’d all integrate together. The code was well-structured and was something that could be both easy to maintain and simple to expand – that is until the customer decided to get involved.

If you’ve worked on any kind of larger project for any length of time, you know the cardinal rule – the customer never knows what they want. Even when they say they do, show them a demo. Their minds will freak out with new possibilities and new features that were never even conceived of in the first versions you’ve developed. Now, this isn’t so much of a problem if you have the customer/client reined in to keep these sort of things under control, but if you don’t…let the bad code pour in.

It never fails – at least one of the new features that the customer proposes as a “strongly like and might need” for this version will go against the code that you’ve already written. I don’t think I’ve ever heard of a project that was able to augment what they were doing mid-stream (yes, even you agile folks) to accomidate every request the customer could make. Some things are easy, but most of these sort of changes are hard.

This is when it gets very hard to keep that “good code” in place. It takes a lot of practice and skill to keep things flexible enough to make the impact of these sort of changes minimal. Writing good code from the beginning is easy – making that good code stick through to the end is hard.

How hard are you willing to work to keep that code good?

Photo credit snappED_up

Complacent Developers Suck

We’ve all been there – we’ve reached the top of our current skills. We’ve met every expectation and conqured every issue in front of us. We are masters of our domain and no problem seems too difficult. This is the worst position you can be in. No really, trust me on this one. As soon as you become complacent in your practices, you’re doing something wrong.

One of the key things that separates great developers from good developers is their capacity to learn. Good developers will learn how to do something and know it well. They’ll be content in their knowledge of how to debug a script a certain way or refactor their applications to follow a pattern they know well. Great developers, on the other hand, take that next step and grow. They leave their comfort zone in the dust and look to the future to find out how they can conquer the next hurdle in an elegant and constructive way. They’re the ones constantly improving themselves, working to make themselves and their code a better place to work and play. They see challenges in their development as things to innovate around not just as problems to solve with a certain equation. Their joy is in flexible, resilient code that can adapt to any situation and can make not only their lives simpler but the lives of those down the line easier and less complicated.

Innovation is the key here – any developer can cut and paste examples from other website to make things work. In fact, there’s a whole crop of developers out there that do nothing but this. They don’t innovate, they don’t learn – all they do is take the information they find and regurgitate it back into their code. As you can imagine, this is a very, very bad practice and can only lead to code that’s both difficult to maintain and hard to extend.

Be careful – don’t let your past accomplishments make you lax in your development. It’s easy to fall into the trap that successful code can lay. You see things working and the code seems solid so you go along your merry way and do the same on future projects. The only problem with the situation is the innovation – no two software projects are the same and no matter how similar they seem to be, code without innovation is no code at all. You learn something from each implementation and this new knowledge should be applied to every new project you encounter. Reusing code is good, updating it to reflect the knlowedge you’ve learned is even better.

Don’t be complacent in your development – learn, grow and use this knowledge in your future development. If you don’t, you’re only hurting yourself. Learning is good, applying is better. Constantly learn and innovate. This is the only true way to be a better developer. Period.

Search or Settle?

Let me start by posing a question to all of you other groups looking for PHP developers right now – should we just settle?

Sure, I’d love for that perfect candidate to come walking through the door, shiny resume in had that fits close to what we need (no, I’m not naive enough to think they’ll be perfect). We could sit there in the interview and he or she could give all the right answers in all the right places. The choice would be easy and, with a few shaking of hands, the deal would be sealed.

If that’s your impression of hiring a developer, you’re in for a serious kick in the shins by the software development industry. Right now (and it seems especially right now) finding good developers is even harder than the needle in the haystack trick. I’d go so far as to say that, for the parameters that most companies can afford, there’s almost no good, skilled developers out there – the real problem there being that pesky S-word.

If you’re not at all concerned about code quality or serious development, by all means hire the next interviewee that walks through your door. Don’t check his criteria, don’t look at his experience and by no means ask him any questions about how many years he’s been developing PHP. Now, a skilled developer, on the other hand, is something that should be sought after and held onto as long as possible. They’re the ones that will think about the structure of the code they’re writing and continuously look for ways to improve the application. As I explained it to a coworker of mine:

“You want a developer, not a hobbyist.”

I’m not saying that kids fresh out of school (or whatever) are to be discounted because they don’t have much development experience. I will say to be careful with them, though. As anyone that’s worked in development can tell you, there’s just that “something” you can see in the eyes of a developer when they talk about the technology they work with.

So, back to my dilemma – how to find a good developer in a wasteland of good talent. After a few interviews with widely varying candidates, I’ve been getting a bit more discouraged, but I just have to keep reminding myself of a few things:

Don’t be too picky (except on the important stuff)
No matter what the resume makes you think, don’t assume
Remember your roots, assess them based on theirs
Don’t settle.

Yes, I know I’m sort of answering my own question, but that doesn’t stop me from asking it. You go through enough applicants and your have to start wondering…

“Done done”

As I’ve been reading through “The Art of Agile Development” (from O’Reilly, by James Shore & Shane Warden) there’s been a whole load of great suggestions for development practices and not all of them are restricted to an “Agile Only kind of world. One of the major ones that’s stuck in my head (and is repeated quite a bit in the book) is the idea of being “done done” in your development.

The average PHP developer seems to say they’re “done” when the code works from their simple testing, usually just entering values to ensure that things work correctly. I hate to break it to them, but this shouldn’t be considered done. Getting the code working correctly is only the tip of the iceberg – there’s so much more to do to get everything ready to deploy. Besides the code being complete, “done done” also means:

Having documentation, both in the code and about the code. If future generations of developers were to come around and need to update your code, good documentation is a must. One line comments aren’t going to cut it…at the very least use something like the formatting for phpDocumentor to provide some automated docs
Making those unit tests pass every time is essential. (You do unit test, don’t you?) Writing tests for all the bits and pieces of your application may be a pain, but it can save you in the long run. Imagine being able to fire off a test suite and being confident that those changes you just made haven’t broken anything.
The code has to work in the build for your project. Some projects are small enough to where they don’t really need a build, but if your project is much more than a simple site with a database backend, you could benefit from a build[1]. Developers should be able to do local builds to check their work prior to a commit and push.
I must fulfill what the customer wants in the update or new feature. Sometimes, it just happens – you get to writing your code and you think about “this one cool feature” or “that other fun thing” that PHP makes so easy. You wonder why the customer didn’t want that in the first place. Be very careful with thinking like this, it could lead to some pretty random stuff in the end. In the end, the customer needs to be happy with what you give them – be sure it’s what they asked for (user acceptance testing).

Being “done done” means that, if you handed over your code to the testers or even the end customer, you’d be confident that it works and is ready to be integrated. Sure, it’s about the code being tested and correct, but its also about making it behave as a part of the larger whole. Your code (code ownership is a whole new can of worms) shouldn’t be viewed as “this part that does this” but more of a piece to the larger puzzle of you/your team’s application.

[1] What’s a build? A build lets you automate several things you might currently do by hand to get your code ready for production. This can include things like: building out databases, minifying code, running unit tests and checking syntax on all files to be pushed.

Working with WebTests (Help?)

Well, I wish I could say that this was going to be a guide to getting WebTests (an automated front-end testing tool that sits on top of Ant) but it seems as though I’m having a bit of a Java issue to content with myself.

Here’s what I’ve done so far:

First, I noted happily that Ant was already installed on my MacBook’s OS X install (seems a strange choice to have bundled, but who am I to judge), making for one less thing that I’d have to get up and running
Next I grabbed the latest install of WebTest from the Canoo website and unpacked it to a testing directory. It comes as a nice, neat binary so there’s no messy compiling to worry about.
I wrote up a simple test and PHP page to try it all out:
[php]

[/php]
Finally, I gave it all a whirl: “bin/webtest -buildfile /my/path/mybuild.xml

This is where I hit the first snag…apparently since OS X’s Java install is just a bit different than some of the normal ones, a few of the files aren’t where they need to be. In my case, I was getting an error:

BUILD FAILED
/www/tests/mytest.xml:5: 
java.lang.NoSuchMethodError: 
org.apache.xpath.compiler.FunctionTable.installFunction
(Ljava/lang/String;Ljava/lang/Class;)I

After poking around a bit on the web, I happily came across this that recommends copying a jar file over to the Java extensions directory. A simple “cp” later and the build made it past that point. Unfortunately, not much past it, though – another Java error popped up that seems a bit more difficult to find information on:

BUILD FAILED
/dev_tmp/webtest/webtest.xml:265: 
java.lang.NoClassDefFoundError: 
org/apache/xml/serializer/ExtendedContentHandler

So far I haven’t been able to find much that’d help me solve this one, so if there’s anyone out there that’s seen it before, help would be appreciated. It seems like it actually runs the test just fine (according to the output reports) but it’s not very useful if the build always fails.

Thinking Agile

Along with some of the fun new things I’ve been working on it regards to development and deployment, I’ve also been reading up on the agile development methods. I’m only getting started and I can already tell you – it’s not like anything you’re used to (well, unless you’ve already “gone agile”, of course).

Despite all of the hype right now around Scrum, I figured I’d get my feet wet with the agile concepts with Extreme Programming first. I’m assuming that most of the principles will be similar with varying implementations between the two. My “manual” of choice to get started with has been O’Reilly’s “The Art of Agile Programming” (James Shore, Shane Warden) and it’s been an eye opener.

See, I’ve come from a place where, I imagine, most developers out there are coming from and probably still will be in the future. You spend months gathering requirements, you estimate the times, you set the deadlines – all very structured and, depending on who you’re doing the work for, potentially wasteful. We’ve all experienced the frustration of changes to requirements set at the beginning of the project. Things tend to explode when someone changes “one small thing” and the entire development track is suddenly ripped into pieces and put at the complete mercy of what the customer wants.

In short, it sucks.

From what I’ve gathered so far, the whole concept behind agile programming is to prevent things like this. It makes it simpler to move around in the project and change things that might need changing. Work is done in sprints instead of one long development process and the client/business representative selects the things that will be headed into the next development session. Requirements are more fluid and testers don’t have to wait until everything’s done to find where things break.

I’m definitely still in the learning process, but so far, this agile process doesn’t seem half bad. I just wish it didn’t require such a large change in the processes of the surrounding company. I might be tempted to suggest it around my office…