Salvatore Iovene

Some­times, when cod­ing a one-person-project at work or for fun, each one of us has found him­self stuck at some point, and then the project even­tu­ally died out. Let’s have a look at some design and dis­ci­pline rec­om­men­da­tions that can help us achiev­ing our goal.

Who doesn’t have a dream hid­den in a drawer? Some of us coders have dreams about pro­grams about which we’ve been think­ing for a long time and per­haps never found the time to write. Now that we finally decide to set­tle down with it and write the thing down, we bet­ter not hurry. There are sev­eral com­pli­ca­tions that might arise dur­ing the cre­ation of the project and most of them can be faced deal­ing with two issues: design and dis­ci­pline. Let’s exam­ine some of the pos­si­ble issues.

Tech­ni­cal difficulties.

Not very unlikely, at some point of the devel­op­ment, we might find some obscure obsta­cles, imper­son­ated by a very tough tech­ni­cal issue. I.e., we might think that it just can’t be done. Well some­times it really can’t, but usu­ally it’s a mat­ter of tech­nolo­gies and the proper use of them. To address this kind of prob­lem, there are basi­cally two ways.

1. Read up.

   Once you’ve deter­mined what tech­nolo­gies you’re going to use, and what libraries, read up about them. “I’m going to learn them as I build up my project” is not a good strat­egy. You will prob­a­bly real­ize that those are not the right tech­nolo­gies after all, or that you’re not using the right libraries. Or, most com­monly, that you’re using your things in the wrong way. And that could be too late. This is a very com­mon case of project fail­ure. This is when you get to face an obsta­cle that seems insu­per­a­ble, so you’ll waste a lot of time, and even­tu­ally get unmo­ti­vated. Start read­ing the web­sites of the tech­nolo­gies and libraries you want to involve, then read their doc­u­men­ta­tion. You don’t need to read all the APIs of course, but at least you ought to read the tech­ni­cal overviews, the white papers and the gen­eral design per­spec­tives. Pos­si­bly, buy a book about them and read it. Of course this will delay the start off of your project, but that’s bet­ter than invest­ing 2 months in it and then have to trash every­thing. Typ­i­cal case involve start­ing a new lan­guage, or a new frame­work. If you’re new to Hiber­nate don’t expect to just start­ing using it read­ing the Quick Start Tuto­r­ial. Most things, espe­cially nowa­days, aren’t just about using them. It’s mostly about under­stand­ing the big pic­ture and know­ing what the right angle from which approach them. The details will always come after­wards. Never ever under­es­ti­mate the impor­tance and the power of a good book on a cer­tain mat­ter. After hav­ing read up enough, you’re ready to start think­ing about your application.

2. Design.

   Never fail or omit to design your appli­ca­tion (thor­oughly) before hands. It might seem silly for small appli­ca­tions, but it never is. Draw down a scheme of the main com­po­nents of the sys­tem, and remem­ber: always divide and con­quer. Start by draw­ing off a very big pic­ture of the sys­tem. Ask your­self what com­po­nents are involved, what tech­nolo­gies you’re going to use, what libraries you’re going to inte­grate. Once you have a clear and state-of-the-art idea of what the big pic­ture is, you can start adding details. You can plan your data­base, for instance. Start that by indi­vid­u­at­ing what the main com­po­nents are, and how they inter­act with each other. Then you’re ready to design the data­base in more detail, i.e. spec­i­fy­ing each field and rela­tion. That will also help you enter­ing more detail into the big pic­ture of your appli­ca­tion design. Start now con­sid­er­ing all the com­po­nents and their inter­ac­tions. Define the objects you need and the way they com­mu­ni­cate. Draw mod­els and objects, pos­si­bly using UML. Be very care­ful and see to it that your model makes sense. Glitches and prob­lems might (and should) already come up at this point. If your appli­ca­tion takes less than 6–12 hours to be designed, than it’s either very sim­ple, or you’re being super­fi­cial. Of course if we’re talk­ing about Hello World, then you don’t need that much design, but this should be clear already!

