How much and what planning is used for software projects?

Question

How much and what planning is used for the software projects that you or your company develops?

The reason for my asking is because of a class I'm taking on UML and other similar things of that nature. From the way the class is set up, we have been creating a mock library system extensively with programs like Visual Paradigm, but for all of the work so far we have not done any programming yet (and we do not intend to either for this mock project).

Perhaps it's just the way the class is taught, but it seems to me that a lot of the stuff that's being taught in the course is very wishy-washy in its presentation of important planning for software projects. I can see how useful object diagrams are, but the other diagrams are leaving a lot to be desired. Just how useful are sequence diagrams or state machine diagrams in practice?

So, because of the aforementioned, just how much and what planning is used for the software projects that you or your company develops? Is it extensive or is it minimal? Do you delve deeply into planning out everything or do you get the general feel for the project before writing code?

Answer 1

I think you're confusing planning and design/architecture. Planning usually refers to the business side of things - how many people will do something in how long. Design/architecture should deal with how to do things right assuming you had enough time and budget.

In terms of design, most developers know UML to some degree, but don't necessarily use it. If they are given CASE tools, they might use class diagrams for individual use, but not use the others frequently. CASE tools force you to use the "formal form" of UML so they are fairly strict and that limits their creative use. A CASE model is often created to benefit from code generation. In my own company, we produce a ton of code but don't use UML at all.

For collaborative design and review (e.g., drawing on the board), UML is more common because "everyone speaks it". However, from observational studies that I've done and published, UML drawn on the board is merely means to an end - people borrow certain notations, but use them to communicate ideas. So you would see things like sequences and control flow on a class diagram. The resulting artifacts are not something you could just capture into a CASE tool. You can see my dissertation for many photos of what these things look like when you group a bunch of experienced developers to do design.

In terms of planning, my experience is that this highly differs between software companies and companies that also develop software. In the latter (which are the majority) macro-level planning is often done based on corporate culture and business style planning, the kind of stuff you learn in MBAs. It is typically not specific to software, and as far as management is concerned you could be building software or baking muffins, it's just numbers. On a more micro-level, there isn't really any official system used. Tools like Gantt charts and spreadsheets are used to keep track of what are essentially best-case guesses and slipped schedules. But in the end, it depends on management's experience - former devs are usually stronger at it. Certain practices like Agile simplify planning in some ways.