Hacker News Reader

Comment by rsynnott | Hacker News Reader

> But a problem with a subcontractor, compounded with other issues, forced Tesla to start over in certain areas, delaying production.

> “We had to rewrite all of the software from scratch,” Musk said, adding that they’d redone “about 20 to 30 man years of software in four weeks” for the battery module.

Maybe I'm just overcautious, but I would prefer not to be anywhere in the vicinity of a high-discharge actively cooled 100kWh battery whose control system was written, presumably as a rush job, in four weeks.

View on HN

Yeah doing 30 man years of software in 4 weeks is nothing to brag about. It's like assuming putting 9 women together can output a baby in a single month.

So your opinion is parallelizing software development is impossible? Interesting.

This is not an unorthodox or unreasonable position. The Mythical Man-Month is a classic text in software engineering and project management and essentially argues this very point. The analogy to child birth is actually also a classic one made originally by the author.

https://en.wikipedia.org/wiki/Brooks%27s_law

Of course just like everyone on HN am aware of the book and heard this quote a billion+ times. And of course I know it's badly misused in this particular case (as it often is).

software development parallelization works about as well as it does for actual software, ie non-linearly at best. Add to that overhead/mistakes/difficulties caused by "synchronization" and you come to the conclusion that a significant amount of that "30 man years" of software had to be just discarded when rebuilt

But consider that the existing "30 man years" design had couple year calendar time for it at most. Doesn't that say something about the task at hand?

EDIT guess this is just rephrasing of your point, in a way.

The more people you put on a single project, the more communication costs - which grow with n! - start to dominate.

The solution to that is to structure the project into independent parts that can be done in parallel by smaller amount of people, thus vastly reducing communication waste. But whether or not you can divide your project in such a way is a question of its scope, and of design decisions you make.

My only point was that the quote is often misused and is highly contextual.

There are countless projects where work can be efficiently parallelized. Cramming 30 man years in a month still sounds like a death march but we do know that say Linux kernel which by now is probably a million(†) man-year effort was done faster than in geological time.

† Ok exaggerating but it is huge and with fast paced change throughout whole codebase.

20years * 50weeks / 4weeks = 250

assuming a man year is 40h/week and those 4 weeks were a crunch of 80 hour weeks, then 125 people worked on the same piece of software, assuming no ramp up time.

Is this even possible?

possible sure! likely or useful or effective...probably not

What on earth is in that control software since it take 20-30 man years to write?

I mean, charging profile based on input variables such as temperature, total capacity, current capacity, health, available power ect. And then for discharging.

The battery and it's controller ought to be a black box you can either feed power or request power from, and query for data. Either I'm missing something fundamental, or the SW stack is a mess.

This control software is for the manufacturing line. It's a mixture of a game engine and the code to control the robots by signaling each individual servo on the robot arm. Now multiple one robot * 4 lines* multiple stations(at least 6) * more than one robot per station. The game engine simulated the robot state to program then faster without requiring a pendant like it's typically done.

The code you are thinking about Is a copy paste from the model s and x batterry management system which implemented a kalman filter in a dsp to calculate State of charge among other things. That code is not the one being discussed here.

Reply on news.ycombinator.com