Lines Of Code In Healthcare.Gov

Gerry in GTA, I wish I could code like I used to 25 years ago. Sometimes I feel that it's a type of early programmers dementia when I'm only good for a couple hundred lines of assembler code/day and I make way more errors than I used to in my prime.

25 years ago, when credentialism in software development was still a future nightmare, I took on a few contracts for the tax department to assess software projects to see if they met the criteria for scientific research tax credits. At the time, I was considered an "expert" in my field because I'd created several sizable software projects. The first thing I noticed when I began to audit code (and some of the companies seemed quite upset when I asked them for full source code for their projects) was that the productivity of some programmers was abysmal. One company in particular was developing a medical software system and the results of years of programming I could have easily duplicated in a month of work. The opinion I rendered was that crappy programming is not considered to be "research". Another company was taking on a very ambitious project and the code base was so large I had to review it at their office. My conclusion in this case was that because of the immensity of the code base, creating working code could be validly considered to be a research project. This would have been what I would have considered to be a nightmare project with thousands of business rules that had to be implemented as well as multiple simultaneous inputs to the system. That was when I first ran into the book The Mythical Man Month

The first company, who I thought was running a scam, ended up claiming large amounts of money as scientific research tax credits. I was accused by their "lead developer" of being "overly aggressive" and, surprisingly, of expecting "academic" software standards for a real world application. All I did was tell the guy he was an incompetent programmer. Given the way the tax laws were written in that era, I now kick myself for not taking on some of the projects which I assumed were far too good to be true yet they met the criteria for "scientific research" at the time. It was also then I realized that I was grossly underpaid at UBC considering what my coding productivity was at the time.

During that summer, I did some intensive reading about managing software projects and the thing that stuck with me forever is the vast differences in productivity between programmers. This is a problem that hasn't been solved. There is a problem of prima-donna programmers who think that all sorts of personal vices can be excused because they're such productive coders. A lot of companies have made the decision to utilize second class programmers who at least are consistent. Over the years I've delved into the history of successful software and it seems that every significant piece of software has been written by one or at most a few highly productive programmers. In 1985, the software management books bemoaned the fact that a builder could look at a blueprint and give an estimate of how much materials and labor would cost with an error of 10%. For a software project with similarly detailed specifications, the cost over runs would be only 300% if one was lucky. Not much has changed in this area.

To my mind, the huge cost over runs in software projects are a combination of programmers assuming that their level of productivity will be the same on this project as it was on a previous one and also being unaware of the fact that software complexity scales via a power law. For a building project, if one were to take all of the workers employed at the building site and plot their productivity on a graph, it would likely be a close approximation to a Gaussian distribution. There is no physical way that a particular bricklayer can be 1000 times as productive as the average bricklayer. However, in the virtual world of software such differences in productivity are routine. Rather than nice Gaussian distributions, programmer productivity graphs are power distributions. When it comes to debugging code, code complexity is also an exponential function of the number of lines of code. I relearned this the hard way on a simple Propeller assembly language project where I felt very pleased with myself when all of the initial assembly code I wrote was perfect the first time, and so I did the obvious next thing which was to create much longer bits of code and then spent a month trying to find all of the errors.

People aren't used to exponential functions as they've grown up with Gaussian variables. One of the ways that people attempt to thwart the exponential complexity of large software projects is to use boilerplate code as much as possible. The only problem here is one of scalability which is best dealt with by being able to grok the essence of the complete codebase and then apply optimizations which only the best programmers can do. Given that the people who are pushing Obozocare are linear thinkers with absolutely no clue about the complexities of software development, I predict that healthcare.gov will have a several decade long life as a classic example of how not to do a large software project. My prediction is that this system will never be fixed and that the competent coders to rebuild the system won't be found.

Can't remember who it was a couple of days ago, half in jest, suggested that Obozocare be added as a feature of 2nd life. Given the quality of the programmers working on MMORG's, I suspect that this version of Obozocare in a virtual world would have far more of a chance of success than the real world implementation.

But I see it is impossible for the King to have things done as cheap as other men.

Samuel Pepys 21st. July 1662

http://www.pepys.info/1662/1662jul.html

Loki said: "...the thing that stuck with me forever is the vast differences in productivity between programmers. This is a problem that hasn't been solved."

This is the management world crashing into the reality that some people are smarter than others. Its not a "problem" unless viewed from the bureaucratic perspective, which is that all individuals are replaceable cogs of the same size and shape.

