On that scaling and this comment:
It appears that the meaning of "The Mythical Man-Month", after 50 years, has yet to be learned.
It doesn't work like that, but if your point is that it doesn't scale linearly, then thank you captain obvious. This is also part of every single software engineering degree you will take.
In software and I imagine most or all engineering communication is key.
Electronics and hardware people know this. If it's just you making the circuit and product end to end, you can skip a VAST amount of diagrams, documentation and specifications. You can skip a vast number of meetings too. You can develop such a product (usually a prototype) amazingly fast.
However, when you can no longer be the single soul person doing the work end to end, the amount of documentation and the details it must go into go up non-linear with the more subdivisions of the work. The number of meetings and workshops and debates and changings of minds and requirements go up and up and up.
In software engineering when a task/system/requirement becomes too big for a single person, you can move to a two man team (Pair programming). However, social and civil issues arise from a team of 2. It's a marriage and will suffer similar issues to one. Often burning out in arguments after 6 weeks or so. So 3 is usually better as no vote can hang without abstention.
3 developers rarely produce 3 times the work of 1. The finger in the air rule in 60% per additional. So 2 devs do as much work as 1.2 devs. 3 about 1.8.
The issue is the communication channels between team members and the inter-coupling of their work requiring communications multiply geometrically. When there are 2 devs, there is only one pathway. When there are 3 devs there are 3. When there are 4 devs there are 6.
Honestly when you get to about 4 devs, you need some management or team leadership and they do not count directly towards teh "man month" count although they do tend to stop "pulling in many directions" problems.
The "preferred" "modern" model is to divide groups of devs up into teams of 5-10 with a "scrum master" serving one or two of these teams and a project manager over-seeing 5 related teams. Software is broken down into "Epics" by management, then into smaller one to three day tasks which are then ordered by priority and dependencies, but ultimately left for developers to pick up and assign to themselves.
This is the development team manages and owns the development.
No. It doesn't work with pure business types. They simply cannot understand that we can tell them "what" they will have but not when, OR, we can tell them when they will have it, but not what.
When you do get through to a team of business types and they trust you, they are usually happy for it. Far, far too often business analysts and customer managers will UNDER estimate just what can be delivered with modern software tools and techniques. They under sell the likely output and enforce stupid requirements resulting in inherent functionality being lost.
Instead by operating very rapidly on a 2-3 week cycle and then demonstrating functioning software each cycle and allowing customer feedback each cycle allows a lot of the otherwise, "Would you just open you eyes and LOOK instead of talking crap!" to be skipped and wasted effort avoided.
Spending 2-3 weeks on an idea and having the customer say, "Nope, absolutely not!". Is far better than doing it on a waterfall for 3 years like civil-service projects where, under their certified methodologys, if a requirement turns out to be wrong after 2.5 years the are legally required to go back to square ONE. This is why many, many government IT projects cost so fucking much it's got nothing to do with software engineering, it's high brow legal quality and control methodologies that require every single line of code be documented. Which is fine if you are writing a 777 autopilot control software, but not a fucking "Apply for your vehicle tax form", only form!
There is no man month. Most tasks are assigned and estimated on a individual basis. Either based on days or just on "complexity". I've been in teams where the estimates where facial expression emojis! Having management constantly under-estimate those aggregates is only because management are ... well management. aka, usually skill-less.
Like everything, it depends where you are and who you are working for and with. Projects come and go, stuff changes. New skills are required, you are expected to learn. Tech lead wants to switch from SpringBoot to a random app container framework you have never heard of.... best get googling.
Home
Help
Search
Login
Register
