I've stumbled into a habit of late, something I can't stop myself doing, which I've never really done before... I'm parallel processing... Since 1989 when I became more aware of the internal workings of my Atari St, and the way it did one thing at a time for me I've always worked the same way. I used to write softwatre that way, picking up a component, designing, writing, testing and documenting it in sequence.
But, I found that as my software projets have gotten bigger and bigger I needed to be able to put parts of things together, slide in other parts and then go back to sew things together. This started out small, but in a current personal project I'm working on its a sprawling documented seething group of about 110 classes (and counting).
Concurrently running through each module in turn, going back reading my notes and reviewing each, incrementing and incorporating innovation from one place through the body of the whole project.
Its turning into a bit of a quality kicker for me, my personal software projects are far more higher quality than the ones I'm writing for my employer, simply because my employer don't really seem to see the point of my spending four weeks to do a task which they think should take one.
I myself however am reaping the benefits. My current software project is, unfortunately, about four months behind schedule and had a bit hiatus between June and July as I re-wrote vast swathes. But things are quieter now, for example in one day (with the improved quality) I was able to replace a major components of the display systems and rendering threading in a day... it should have taken at least a week alone, just to get a coloured screen to display. Instead, because of the quality of the underlying code I was able to get this feat of engineering done in less than 8 hours and had it integrated on my three test boxes for soak testing after 10.
The question is, how do I sell this contept to my bosses?
No comments:
Post a Comment