Let's say I want to start developing a project (for the sake of example, let's use facebook, ultimate-guitar, and all recipes or AutoCAD, outlook, angry birds). All of these apps are successful and vary in the degree of "depth" and complexity.
As a starting developer most of these apps and especially the web apps seem simplistic to build and design especially if you're using a good framework. How can I gauge, estimate and forecast the complexity of a project?
Time and time again people ask me this same question - how can you guesstimate the size of a project.
Here is the first thing I always do - use the "Tao" method (also known as the "snowflake" or "Fractal" method) - please note I'm keeping the below simple and a bit naive! - you need way more to build such a complex product:
Say I want to build a massive multiplayer online game. This is general statement of the end product we'll call level one.
What do I need to realize this? High level items only - the list shouldn't be longer than 5 or so items, otherwise you know you've started on details. Lets say I split level one into the following: a) I need a dev team, b) a bunch of servers, and c) someone to take care of the servers. Keep level 2 very basic (although maybe not this basic).
Now level 3 is to split each item in level 2 further into detail.
For the dev team I need i) leadership ii) programmers iii) graphics guys iv) sound guys and finally v) story and level designers.
For the servers I need i) web servers ii) database servers iii) backup servers iv) test server.
(...and so on for level 2).
Now I continue onto level 3, going into even more detail, but still keeping it pretty rough. Example using the programmers item from level 2: I need network programmers, database programmers, 3d graphic programmers, general game engine programmers, sound programmers, and possibly tool programmers (the guys who build the level editors, etc).
And I do that detailing for each item in level 2.
Then I start off on level 4, detailing each item in level 3 a bit further...
And then level 5... etc.
Once you have a level of detail that you feel is trivial enough (for our complex example you probably hit at the very least detail level 10), you can start putting time and money estimates to each item.
The total of which will give you a pretty good idea of what you are in for...
Note: Even a simple web app will have 5 to 7 levels of detail iteration.
Sadly there isn't really an off the shelf product that you can use for this that is easy to use - I've used everything from Excel (easy enough to use) to MS Project (bonus: you already have the start of your WBS).
And please don't think you need to do all the detailing yourself (unless you are a one man team!) - get subject matter experts to help you out with the sections you know they have experience in!
Hope the above makes sense!
I'd start by going to source-forge or another open source repository and finding applications of the sizes you are talking about. Then look at the code involved to have a better handle on the complexity. For example, Blender is a 3D graphics program that's probably approaching the complexity of AutoCAD.
Complexity and challenges will also vary hugely by domain. An embedded system controlling a natural gas refinery will hugely complex despite having almost no visible components beyond numbers on gauges. Complexity can also be overdone by poor coding practices or design problems (too much, too little, wrong type, etc). A game like Angry Birds would be on the low end of the gaming complexity scale compared to something like World of Warcraft. Complexity also arises from interactions, the more interactions you have, the more complex the code will be.
Scope and Feature Creep, are hugely common problems, even in student projects and are huge sources of ballooning code bases. Simplicity may also lead to complexity as Brian Kernighan famously quipped, "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." So you might find that you have written code so cleverly or so quickly due to constraints, that the task of maintaining it is far more complex than you estimated.
Iteration is key here I think to overcoming that. The old adage, "practice makes perfect", is all the more real here.
Just start designing then writing the code. 6 months down the road you'll get a good idea of the complexity and the 97 tasks and functionality you didn't think of initially.
You can't.
Most domain specific experts have difficulty estimating moderately complex projects and above with any level of accuracy.
There are a lot of reasons for this. Papers written. ect. You could study the problem for ages.
If I had to pick an approach to leap frog the experience gap, find a comparable project being implemented by a comparable team working within a comparable company. This will probably put you in the right ball park. The challenge is finding comparable data points and how you attempt to define comparable. And, this just addresses the biggest factors in a project. There are so many other things that can affect a project...see Butterfly effect.
It isn't magic, but it is far from consistent implementation unless you've done something very similar before.
The one and only required tool is experience in similar problem domains.
Even if someone is a C++ whiz, asking them to estimate how long a website component will take is not something they're going to be able to answer well.
I think what you're looking for si something like COCOMO It takes relatively simple inputs like quality of the team, number of input screens etc & pumps out a high level estimate of no of developers and duration of project. I've used it a few times & it's close enough for a sanity check.
