The Easy Stuff is Hard

In my daily life, I pretend know a little about matters related to software development – mostly on the technical side. But like most developers I know, I strive to be better at what I do – developing enterprise software applications. Documenting the learning process is a part of that, that’s why I decided to start a blog.

This blog is an attempt to capture some of those otherwise fleeting thoughts that I have during a working day and expand a little on those. So this blog is mostly concerned with software development, version management, QA, methodology, etc etc.

So where do I stand professionally? Well, here’s a list of software development statements that I adhere to, not in any particular order, and I should say I rather steadfastly hold onto some of them, but not all.

• Scope is important: when you’re fixing a bug, it’s not necessary to ‘fix’ problems with other parts of the code. Try to find the easiest solution. It’s not likely that you will get paid for the work, and, more importantly, with new software comes new bugs – you might introduce more problems than you think.

• Design time is cheap: think ahead. If you’re somewhat experienced, you should be able to anticipate problems before they happen. Use that experience by thinking a little more about your design & architecture at the beginning of a project. If you end up maintaining the application yourself, you will get this time back. If you don’t, you will get back a lot of user satisfaction.

• Isolate your stuff, achieve flexibility. Don’t assume you’ll always have one database at a fixed address. Maybe you don’t want to do load balancing now, but at least allow room for it in your design and architecture.

• Test your stuff, and moreover: make it test-able. Anyone experienced with unit testing or TTD will tell you that adding unit tests onto existing code is hard to accomplish at best, and usually impossible without going through the pain of major refactoring surgery. Also, go for good coverage. And then still, 100%  code coverage is nice, but says nothing about the quality of your  tests – you may still be testing only within your best known scope.
  

  Initial speed may slow you down in the end

• Pay respect to the database. Databases are the backbone of your application. Nearly everything of what a web app does at some point touches the database layer. A slow database, or even a few slow tables can break your end user’s experience. Nobody likes a slug. It’s nice to have a framework that helps you with accessing the database. But it should still allow you to manipulate database schema and, if necessary, SQL queries. I can’t tell you how many times I’ve seen inefficient queries generated automatically from a database access layer, and that includes stuff I wrote myself, too..

• If anything sounds familiar, it’s probably because it is familiar. Object orientation has been around since the 1960s, design patterns were first done in the late 1970s. Agreed, aspect-oriented programming is relatively new, but basically these and other recent innovations are basically variations on older ideas. It feels like we’re in a lull now, awaiting the next huge paradigm shift or innovations. In the meanwhile, it’s up to us – meaning developers – to bring the tools we have to perfection.

Oh, and UTF-8? Yeah, you want to have that. Believe me. And please don’t say “it’s only a local application”. Your manager will be really pissed if you tell him the same three years from now, and he has to explain this to the sales team.