Search This Blog

10.28.2012

The Beauty and Wonder of Programming Specs

Bit of a work rant. I'm not trying to use this as a whine-fest, although it'll sound like one at points. Take this more of a case study or illustrative, anecdotal example of why it's proper practice to write out a formal specification for your developers.

There's a project I've been working on for 9 months now; I'm not sure if I've mentioned it, but if I have it's the pricing update program. Anyway, this was originally slated to be a 6mo project. Well, obviously, it hasn't been. Part of the problem has been, I'm learning Flashbasic (Pick/Basic, whatever) as I'm writing it. So that's obviously going to make things take longer than if someone experienced in the language is working on it.

 However, I'm getting ready to put it into testing for the 3rd time here in the next week or so. Why? I had no specification to work off of. All I've had to go by is a couple meetings with the heads of the involved departments, and streams of emails back and forth. Plus the input during the previous 2 demos/tests. Neither meeting was that enlightening-- the first one got bogged down in minutiae and was more confusing to me than explanatory.  I took down some notes, and ended up with something that got completely rejected when I called the second meeting.  However, that was all I got out of the second meeting: what you're doing won't work, it's too unlike what we're doing now and generally wrong anyway, but the current way of doing this is still terrible.  I cobbled together something based on what I could glean from the second meeting and from what I was learning on my own from the way pricing currently works.  Then I demoed it.  It had a lot of flaws, was missing a lot of features, there were a lot of miscommunicated aspects.  I took copious notes, learned that the department head I hadn't consulted with so much a) had taken on the duty of updating pricing and therefore needed the project more than the other department did, and b) he was more analytical and demanding, and therefore easier to hammer out the program with.  Cue the storm of emails back and forth on what was needed where.  Got a mostly workable version, demoed it again, except for a major missing feature it was great.  Now I'm finishing that feature and reworking the program flow to shoehorn this whole extra step in, and hoping it'll fly (it's necessary still to edit the spreadsheet, just not to the extent it was the last time I showed them the program-- they want to do 0 editing.  This is not possible).

Note all the miscommunication, poorly stated needs and goals, and tendency to leave how to write the program (and therefore alter the business processes surrounding it) to an inexperienced programmer who has never had anything to do with that aspect of the business, and never will on a daily basis.  Note how much time was wasted simply trying to get information and input from the people who will be using it every day for the rest of their career with the company (theoretically).  This could have been avoided with one thing-- a program specification.

Even though my classes in college were theoretically all intro classes (although you could get more out of them if you put more in, as I did), we were taught to work with specs.  In Linux Administration class,  Netware Administration, C Programming, Java Programming, Security, Forensics, all the electronics classes (DC/AC Circuit Analysis, Semiconductor Applications, Digital Electronics, Intro to Microprocessors), even the first semester classes like Computer Repair and Survey of Operating Systems-- they all dealt with both writing specs, and working from one.  With a proper spec, there is no question of what needs to be done.  Everything is laid out, from the current process, to what is broken about the current process, to what needs to remain the same with the new process, to the new process.  Even if the new process is a proposal, it still gives the programmer, who does not and will not work in the department that needs the program they're tasked to write, a starting point to work from.  And in the meeting about the proposed spec, there can be discussion over what is possible, what the needs are, etc.  Rather than everyone just throwing up their hands and asking "well, what do you think it should do?".  I was, in fact, asked by the less-analytical dept. head that exact question.  That was the point I threw up my hands and called the second meeting, so her boss and my boss could provide us some guidance.  Had there been a spec prior to the first meeting, much of that back-and-forth wouldn't have happened, and much of my time (and everyone else's) wouldn't have been wasted.

Unfortunately, and this is where it gets a little whiny again, I've brought up the suggestion (during the first demo) of writing a spec from now on.  It was met with total resistance.  So right now I'm basically... how shall I put this politely?.... whistling in the wind, as far as applying this to myself.

But maybe this can be an example to someone else, and save them the heartache I'm relegated to.  However, this experience has taught me a lot about my coworkers, and working with them on designing programs.  And hopefully taught them a thing or two about working with the programmer who hasn't basically built everything from the ground up, or rebuilt it for the company's needs, for the past 15 years.

I'm just really looking forward to the end of this project, and to move on to other, more interesting projects I have lined up.