March 30, 2011

Software design is about iteration, not perfection

Kevin Hallmark @ 1:07 pm —

Over the years, I’ve learned some fundamental things about software development. Writing perfect code with a perfect design is a fools errand. Perfection used to paralyze me. These are some principles I use to help me make coding decisions.

1. Don’t rewrite your application. Ever.

This explains it better than I ever could.

2. DRY – Don’t repeat yourself

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

While it can apply to data sources as well, I am applying this to ┬ácode itself. Every single line of code you write is a potential bug. You should strive to write the least amount of code possible so you can depend on “known working” code.

If I need to get a record from the database, I can either write the select/execute call every single place I need it. This works for one off calls, but if I need to get that more than once or twice, a function is a better choice. I won’t have to worry about making a mistake each time I write the code. This is a contrived, but relevant, example.

3. YAGNI – You Ain’t Gonna Need It

“Always implement things when you actually need them, never when you just foresee that you need them.”

Simply put, if you don’t need it today or tomorrow (soon), don’t write for it. Maybe put a little underlying support code in, but don’t implement it until you have to. It takes time to add code, debug it and document it, time that might be better spent on more pressing features. If you add the feature too early, you need to support that bloat. If you need to refactor, you are refactoring more code. You have to make sure it doesn’t break.

After all that effort, you might even find that you don’t need the feature (ever), or you need something slightly different. The way you implemented it might be mutually exclusive with what you actually need. Adding it before it is needed might actually make you unable to implement a feature you need, or may lead to an incomplete implementation.

A good example is scaling. Why would you write software to scale your servers when you aren’t even using the power of one? Why write some awesome abstraction when it’s not going to be used by anything?

4. Three simple steps:

  1. Make it work
  2. Make it fast
  3. Make it pretty

I used to worry about the perfect application. I wanted everything to be the creme de la creme design. Unfortunately, I found that I never actually wrote the application. I got stuck in the design and never built out all the features I needed.

In a time crunch, you need the code to work. It doesn’t matter if it’s fast or pretty, if it doesn’t work it’s worthless. Usually, I can make it fast enough with iteration one, but as a system grows you’ll need to make things faster. As each pain point in speed becomes apparent, whack it out. Eventually, you’ll discover where you need to optimize. Finally, making it pretty by identifying code duplication and eliminating it where needed.

These principles have helped me write better software. I hope they help you too.

December 10, 2010

PHP is falling apart (or Why we need ‘finally’)

Kevin Hallmark @ 11:58 am —

PHP is crumbling.

PHP 6 was delayed for years and now sits abandoned as they restart the effort. In the meantime, a bunch of features are being backported to PHP5.x branches. Each new 5.x release has more features from what would have been PHP 6. PHP is stagnating.

The PHP core team has fallen apart. There is no leadership. There is no guidance. There is no logic. There is just a cobbled together release of miscellaneous features that are somebody’s baby.

For example, ‘goto’.

‘Goto’ should not be implemented in any modern language, period. It’s not needed. Yet, PHP chose to implement this in version 5.3! The reasons for adding this were dubious at best, showing a lack of language design skills. You can read all about my opinion on goto here: http://www.littleblackhat.com/blog/2009/11/php-5-3-and-goto/

I recently found this little gem on the php website: http://bugs.php.net/bug.php?id=32100 (thanks @lesmothian).

The best (and only) comment we get about why there is no ‘finally’ block is “We’ve had long discussions and came to the only conclusion that we don’t need that, for more search the mailing list archieves(sic).” Of course, that conversation can’t be found in the list archives. Does that matter? Of course not.

Finally is part of many modern programming languages: Java, Javascript, C#, Ruby, Python, Objective C, Perl, VB.net… the list goes on. Many of these languages and their designers abhor ‘goto’ and praise ‘finally’.

The use cases for finally assure proper memory management and resource deallocation. Without it, the chance for a mistake in control structure flow increases significantly. Additionally, unless I reraise the exception, it short circuits my app wide exception handling code. Reraising deletes runtime information about the source of the error.

Finally results in cleaner more reliable code. It should be implemented in PHP.

This essay only touches on the idiotic decisions of the PHP team. First ‘goto’, now ‘finally’. Suffice to say, I am getting less and less attached to PHP by the day. I hope that one day the php team gets some leadership again.