Developing on a small scale

When you are developing software by yourself, you can skip through an awful lot of the software design process.  Model-driven development, peer programming, code reviews, documentation – they almost have no meaning when you work by yourself.  Half of traditional software design is figuring out the right approach for the task – getting it to work, scale, perform, be flexible.  The other half deals with communications – how to subdivide into person-sized tasks, provide clean interfaces between tasks (and people), making sure the understanding of how things work is shared among the developer group. 

Inherent in the concept of a one-person project is the scope of the project.  We are not talking about code that flys the space shuttle, we are talking about code that performs a single business function. 

The worst job I ever had was working on the set-top box for a cable TV company.  You wonder why your cable bills are so high?  There were about 30 software developers working on the code for this single-processor box.  The software tasks were so deconstructed to be able to spread them among the 30 people that the tasks became meaningless.  Some functions just can’t be subdivided.  Ultimately, the real work was all done by 6 people.  The rest of us wrote bells and whistles that would never be used.  I earnestly slaved away implementing my task.  If I was smarter, I would have written a quick shell, said “This works”, and spent the rest of my time doing whatever I wanted.  We didn’t have desktop Internet in those days,  so it was a lot harder to goof off.

I have been thinking about the State pattern lately.  A class for every state, calling back into the controller to perform tasks – maybe.  It seems extremely cross-coupled.  But if the state machine is on a small scale, the Big Switch Statement works well enough, and is a lot more clear and efficient.


Post a Comment

Required fields are marked *

%d bloggers like this: