Development tactics : phoenix development cycles [closed]

Question

I was wondering how you guys actually develop large applications when you are your own boss. For myself I have been learning the hard way the necessity for patience and hope. I have been working on implementing an application (in the form of a series of scripts linked to a database) that clusters Wikipedia articles using a combination of knowledge of Wikilinks and article text/content. I have been at it for two years now; no results yet.

I cant seem to get any results for I am continuously reengineering my scripts and db due to changes in either the essence (pseudo-pseudo code, the theoretical algorithm) or form (script, threads, db tables, the practical algorithm) of the algorithm. Basically, I find myself continuously learning from the mistakes I discover while implementing; the devil being in the details, so are the answers it seems.

Anyway, every time I reengineer a script or a table or something, I need to scrap all my documentation and script. I am now able to do this without fear, but it has made me hate programming (I hate the details).

I feel that reengineering is the way to go since I am thinking long-term and I wish to learn fast, but I am wondering if you guys have a similar programming experience or if you never really need or choose to have a better script come out of the death of the last one (like a phoenix).

The hardest part for me is scraping my documentation for I spend more time documenting than coding; I use documentation as a means to discuss issues and consider solutions; I use it to formulate implementable solutions. While if it would be but for me, I would not mind scraping it, yet I always write it as if it were to be published the next week for while developing a script, I also seek to develop myself; I also try, like those of you who participate to this website, to share my knowledge or wisdom with others.

Anyways, I have been developing at full speed these last 2 months, reengineering countless essays, scripts, tables, etc; my patience is running low for I seek results.

Any tactics, any help, any experiences or anecdotes you wish to share?

Answer 1

A good motto in programming is 'be willing and happy to throw everything away at least once', usually more. I'm currently writing a complete shell from scratch for a new operating system and I'm about to completely scrap part of the design, I don't like how I'm handling built in commands vs loadable modular commands.

It sounds like you dove in, head first .. excited to get some code written. From what I gather, you did spend some time with pseudo code (I even use a big dry erase board) to determine the structure of your code .. but the code was not able to survive radical changes to said structure.

There may be some good reasons why you're working completely isolated. If its possible, as others have suggested, bring someone else in who understands the end result that you hope to accomplish and hammer out a new design. Keep in mind that you application has proven to be quite volatile, the new design should not make you throw everything out because a few things changed.

I think you're also falling victim to what is known as premature optimization. Try to get something put together that works, even if its horribly inefficient and clunky, then really spend some time looking at how things can be improved. This step is almost a precursor to a new design that could survive radical changes in the future. If you can't bring someone else in, a working model of your current mistakes is almost as good as another collaborator.

Answer 2

keep a development log; this is the place to discuss details with yourself, work things out on paper, sketch documentation, make notes about current and future issues, remind yourself what you've tried and what you have left to try, and so on. It's also a good idea to always note what the 'next thing to do' is, so you don't waste time remembering/reviewing when you have time to work on it. Date each entry.

i have used this approach on a number of long-running, sometimes frustrating, one-man projects of durations varying from a few months to several years, and it helps keep me focused and it helps keep me from trying something more than once.

It also eliminated the internal pressure to document everything, which might be of great benefit to you.

think of it this way: notes to yourself about what you've done are useful to you, but detailed documentation intended for third parties for code that gets scrapped is a waste of your time.

Maybe this will help your OCD documentation neurons to shut up so you can solve the problem completely, then document the working solution - instead of continually re-documenting the latest prototype.