|
|
Allow me to quote Fred Brooks, in The Mythical Man-Month (1972)
He wrote: ... when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.
If you haven't already, get yourself a copy. Even 50 years later, that book is full of relevant stuff.
Also, remember that impregnating nine women will not produce a baby in one month. (Software is not quite the same as babies, but sometimes I wonder...)
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
As I recall the discussion to which you refer is re/ projects in full progress and significantly advanced. The articles to which I refer are projects which are fully designed though yet to be implemented. Assuming the design of a software project is complete well documented and accepted it is not obvious to me why 100,000 programmers can not be hired to implement one of each of the 100,000 methods of the project and bingo presto voila the project is complete in no time at all and ready for integration test.
"We can't solve today's problems with the mentality that created them." Albert Einstein,
|
|
|
|
|
Let's say that is, in theory, possible.
The amount of time it would take to design and plan ahead would probably make it more efficient to hire less programmers and do less planning.
A railroad or building will have many knowns (because every railroad and building is essentially the same, if you're not doing crazy stuff) while software has a whole lot of unknowns.
So every method, method name, number and order of arguments, probably class names, etc. will have to be thought out in advance.
That's basically saying a few people will write the software up front and then we'll hire 100.000 programmers to fill in a few of the details.
So then, let's say you got to the point where 100.000 programmers can write 100.000 methods simultaneously (after probably years or planning and designing).
Those methods are probably going to call one another, but that's not possible because those methods are still being written!
But let's say you get around that by using a dynamic language like JavaScript or Python.
Now you can't test them because each of the 100.000 programmers will have to get the spelling, casing, order of arguments, etc. correct right from the get go without being able to see, verify or test if the other programmer has, indeed, followed the design to the letter (here you can see why designing to that level would be ridiculous).
But let's say these programmers even got that right and they're going to commit their code...
Imagine the merge conflicts! 
Unless, of course, each method has a seperate file, but then that would have to be designed to and those files would somehow need to come together.
All in all, it's not very practical and would take so much time and effort and be so error prone that it's, for all practical reasons, not possible.
|
|
|
|
|
Sander Rossel wrote: order of arguments
Like one of my pet peeves about .net:
public ArgumentException (string? message, string? paramName);
public ArgumentNullException (string? paramName, string? message);
public ArgumentOutOfRangeException (string? paramName, string? message);
In my opinion, ArgumentException has the parameters in the correct order.
|
|
|
|
|
It looked strange to me at first, but I think I get it.
With the ArgumentException it's not clear what is wrong with the argument, so you must specify a message for further details.
In that case the paramName is secundary because it could also be hard coded in the message or the error could relate to multiple parameters.
With the Null and OutOfRange exceptions the error is clear even without a message and a default message would suffice, so you'd rarely specify a message.
What's more important is what parameter the error refers to.
Hence the "switch" in parameter order.
|
|
|
|
|
Okay, so lets say that there is an average of 100 lines of code per method. So 100,000 methods means the project has 10,000,000 lines of code in it. At the accepted rate of 1 defect per 1,000 lines of code, one would expect roughly 10,000 defects to be present in the code base. That is one hell of an integration test to complete.
Physical projects, building things, has safety cushions built into the engineering plans. Software does not have the same cushion to fall back on. You can make a girder with 10% additional material to make up for defects in the material or stress estimates. You can not add 10% additional code to a software module to make up for defects in the code or algorithm. You only add more defects.
It seems that software development leans towards smaller, highly integrated teams with smaller goals and continuous development, integration and testing. (IMHO)
|
|
|
|
|
BernardIE5317 wrote: it is not obvious to me why 100,000 programmers can not be hired to implement one of each of the 100,000 methods of the project
Because software engineering is not a task like making toast or painting fences. (With no offense to makers of toast and painters of fences.)
Methods aren't worked on in isolation. While a 100K engineers could write a 100K methods in a few minutes, they can't design a 100K methods in a few minutes.
/ravi
|
|
|
|
|
Peter_in_2780 wrote: Software is not quite the same as babies
The difference is that software ![Elephant | [mastadon]](https://www.codeproject.com/script/Forums/Images/elephant.gif) s you back.
Software Zen: delete this;
|
|
|
|
|
And babies piss or poops on you...   
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: babies piss or poops on you...
You telling me software doesn't?
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Peter_in_2780 wrote: If you haven't already, get yourself a copy. Even 50 years later, that book is full of relevant stuff.
Indeed. A true software classic. Plan to throw one away; you will, anyway.
|
|
|
|
|
Greg Utas quoted Fred Brooks: Plan to throw one away; you will, anyway.
In a similar vein, the common saying
Think, Think, Think! really means
discard your first thought, consider the second, and act on the third.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I read that before I got my first defacto project management position (senior dev, but we didn't have a PM per se) and it stuck with me.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
lot of things were planned and prepared for some time.
At some point it's just integration.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
BernardIE5317 wrote: builder puts up 57-story skyscraper in 19 days
Give them a change request to add an additional basement floor to that skyscraper.
Yet, that's what we sometimes do in software, isn't it? Causing the recent BSOD outage.
|
|
|
|
|
In short, no.
What was built is not what you would call a full hospital. It's more a stripped-down "hospital" with well understood modules that could be mass-produced and assembled like Lego.
The same with a railroad, where everything is a known, small, and easily assembled.
The skyscraper was the same way. A simple skyscraper, with nearly every floor the same, easily mass-produced, brought to the site and stacked. Is it up to the standards that we would use? No.
Seriously, have you seen some of the software that comes out of China? China doesn't build software like they build those buildings.
|
|
|
|
|
Dave Kreskowiak wrote: China doesn't build software like they build those buildings.
Maybe they need construction cheerleaders?
|
|
|
|
|
Espressif (a fabless semiconductor company out of China) makes decent software for their MCU products. The ESP-IDF for the most part is well thought out, and easier to code against than many other embedded software frameworks.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
All these examples show building speed, not design speed. No one said how long it took to design the skyscraper, the railroad or the hospital. In our field, writing a program is making a design not a product; the build phase is up to a compiler/linker and those have tremendous speed and are incredibly cheap. Let's not compare apples and oranges.
Mircea
|
|
|
|
|
You beat me to it. If there was a blueprint that was 100% thorough, already done and thought out, etc. then in theory that could happen. But, software dev is never like that. People want change and customization when they hire custom dev work... otherwise why hire devs. So, in reality that theory never holds up.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: But, software dev is never like that. People want change and customization when they hire custom dev work
Totally agree.
The comparison I was making before (design = writing programs, build = compiling/linking) is not mine. I read it somewhere but I find it very true and it also "explains" other differences between software projects and construction projects. Stuff like why software piracy is a lot more prevalent than bridge or house piracy. You can get plans for my house from city hall but building it is still gonna cost you a good chunk of money. Meanwhile if you get my source code, building it takes mere seconds.
Also changes like adding 10 meters to a bridge, or an entire traffic lane: this is done, but the result is a new bridge and it will be built in 30-40 years when the current one was amortized. That's because building is so expensive. For software, building is incredibly cheap and people are asking for new versions all the time, ignoring the cost of design.
Mircea
|
|
|
|
|
In a word, no.
As someone else mentioned here, building software is equivalent to the design phase of building hardware. I guarantee that the design team for the railway took longer than 9 hours to plan the railway, and that adding people to the design team would not have materially shortened the design process.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I think "built" is the wrong use of words. I would use "assembled". If the plans are done, and you just need to implement according to an established standard by assembling pre-established components according to a pre-established pattern. . . then yes.
Kind of the way that building a car can be done by hand, but usually it's done on a production "assembly" line.
That's one of the tantalising possibilities of low code environments.
But just because, you can, doesn't mean that anyone can, or that the results are spectacular. Methinks doing work very rapidly has implications with regard to quality, and what might be accepted and acceptable.
|
|
|
|
|
I have limited experience re/ large software projects. I was imagining an initial lengthy process of design specifying all or as many as possible of the classes functions etc. required in terms of their interfaces only leaving details of implementation to each of the 100,000 assigned programmers. So no pre-established components rather pre-specified components.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
