Thursday, December 19, 2013

Releasing Your (Software) Projects...Self-Imposed Feature Creep

I've been working on my proof-of-concept VB.Net program for awhile now...

It started as a curiosity, a toe-dip into the pond of testing my rusty brain. I wanted to experiment with something that had been floating in my head a little while.

For the most part I got the core of the application down. It's simple. There's a lot of room for improvement, granted, but it was relatively simple. And I really need to test it out, once I get one more piece of behind-the-scenes functionality implemented.

See, that was part of the problem. Even though this was supposed to be a neat little proof-of-concept test application for me to take a concept and make it work, I still ran into bumps where I ended up wanting to tweak it a little more. I only worked on it a little bit at a time; usually an hour or two after work a few nights a week. Which isn't optimal for the way my head works. I usually need a large block of time dedicated to sorting through a problem and figuring things out; but if I wanted to get to work in the morning feeling like more than a zombie, I had to get to sleep at a decent time. So that kind of limited my time spent on the project.

Then there is the podcast. I currently spend an hour recording, around the end of the workday, the audio material. Then I typically spend an hour and a half to three hours total going through the material, editing it, taking notes, and getting it posted to the feed site on Tuesday so it will be available to my meager audience on Wednesday. That takes about two nights off my "available for hobby" schedule.

Every time I got close to feeling like, "Eh...it's good enough for government work..." I come up with one more thing I want to investigate or tweak. Some design ideas I abandoned from what I originally had in mind...usually because of time, or the thing I wanted to do just wasn't of high enough priority to make that particular item worth pursuing.

Little tweaks kept calling me, and given that I'm rustier than the Tin Man after a rainstorm, it takes me longer than it should to put a tweak in place. I'm even more handicapped when I insist on doing it in discrete blocks of time after work a few days a week. It was supposed to be a small proof of concept thing...not a full on project!

Thus was another lesson in software projects. Without the mapping and specs pre-mapped, as I've mentioned before, you end up feeling like you need to keep altering and tweaking the program ad infinitum. You need a set of goals lined up so that at some point, you just say, "It's done." Maybe it's not really done, but it's met the spec.

Of course part of it is, no doubt, embarrassment at how it would be received, since no serious programmer uses VB.Net (of course.) I'm not entirely sure why this is, since .NET languages largely compile down to a common language runtime (which is the whole point of .NET as I understand it...) so...maybe it's a fear of the culture. A side effect of working with smart people is feeling like you're always one or three steps outside the pack.

I need to move on to one of the projects I've been wanting to use for learning Ruby, which means I needed to come up with a deadline to stop this current experiment. I decided that there is one last thing I wanted to try to get working, and after that is finished I'd show it to my manager for a bit of a constructive criticism. My deadline will be the new year. I'll take my system home with me over the holiday and work on the last feature, then come the new year send it his way to have a look.

It'll be a mess, no doubt; I have no illusions that it did things "right" all the way through. I really should have focused on using classes to implement part of it rather than my mangled hard-coded approach. And there are definitely parts that could have used more error checking.

 On the other hand, it was the first time I'd approached a programming project in some time. And the end result was that the basic idea, the basic functionality, worked. Given more experience and time it probably would turn out better. I really need to keep working at it to develop better habits and solve more problems, and I need to move on before everything becomes an excuse to procrastinate. Then nothing will get accomplished.

To try keeping myself on my self-imposed deadline, I asked my manager if he could take a look and offer some constructive feedback come January; having someone else know about it might help keep me on my timetable. So there it is. Over break, I'll spend some time polishing it slightly, then test it out, then have it reviewed by someone in a position of experience to tell me how full of blech it is.

Then I can move on to the Ruby tutorials and create a whole new type of blech.

No comments:

Post a Comment