As a developer...

Working with software all day, I come across all manner of poor (and great) software packages. Some are robust, some are fast and lightweight, some are the complete opposite. Here is a great article on what it means to program a robust piece of software (from who else but the Linux information project): http://www.linfo.org/robust.html. Producing software that is fast, lightweight, easy to user and has few (or no) bugs in it is what we (developers) are all trying to do, and this definition of robust, really reminds me of where we want to get to.

Something else to keep in mind when programming is that I need to ensure that these pieces of software that I am producing need to function, and function well – it is in the nature of software to have bugs. We are expected to produce more and more complex applications (especially web developers where requirements for web applications are getting much more like desktop applications) and as such program bigger and bigger code bases. This in turn leads to less manageable code (by it’s very nature, large code bases take more time/effort to manage) and more potential for bugs. Proper QA (qaulity assurance) can mitigate the issue of bugs, but creating structured user and QA testing takes a lot of time and time is something that as a professional developer, I don’t have much of. More worryingly, is that creating large programs with less time per functional element leads to less robust programs and more hacky code – the opposite of what I – as a developer – am trying to achieve.

As a developer, I am always looking for better ways of solving problems. Sometimes, I think I am doing something the right way and go about building a little (or large) framework, to reuse and refine in future development. More often than not, when I go back to some piece of work I have done in the past, I end up cutting it right back and making it smaller, faster and more manageable than before – why is this? What is it in my head that makes me think programming something with everything is a good solution. I guess I am trying to create that all-encompassing solution to the problem that will allow me to never have to program a similar thing again to solve it.