Hacker News new | past | comments | ask | show | jobs | submit login

"... At my previous job I worked with a 2 mln LoC code base for a core banking system. ... Imagine working with a code-base, that's layer upon layer of quick fixes. Imagine being woken up at 3 am to diagnose & resolve an issue with it. ... The company wasn't really affected by heartbleed. ..."

AND

"... OpenSSL code base, counting how much resources are needed to plumb it into shape, how the original maintainers - let's not go there. Let's say 'didn't do a great job'. ..."

Does anyone see the disconnect here?




I'm the author of the article. Can you elaborate more clearly on what you are pointing out?


Hi @mulander, this is a good read (quickly went thru your other posts as well).

The point I wanted to make was the bank code base described in the article reads like it's insecure (no mention of it being exploited). The article then describes using Unix variants at home, [0] though not which one. I assume Linux. Usable, permissive and open, Linux has always been inherently insecure. Then the article goes on to describe finding of OpenBSD, post Heartbleed.

The question I asked myself: "How does a smart capable person as yourself, miss security being the heart of the operating system and programming while working on core bank systems?" Is this atypical? That's the crux I've what struck me. The dis-joint between the description of what represents a secure, large code base and the personal move to OpenBSD.

From what I understand OpenBSD, a bastard child of 386BSD [1] was a deliberate move to build a secure and audited and most importantly free operating system. This is such a contrast to the cruft described in the article. Maybe that's the point of the article, a growing awareness that fast a moving code-base left unchecked, comes at a cost. It has to change and it can be done.

[0] I fully endorse this btw. A linux user since '95, I love how I could use lots of different hardware with it. Linux is also fast. Fast to use, fast to install software. Fast. Secure it is not. I got sick of trying to secure my boxes and started using OpenBSD. Read about my pathetic attempts to install it on old hardware <http://monkey.org/openbsd/archive/misc/0310/msg01026.html>

[1] P57, Tovalds & Diamond, 'Just for Fun', "One BSD derivation in particular is worth mentioning. I was the 386BSD project by Bill Jolitz based on the BSD code-base, distributed over the Internet. It was later to fragment and become the freely available BSD favors-NetBSD, FreeBSD, and OpenBSD".


Hi @bootload, I deeply appreciate your response. It's sometimes hard to read between the lines as English is not my native language.

I'll try to put some more light and perspective into how my previous work place 'ticked' and how I intended to outline my passage to OpenBSD in the article.

My previous workplace was a large corporation. I were literally on the clock accounting for every 0.25h of work I did. You were not allowed to touch a single line of code unless you had billed hours against that task (contract with a client, bug report from a client). This literally meant that doing comprehensive code reviews or reworking a particularly nasty part of the code was not possible. There was a 'process' for doing code reviews but it was so bureaucratic that going through the paper work you had to submit after one took 0.5h-2h but the time you had for a code review was counted as a percentage of the time it took someone to produce or alter the code. So if you reviewed a change that took 1h - you had 10 minutes to do the code review and all the alloted paperwork.

I don't want to speak about the quality of the code base in detail due to obvious reasons but I can assure you that people working on it are really experienced and know what they are doing. Most of the problems and the humongous technical debt is years of corporate culture. Did I mention that the banking system I worked on was born around 15 years ago?

During my 7 years at that job. I had the chance to refactor code once. In my first 3 months of working there since I was not yet on the 'clock'. When I was at my leaving period I was given a free hand and was took off the clock again. This allowed me to really look at the code, analyze potential problems and actually react on them. People that are still working on it don't have that privilege on a daily basis.

The stab at Linux was actually accidental :) I use Linux personally since late 90s. What I mostly pointed out was some of my bad hardware choices in the passage and how OpenBSD drives me more into actually diving into the code contrasted to all the years I solely used Linux.

You are correct that my 'evolution' towards tighter, smaller and correct implementations drew me towards OpenBSD. I think I had that feeling for a long time but hopefully you understand that it's not always in the hands of the programmer himself to call the shots and do things right. What I really loved though was auditing and removing a ton of cruft in one code base while OpenBSD did the same with LibreSSL :)

Hope this answers your question.


@mulander

"... I were literally on the clock accounting for every 0.25h of work I did. ..."

That is a revelation. Please follow with more articles like this.

I like to think the development of software as something akin to making music. If startups are Punk, big business is Pop. Manufactured Pop. It makes a lot of money and does the job, but at it's core the product sounds crap and devoid of time for creativity.

There was one guy who was a natural at playing guitar, a born player. He started in school and went on to be a top session player for a commercial company in the UK. It got to the point where he would turn up and be handed a folder of music and would have to play it on the spot, no practice, just play.

At that point he realised he was just a highly skilled session player, churning out muzac. He quit. That man was Jimmy Page who went on to play in Led Zeppelin.

Understanding how these musicians/programmers make the choices and tradeoffs to create, be it commercial muzac or punk rock, hearing about this trade-craft is good value.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: