Holy Christopher Columbus! Was it bring your favourite programming language to work month?

Seriously, this is a clear indication to me that this thing probably had all the halmarks of bad projects:

1. Design by committee - definitely little thought given to KISS. No unifying approach/structure.

1. No central control of the implementation standards.

1. No thought of manageability/longevity/lifecycle of the code base - expediency at the expense of resiliency.

Managing that brittle monstrosity is going to be painful over the long haul. I feel for whoever gets that job.

The questions for those of us in the business: Why do we continue the cycle of poor craftsmanship/performance? What can we do about it?

500M for a website isn't possible. Period.

Anything is possible. The real question: is it probable?

"The lack of a standard library however makes things just repetitious and error prone", doesn't follow. Why would you copy the same code over and over in your application? Are you 'copy-paste' programming? That isn't very smart. Even as minimalistic as C is - it still has subroutines - you could even put them in a separate file from your main application to be reused in more than one program. Code reuse isn't a magical property of OO languages exclusively. Your statement actually illustrates the point - people don't have a fundamental understanding that carries over into all other languages as your abstraction level increases. You don't run before you walk - but in teaching computer science and programming we seem to be trying to do just that with our students today - and the failure of this approach is starting to be obvious in the real world where the rubber meets the road - at least for those of us who have to waste time and resources fixing the results.

C has been described as a wrapper for assembly language, and as such it requires that you really understand how the computer processor works to do anything non-trivial. C++ allows you to do that as well, but C really enforces it - and makes you think about building your own libraries of routines to do the higher order abstractions yourself.

This is valuable because most higher abstraction entry level languages today don't give you that experience (e.g. Java) - which really is what is important when designing good software, or conversely trying to troubleshoot someone else's bad software.

Case in point: We had a java application written by a vendor. It ran slow, but worse than that, it would crash after being up for some time. To make a long story short, the vendor had short circuited Java's garbage collection mechanism. All the objects it was creating in memory where not being released because they were not going out of scope. Java would reach its configured memory high water mark, and shutdown.

When we showed this to the Java programmer - he didn't have a clue as to why this happened to his application. So I would have to agree with Joel that Java is not a hard enough language because it abstracts away too much of the underlying machine. If that is all a programmer knows, then he is not a complete programmer IMHO. So I would have to say here is some support for his unsupportable premise.

Ned Lud, is that you? The 17th century is calling and they want their mime back.

Seriously though, this 'techno-shit' is what is powering the next revolution - allowing us to be far more efficient than we have been in the past. In a world of dwindling oil supplies, climate change, and over population, technology is what will allow us to survive this world, and migrate to the next. I don't know about you, but I'm not interested in contemplating future generations groveling in the dust of this parched world as it spins down to nothing. Doing my best now to move the technology bar - even a little bit in the right direction is worth the effort taken in that light.

I'm curious as to your occupation - given the subject matter of /.

I tend to agree with sticking with Moleskin(sic) - preferably 8 1/2 X 11 size --- nonruled (blank). I've tried electronic logs - I've tried electronic drawing apps (e.g. Papyrus on a Nexus 7 Android system). The main problem for me is not only do I want to write in it - but I find freeform drawing to be more helpful in conjunction with the writing. The Nexus pixel sizes for drawing where too coarse - and while you can zoom in and out -- the drawings always ended up looking odd - and took longer than just writing on paper. The only other acceptable solution I found was a $1500 Wacom electronic drawing tablet --- so I continue to buy Moleskin at a fraction of the cost.

So that does bring up the problem that is mentioned regarding indexing - and here is how I deal with that:

Each entry is dated in this manner: yyyymmdd e.g. 20140421 ; in this way each volume contains a series of entries that are uniquely numbered; if you need to add more than one entry per day - then just add hours and minutes as needed: 20140421:1405 (using the colon to visually separate the date from the time is preferred by me).

I also encode each entry as to 'type', where types are based upon single letter codes: C = computer science, A = art, etc... I put the letter code inside of a square in the upper - outer corner of each page where an entry begins.

The next step is to create an electronic index to key entries in your logs --- assuming you number your volumes sequentially - you can identify an entry like this:

Vol 2, 20140421:1400 History of FOO

With this system you can have both the flexibility of combining freehand drawing with your log entries, and also keep an index of your key entries organized however you like (perhaps by type, or project codes etc...you can expand this as you need beyond my simple method).

Apocalypse in current usage means the end of the world. By that definition - no skill will be 'Apocalypse Useful' - because no one will be around in the aftermath of the end of time (with the possible exception of an intrepid band of our great grandchildren who might figure out how to jump between multiple universe branes at the precise moment of the 'big rip' - a very remote possibility imho).

Really what we are talking about are events that while devastating, are short of the level of destruction needed to end the world. The very nature of that definition means that there will be locations that are not directly impacted by whatever happened. The most key struggle would come from dependency on things that moved by long distance transport; various foods, fuels, technology, and other manufactured goods. As a result, local replacements would have to be found and developed.

In those areas harder hit - it would be very bad, if not impossible to survive after the initial event. I can see migrations of people from these 'hot zones' to more habitable areas. Refugees might put too much pressure on less impacted areas - causing a crisis in those areas. The first few years after the event might be very chaotic due to these population pressures and migrations. The very best way to avoid a humanitarian disaster would be to make sure all of the surviving zones have good communications - and plans in place for relocating and organizing the influx of survivors into their communities. I think you would also want to move as quickly as possible to restore technology to society - maybe not in the exact forms that we are used to - but restoration just the same. Having running water, food, medicines, heating and cooling, and energy in general are critical to sustaining life. As a result, I think all disciplines will be useful to society in that situation in one way or another. One example: artists and story tellers would be useful in bringing entertainment and beauty into the lives of the survivor communities - and might be very important in keeping human knowledge alive until information systems can once again be restored. Ultimately, people would be so hard pressed to survive that it would quickly become apparent that the survivors will do better by banding together rather than fighting among themselves.

Overall - I think if the event was large enough to depopulate the world significantly, I think the survivors would be very busy indeed, with little time or energy to waste of the staples of post-apocalyptic fiction: warlords, societal breakdown, and descent of our humanity to that of the animals, leading us to prey upon our fellow man. While there may be a few sociopaths who try to benefit from the situation, I expect the rest of us to quickly control that. Essentially, humanity has lived through these sorts of things in the past, and I am sure we would make do and get on with living in the aftermath of whatever mother nature sends our way again.

My very first program was 'hello world' in Basic on the High School computer lab's Apple ][ in 1981 (learned Fortran in that same course). I got a TI 99A for my birthday that year, and I wrote more noddy programs in Basic over the next few years, saving them meticulously on cassette tape.

I can't imagine using Basic for anything useful these days, but it was fun while it lasted.

Another aspect of the problem - Corporate policy in most large companies is to treat all of your IT programmers as identical widgets. This policy stems from HR, Finance, and IT efforts to 'normalize' positions so they can be circumscribed enough to allow 'efficient' allocation of resources, or more damaging, the allocation of resources that can be outsourced wholesale. Ultimately it all comes down to cost reduction. Poor results of IT, coupled with IT being strictly a cost center - leads to this outcome (the cost vs. value proposition as seen through the eyes of the heads of the business).

This of course, drags down everyone with it causing many good people to leave or get caught in the outsourcing net. If they are lucky - they do manage to move up into management (architects etc) - and hopefully they can influence the designs - but again - what is left behind is tragically impossible of effiently implementing even the best designs - so the problem feeds itself as your best get pulled away from programming.

Indications are CTOs are starting to see how this is not working...here's hoping they can get the HR and Finance people to turn this around, but I doubt it. .

Too bad you posted anonymously. I would have modded you up. This is absolutely the truth.

My recommendation for anyone: if you love the carreer you want to get into - then do it. However, if you only see a bunch of dollar signs - then it is better off for you and the rest of us in STEM if you would put your energy into something else.

We are plaugued with a glut of people who cause more inefficiency than the 'solutions' they create... causing me, and others who know what they are doing to spend extra cycles fixing their broken systems. The problem is most of the time, they don't even know why their choices are a bad thing, or worse - if they do, they don't care allowing expediency to take precedence over quality.

On a positive note: this will keep me employed well beyond my retirement as a contractor fixing other people's code.