Some people have a mathematical mind and gift for programming, most do not. Example, a 13 year old of my acquaintance was told that the angles of a triangle always sum to 180 degrees. He wondered why. For about a minute. He generated a proof in his head that fast. Proof was, if two angles of the triangle are zero, the third is 180. Because its flat. Duh.

Personally, I can't do that. I can understand the proof, but not make it up in my head in a minute. Which is why the kid is going to be a kick-@ss mathematician/programmer/physicist and I'm not. I told him he should be prepared to be fired a lot in adult life, because that kind of brilliance isn't tolerated most places.

The problem with the Obamacare website is that the people who designed it are not that clever. They fired the clever programmers who told them at the outset it was a disaster, and went with the replaceable cog model. Now they are trying to get somebody to rescue them from their lack of talent, because adding more and more cogs isn't helping.

But again, having this Obamacare scam crash and burn seems to have been the plan from the outset. They wanted an excuse to transfer several billion dollars to a "friend", and they wanted a reason to shift the private medical business to single payer/single provider socialist central planning.

As a DevOps engineer, I just cringe and walk away when software comes up on this forum.

Better than being one of the useless twits who can't code.

As Einstein is repored to have said...."Keep it simple. As simple as possible. But no simpler."

I'd love to know where the "code count" came from.

I share the disbelief that it's "real code" rather than a lot of generated stuff - which is how all modern websites work.

I'm sure their business logic is "too complex", if only because of the legal and regulatory requirements.

And we can see they didn't get scalability right.

But I doubt the problem boils down to size of codebase.

(And I will take gerry's "I wrote code at 200k lines per month with very few errors." with a small salt mine, as a professional programmer.

I work on a commercial point-of-sale product over a decade old under constant development, and our total codebase is under half a million lines, probably more like 300,000 - much of which is generated UI code.

Like hell did anyone write 200,000 lines of code a month, let alone with very few errors.

[Assume 40 hour weeks, and let's be generous on the rounding and call it 180 hours a month of work time.

Assume - (hah!) constant full productivity and zero downtime for builds, debugging, review, looking anything up, or anything else, pure code time.

That's 1,111 lines of code an hour.

A line of code every three seconds, non-stop, all month long. [That rate is perfectly plausible for simple stuff for short bursts, just not scaleable.]

And very few errors?

If you did for more than an hour or two at a time - tops - doing very simple things, you're not human.)

Gerry, you all ways have to consider the "if I can't do it no one can" aspect of human nature. I"v run into that many times in my life, just not in code writing, as I don't do code writing:-)))))

Even writing code for 18 hours a day that's 370 lines AN HOUR. 6 lines per MINUTE. Better keep your job in the server room boy.

James, as a system and network admin, you can blow me.

Like systems admins, programmers are dime a dozen, 9c on Sundays and that's the domestic market. Admins and coders that are worth anything are a completely different story. The difference is experience and capability to learn.

Personally, having done both, I'd rather spend my day in that server room you disparage then in the cubicle pumping out another bubble sort or optimizing some function for the umpteenth time; license plates, for the most part.

But neither here nor there. You can't do squat without the infrastructure and I can't do squat without the programs.

Often lines of codes are only one word or even just one character. Some examples include "return x" "else" "x++" and many as small as "}" It's entirely possible.

Even still, maybe 200k is really an exaggerated 180k and maybe a month is
5 weeks. Can you honestly tell me you can't move beyond that to his point?

As to the "website" being that many lines of code, it's clearly the whole system of programs to access servers, verify identities, collect and distribute a heck of a lot of data and not just what you see in your browser. Definitely a huge undertaking and if done poorly could definitely sprawl... not saying it is that big for sure, but it's one of those things that nobody can assume has to be smaller than xp.

Why would you limit him to 40 hour work weeks when he said he was on a deadline working 7 days a week up to 18 hours. Must be nice to live in your world. I work 21 days in a row at 12.5 hour a day minimum. Some people are willing to go above and beyond especially for recognition, pride, and money.

You say your POS system was 300k. Well I would think the coding required to bring all the obamacare crap together, especially if written inefficiently would be about that much more complicated than a POS system. 40 hour weeks? Very weird programmer hours. Gary's programmer story is much more believable than yours.

sorry Gerry's story is more believable. My bad.

200k lines per month? OK, let's assume you work 30 days a month, taking no time off.

200k/30 = 6,667 lines per day. Assume 10 seconds per line of code (thought, typing, fixing typos)
66,667 seconds = 18 hours a day, every day, for "months".

Now, either the code you were writing was dirt simple and was full of simple loops and assignments, so that
no thought was really necessary, or you are full of it.

My money's on the latter.