If you’ve taken care of all this, the odds are with you and there are very lit­tle chances of fail­ing for tech­ni­cal issues. Now it should just be about writ­ing the actual code and you already know that it can be done, because you read up and designed the thing properly.

Scat­tered code.

Although Spaghetti Code was The Way, some long time ago, Object Ori­ented Pro­gram­ming has now been out there long enough so that we all should be able to write decent Object Ori­ented code. Seri­ously, if you’re still writ­ing pro­ce­dural Spaghetti Code, you should really read some Object Ori­ented Pro­gram­ming books and start liv­ing in the present. If you don’t even know what Spaghetti Code is, chances are that it’s what you do, so Google it up. Hav­ing well struc­tured, lay­ered and main­tain­able code will help you write less code, write bet­ter code, and fin­ish your project sooner. This should come out auto­mat­i­cally from a good design, but it’s worth spend­ing some words. The more you are able to do the fol­low­ing, the bet­ter your project will go on: write a class, double-check it, test it, never touch it again. This is the divide and con­quer par­a­digm. Once you have some parts of your project that are actu­ally fin­ished, you will find a lot more moti­va­tion in con­tin­u­ing. Hav­ing to con­tin­u­ously mod­ify parts of your code, going back and forth on those changes again and again, is not only frus­trat­ing, but dam­ag­ing the very struc­ture of your project. I’m sure you have run through more that one ses­sion of “refac­tor­ing” your code. Mov­ing pieces around, redesign classes, putting order, etc. This means that you’re wast­ing time that you could’ve used on adding new fea­tures or get­ting close to some­thing that’s releasable.

Lack of deadlines.

Even if you’re work­ing alone on an hobby project, set your­self dead­lines and a roadmap. Reserve your­self some time each day in which you can work at your project. If you already know what ver­sion 0.3 will have, and what ver­sion 0.4 will look like, it’s more likely that you will stick to that. Give your­self small objec­tives and fol­low them, one after the other. Don’t push your­self too much, though.

Lack of professionalism.

This is a very impor­tant point, even though you may think it’s not. Even if you’re work­ing all by your­self, whether it is a work project or a hobby one, always be pro­fes­sional. Remem­ber the fol­low­ing rules.

• Use a source ver­sion­ing sys­tem.

  I don’t care if it’s CVS, SVN, Darcs, GIT or one of the many out there. Use one. Com­mit your work and keep track of the changes. This will not only help you not lose impor­tant code, and keep your work traced down cor­rectly: it will also give you dis­ci­pline and moti­va­tion. Read some best prac­tices for SVN and other ver­sion­ing systems.

• Use a bug tracker.

  There’s a vast choice: bugzilla, trac and the Bug Genie are only few of them. Bug track­ing is ter­ri­bly impor­tant. Maybe not in the very ini­tial phase of your project, but as it becomes usable, bug track­ing can’t be neglected. Even if you’re work­ing alone. Track the bugs scrupu­lously and like you were work­ing on the most impor­tant project of the World. Bugs tend to be for­got­ten of after few hours. Few days in the best case. This is also some­thing that will keep you moti­vated. Act­ing professionally.

• Keep a web­site and build up a com­mu­nity.

  I assume that your project would be inter­est­ing to some­one. The most moti­vat­ing thing ever, is receiv­ing encour­age­ment and feed­back from strangers. Keep a web­site of your project and let the com­mu­nity know what’s going on. Release it as soon as it’s ready and you’ll get feed­back, even­tu­ally help. This is really highly motivating.

Lack of discipline.

Another big hit for unfin­ished projects. Stay away from it for more than 1 months, and it’s over. Most of the times. After one month, you will have for­got­ten a lot of things about it, and just can’t get the focus again. Just can’t find your way through it again. The more the time goes by, the more you’ll get detached from it, and it will even­tu­ally end up in the well of the for­got­ten and unfin­ished projects. To find the right dis­ci­pline, force your­self to keep an eye on it at least two times a week, for 2 hours each time. Of course, this depends highly on how much you care about fin­ish­ing your project, but of course we’re dis­cussing this assum­ing that you care a lot.

Keep all of these hints in mind, and with a good dose of deter­mi­na­tion you can accom­plish everything.