“ I'd appreciate it very much if fellow monks could share into their experiences and why 'formal' approaches to 'software engineering' (e.g. requirements specification, functional specs, architectural design before actual 'coding' stage) are almost always guaranteed to yield better results.”</body>Well first off, think of it this way, imagine the same project without any of the above. Why would anyone expect this to work? Perhaps with a great deal of talent something could be salvaged, but it would be up-hill and against the wind all the way. Not that it doesn't happen this way in the Real World(™)—of course it does. But take the same crew and give them the advantage of actually designing the product, stand back and watch them fly!
I suppose it depends on your background, i.e. how you came to the art. You talk of yourself as a hacker or at least self-taught. And you certainly show some of the symptoms (many around here and elsewhere should seriously start a 12-step program real soon now), particularly your preference for 'code before design'. I don't think that is necessarily a bad thing, the most likely reason is that you simply love to code. I would recommend only a slight change in course, keep the love for coding, but explore the hell out of design. Design is your friend, think of it as an early warning system that can alert you to the presence of Bad Things! As it turns out, there is not a lot of difference between designing and coding. Just different pigments and maybe paper versus canvas, but it still is yet another form of the creative process and can provide a 'fix' just as powerful as a good hack any day.
I mentioned background as a strong influence on hackerhood. In my own case I came from an arena where 'design' was not optional, not required, just flat out mandatory. I'd spent a number of years as a silver-smith and not being independently wealthy, every commission required that the piece in question be spec'ed, designed and executed all on paper first. And at that, well enough to make the sale! Think of it this way, silver and gold cost way too much to whip up a piece on the off chance the client might like it. You might increase your chances of a sale with a good portfolio, but even that is just paper—photographic paper true, but still paper.
So how does that condition my own programming process? Well, not too surprisingly, quite a lot! I don't do renderings of screen shots, but one way or another, I usually know what the product will look like before I cut my first line of code. Occasionally I cheat, for instance, I have no problems with using VB to work out the entire menu structure before hand. And similar techniques to give as realistic a picture of the product as I can without having to actually build the silly thing before its time. But once it's firmed up, approved by the client and by me, then on to coding. And the really remarkable thing is that it is a good deal easier to code when you know what you are building. Not to mention faster! And did I mention guilt-free? After all you're doing it by the book, even those software engineers at ACM and IEEE would approve…
–hsm
"Never try to teach a pig to sing…it wastes your time and it annoys the pig."In reply to Re: Virtues of Software Engineering
by hsmyers
in thread Virtues of Software Engineering
by vladb
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |