4

I need some advice on project management.

I start a project, and often times it will a large project for a solo developer. Usually its a web project. I handle everything from the UI, to the JS, PHP, server management etc. Half way in I feel out of my depth. I lose where I am, so I spend a couple of days away from the project to avoid the stress and before you know it, it becomes another unfinished project.

I try to use frameworks and code libraries to make my developments easier on myself. Sometimes I will complete a project so it "works" and then go back and handle errors, design the UI properly and stuff. But without fail I will always end up out of my depth.

I've though about outsourcing tasks such as the UI, and the behaviour, and focusing just on the PHP - which I feel is my strong point. But then pride kicks in, and I don't feel at one with a project I haven't completed myself. Does this make sense?

I am sure there are many others who have felt like this either at home, or at work, and I would love some advice on managing my projects better.

closed as primarily opinion-based by gnat, user53019, Kilian Foth, Robert Harvey, Bart van Ingen Schenau Nov 6 '13 at 8:01

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    "Project management" is a technical term, and it means exactly the opposite of "complete everything myself". You should probably edit your title to attract the right kind of attention to this question. – Kilian Foth Nov 5 '13 at 13:08
10

Had the exact same problem:

If I'd put my project away for a few days, I'd come back to it and have a real hard time picking it back up. I'd had to re-familiarize myself with it, try to re-understand where my thought train was going and sometimes wonder why did I ever decide to code it the way I did so far. More often than not this would simply make me abandon the project or restart it from scratch. All this became a real problem once I realized that the situation forced me to:

  1. only start small, simple projects. Starting a big project would just bring me past the confusion threshold where I could no longer resume it after leaving it alone for a few days

  2. if I really wanted to do something more involved and complex I'd have to do it all in "one sitting", namely work on it every day until it was done with no breaks

This was just stressful. I decided that before I'd go on making solo personal projects, I'd have to try to address this issue.

I started complex projects on purpose, just to see exactly why I was having a hard time resuming them after a few days' break. I'd start implementing an algorithm I wasn't familiar with until then (like A* or Mini-max, etc), stop coding in the middle of it all, and try to finish it a few days later.

Here's some of my conclusions on this:

  • monolithic anything is bad. Make small concise functions/methods, classes, packages, modules. Don't ever, not once, cut corners on this, thinking "oh come on, I'll just add the draw.sprite code to the updateGameState() function this time only, how bad can it be" or that "I'll just add this calculateArea function right in the SelectButtonWidget class, just this once, it'll be so much faster than making a separate class and instance for it". This makes code hard to follow, and thus hard to resume after a few days break, when you no longer remember all the "mental aliases" you've just done like "all drawing code is in the drawables package except the one for drawing a sprite which is in the updateState() function of the X class of the Y package".

  • unit tests make the code a whole lot more readable than comments Did you, out of desperation, add "pages and pages" of comments to your code in the hope that it will be more readable next week when you resume your project after returning from your vacation? I know I did. Never helped. Not only did it not make the code more readable (some times it made it less, as it didn't help me re-understand what my code was doing while at the same time clutter my code), but it was taking A LOT of time to add comments everywhere. Also this lead to such conundrums as "do I comment at the class level, method/function level, for each line of code, only for the important ones, etc etc". Investing all that comment writing time into unit tests was a lot better. Unit tests check for something, and you can readily tell what they're checking for and hence what the code is supposed to do. Also, the "where to place them comments" conundrum was gone. Unit test everything. Start with whatever you think is most important but make a goal of unit testing anything.

  • unit tests just rock Not only is your code more readable and easier to (re)understand, you'll not even need to to (re)understand it all when you come back to it, but only those areas you want to work on presently. Just peek at the unit tests of the parts of the code you wanna modify right now to see what they're exactly supposed to do. Then modify them, add more unit tests if necessary, and just re-run the whole unit test battery to make sure you haven't broken anything. If they all pass, you instantly know all is good with your code, without having to go through all of it by hand.

  • never optimize until the very end In the grand scheme of it all, this point is debatable. Will my code run faster if I delay optimizations as much as possible, or of I do them incrementally while I implement things? I honestly don't know. But strictly from the point of view of code readability and how easy it is to resume a project after putting it aside for a while, I'm pretty sure that the practice of delaying optimization until the very end is the best way to go. What I mean is: as long as your implementation is not close to being done, focus on having nice, readable, modularized code. Once the functionality is all in, debugged, unit and functional tested, you can get to the task of optimizing the code. You'll have a nice version of your code which you are confident that it works ok, and is clear and easy to read, and to which you can always return if the refactoring for the purpose of optimization gives you trouble.

  • 1
    You, my friend, just explained me to a T! This information is invaluable to me! Thank you so much. – James Jeffery Nov 5 '13 at 16:51
5

Just from pure product perspective, I would ask what is the rationale of creating such projects? What is the end goal you try to reach?

If you are doing it for hobby, then I would argue that probably you don't have too good motivation and reason for doing those projects (getting bored etc.). And if there's no clear understanding why one does some things, it's very hard to expect this to be engaging for a long period of time.

If you are doing it for money, then I personally would seriously recommend taking a look into your business model and would argue that there are inefficiencies that have to be overcome. Every business or product needs a set of different people to be successful, there are good one man armies, but very seldom.

I feel that the problem here is more general and can not be solved with just adapting to new tools or development methodologies.

  • This is an interesting answer Laazik. It's a bit of both, sometimes projects are hobbies, other times they are business related. – James Jeffery Nov 5 '13 at 13:26
  • For the business products or projects, I would definitely recommend to take a look into this and understand what are the main shortcomings - perhaps you should get some additional expertise on development areas, or maybe in project management.* I mean, if this is for business, it is the job that pays your bills and at the end of the day you'll stop progressing, getting better jobs or just don't develop yourself, if you continue doing that for a long time. I wouldn't like to be in that position. – Laazik Nov 5 '13 at 14:03
3

Somewhat on a tangent, but I find that having personal projects of the same type that I do at work (eg. Rails developer by day, personal Rails projects at night) can lead to much increased risk of burnout, fatigue, and just total unwillingness to work on it.

Focusing on the parts that are different (eg. the UI, or the server stuff) can help with the motivation I think, rather than doing 'just more of the same'.

  • This is so true. The only way I can motivate myself to work on hobby projects is if it is an entirely different domain and technology than what I do at work. – Evicatos Nov 5 '13 at 22:49
1

For me the solution is not to start big projects. Instead I make a small project and evolve it.

It may not be publishable after first step, but on every step it has some known state, list of future improvements, may be some plans.

Motivation may affect how much time I spend, but the code and other things (plans, bugs, features) should be maintained in a state that allows to easily continue after at least a month delay (year delay will likely require some refreshing).

0

But then pride kicks in, and I don't feel at one with a project I haven't completed myself. Does this make sense?

What's you motivation for these projects? Fun? Learning? Then maybe it makes sense, tho you could argue you'd learn working with others. Actually making a finished thing or business goals? Then it absolutely does not make sense. Find a way to get over it.

Not the answer you're looking for? Browse other questions tagged or ask your own question.