code, development, difficutly

Development: The First Development Difficulty - Effort Sizing

I am starting my next personal software project now, parsse, and I want to share some of the difficulties with software development along the way. I recently read Dreaming In Code which cronicles the many short-comings on an effort to code a single project (fantastic book; appropriate for non-programmer types) and expounds on development problems in general.  I also started professional development work.  This has all got my brain churning so allow me to think aloud.

One of my personal struggles with any software project is how much engineering should be done. It is often easy to bang out a Perl hack, a Java class, or a quick JavaScript/HTML solution to any problem. It is a bit more difficult to make it a slightly more permenate fix. It is challenging to make it fit for third-party use.

I often struggle with asking myself how to iterate fast and how to iterate expecting long-term use. Again, it is easy to hammer out a solution to a problem and difficult to never have to look at the code again — to make it perfect the first time.

Let me provide you with an example. Consider you have to write code to store an email in a file. The email must be stored in a standardized way so that future accesses to the file correctly read and interpret the contents. This code has two extremes by which to achieve it’s goal: trust the sender to send the email in the agreed standard or test and validate the contents before writing them to a file. Then comes the questions such as, “if I write the code that sends the content to this file-writing code, can’t I assume it’s always going to be perfect? I obviously write the easier of the code.” Well, not exactly, you may have to open this code up to a network for read/write access to these files.

So for every fork during development is wrought with trade-offs like these. What this means to a developer is you never know if you are engineering too little — wasted initial effort — or over-engineering — wasted final effort . You want to know who gets it right? Just look to the authors of the software you use everyday.