I am currently developing a very large software project alone, due to financial constraints from the company.
I work on the database, get requirements, deal with the business logic, user interface, ...
Though I have some experience across the different layers, it is not easy. Is there any way I can manage myself and the project more efficiently?
Current, I'm taking it module by module.
C+++ Coffee,Coke,Chicks.
Seriously... comment your code man, and comment it well, cause you will forget stuff.
Many of the same principles from working on larger teams still apply:
One very important element is to keep yourself motivated. One way of doing it is to plan the development course so that you regularly see new features appear and function. Try to do work by adding logically separate components, one after another. This will display the progress well. If you were, for example, build a complex architecture for many months before actually implementing a single usable feature, this has the danger of making you bored and unmotivated.
Find an issue tracker that you're comfortable using and that meets your simplicity/complexity level. Don't get one that's huge and massive and takes 4 steps to enter a task/issue so much so that you'll never use it.
Either keep it open always (in a 2nd monitor perhaps) or make a very easy to access link. When you think something that you need to do/fix/improve, make a task for it right there on the spot (or within a few seconds). You'll be amazed at how many things you forgot within just a day or two which are in the issue tracker.
This also gives you the opportunity to 1.) prioritize your time and make sure you're not drifting into low-priority areas, 2.) review if that 'great idea' is still great, and 3.) manage a sense of how fast you're moving through the project as well as give you a sense of accomplishment for what's already been done.
All my projects at work have been solo-efforts so I understand where you're coming from. The only thing I can add to the other answers is that you need to make sure you have someone else to bounce ideas off and discuss things with.
When you're just doing things on your own it's easy to go down the wrong path or get stuck on something that could be solved by just explaining the problem to someone else (they don't even have to have the answer, just explaining it is often enough).
Use feature integration on this if you ask me.
Develop a sub section of the system and release it to some users. Find power users, people who are patient and understand this is for testing and have to time to test it properly for you. Do this as your developing the next sub system.
This is accretion, this way, the select users will find the bugs early in each section that you have released. You can pin down where your debugging efforts need to be. If you release the whole lot and get a load of errors your going to have a hard time finding things.
Keep lots of documents on the go for your different areas. Text files will do so there is no excuse. Write down what you need to do before doing anything, keep reverting back to things time and time again.
Get people to agree on things and sign them off.
Did I mention keeping documents?
Have fun! Good luck
Make sure you go for a iterative approch since you won't have other people on the project to warn you if you start to go down the wrong path.
Make sure everything is kept in Source Control.
Don't make the mistake that is rushing into the coding phase. Especially on a big project, and especially when you're the only person working on it, you have to write documents explaining what you are going to do.
You'll see, soon enough, that you won't understand the whole project anymore. But it's no big deal if you have enough documentation to refresh your memory.
I'll quote a good friend of mine who often says something like "You have to write your documentation while thinking of it as a time capsule...you will understand what I mean when you open it in 6 months".
He's sooooo right about this.
I work for a small development company and we often do projects alone (or in pairs). Here are a few pointers Ive learnt over the years, some have already been mentioned.
Invest in a server for source versioning, backups, issue tracking, build deployment etc. It is worth it in the long run. Dont try to run a project off your development machine, things get confused and lost.
Following on from that use source versioning and issue tracking. When going it alone managing the client and the project are often more difficult than development. Have a web interface for the client to interact with.
I STRONGLY recommend a wireframing approach, give them a dummy app to play with which has the basic gui in place and they can click through and pretend they using it. Users generally have difficulty telling you what they actually want or dont know what is possible. A wireframe takes a couple of days to make, then run through the system with them and leave a copy for them to play with. The better understanding both of you will have will save alot of time.
Get a firm sign off on requirements, as people start seeing things take shape the scope creep will be a problem. Again a wireframe helps immensely, also dont forget there can always be a version 2, dont try too much too soon.
If possible find someone at the company who has a global overview of how it all works and even better has a decent grasp of other computer programs. You will need more details from other people in their area but a single person who can see the big picture is a big help.
Dont promise too much too quickly and remember the last 5% takes most of the time. Getting a useable app into their hands is prity easy, keeping at it and polishing it to be a really useful program is going to take alot longer and they must know this going in.
Make sure you have the ear and commitment of management. Often the project will hit a road block cos someone is busy or not interested. Without getting anyone in trouble you need to be able to apply pressure to push past these hold ups.
If possible, make the project as modular as possible, and see each module as a deliverable or milestone along the way.
Make sure the modules are small enough as to not overwhelm you.
I'd keep it as simple as possible (issue tracker, code repository, powerful IDE) !
Use as much hosted stuff as this saves you time: e.g. bitbucket.org for issue tracking, wiki (documentation) and a sourcecode repository. It pays of to learn a distributed SCM tool like mercurial.
Another thing: you don't want continuous integration or a difficult build system. Since you are on your own you have the advantage of writing scripts that are tailored to your system (eg. specific paths).
Build systems IMO are very time consuming to maintain.
What we're dealing with here is a limited resources project with obligatory fast RoI. I suggest you use SCRUM, or at least some parts of it, because it will make it easier on you to keep track of what you've done, and what you have to do. While keeping you focused on prioritised work and having a stable product at all times.
product backlog is not to much to write and you can always detail it further while you go along (if some tasks/stories need more explanation). You'll always be able to tell where you are, what is still outstanding and it will help you prioritize stories, so you will get a workable/sellable product sooner.
you can use the same log for bug tracking. But keep it separate of your main stories. Use same prioritization as with your stories. And keep the process as it should be: Don't start any new story until old bugs are solved. This way, you'll have a stable product before each story start.
if you don't have any SCRUM tools, just use Office Excel. There are plenty of SCRUM templates out there, but they will probably be too overwhelming for one-man band, so keep whatever seems reasonable to not get you into too much management overhead.
keep your backlog updated. At least update stories/tasks when they're done done. Also don't forget to put in new stories/tasks when they appear because you haven't been too granular at first. This will help you when there are going to be interruptions (think of vacation/sick days) that will get you away from the project for more than a day.
If you like, you can also track velocity but that will put more overhead that may not be reasonable on this project since company has limited resources
All the usual stuff, but very briefly:
Write down in couple of paragraphs what problem the system needs to solve; who it’s for, specifically. who are the actual users and who is paying for the end result.
Write a specification, that describes the way in which you plan the system to solve the problem, what the constraints are, what choices you have to make and why you’re taking one decision or another. Don’t worry about getting the spec perfect, you’ll be updating it as you get more info. The whole point of writing the spec is to force you into thinking more than one step ahead, and there is no better way of doing that. As a minimum you want to cover end-to-end at least the most common flow or usage pattern. Some useful reading:
Then break the spec down onto tasks each up to one working day long. Write down initial estimate against every task. Include any auxiliary tasks, such as making interim demos, building releases, keeping documentation up to date, writing tests, testing, fixing bugs, talking to users, setting up dev environment, setting up test environment, training and so on. Don’t worry about getting every estimate 100% accurate; however be realistic about how long things take.
In my experience then a plan goes pear-shaped it’s because of the tasks that were not included initially: overlooked or forgotten. For a reasonably granular list of tasks (say each no longer than 8 hours of effort) an error in estimate will only give a second-order errors in the overall schedule, whereas missing several tasks altogether will lead to zeroth- or first-order errors. Simply put, miss a task and you have a great chance of blowing the plan, get an estimate or two wrong and the errors might just cancel each other out.
One useful trick of working out what needs to be done is taking a target (for example a deadline, a budget, or fully operable system that users use to solve the problem) and then working your way backwards through the things that need to be done to get into this position: train users, create user accounts within the system, configure the system, install the system, test, create a release and so on. This is opposed to starting with nothing and trying to figure out what needs to be done to arrive at the destination.
Once you have the spec and the task list you’ll be able to start prioritising, in other words to start looking at which tasks are more important and what can be done later. If you have to do some risky things or there are unknowns (like new technology to work with) it might be worth putting them on top of the task list, so you could attempt this task early and re-plan as necessary, instead of discovering problems late and having to re-work the entire spec and the schedule. Assume that problems will occur.
Ok, at this stage you have the problem definition, a spec and a task list. Great! You’ll need to keep these up to date as you make progress. Now start organising: get a dev environment up and running, test environment, automatic builds, some real-world test data, issue tracking to record any defects and outstanding issues (a simple spreadsheet might do to keep track of tasks, issues and defects). Agree interim milestones, demos, get the equipment, software, licenses for the dev, set up source control, et cetera.
Now being all organised it’s time to start writing some code. As you progress update the spec and the list of tasks and issues daily. If you see that there is a lot of deviation from the initial plan just stop, and iterate through the steps 1-5 again. You might want to change quite a few things, however you will know so much more about the problem and the project at this point.
Well, the system is nearly finished now or at least it seems to be. There is a point when you’ll need to make a decision to freeze the development of any new features and concentrate on getting what you’ve already got working reasonably well. Users or project sponsor (one who pays for the system) might be able to give you some guidance on what defects they really care about and what things they could happily live with. But ultimately, you’ll need to go through every outstanding issue and make a decision whether you need to resolve it or just ship whatever you’ve got and move any outstanding work into the next version.
More testing, installation, configuration, training, post implementation support (of course, you‘ve thought about organising and planning for support in advance, right?)
Bring any documentation up to date and either wind any resources you don’t need any longer down (such as dev environment) or hand things over. But think about any issues that are going to come out of system being used first. You might want to take some notes for future self about what went well and what went wrong.
Champaign.