The story of Mel

Christ, it’s a while since I’ve seen that! You’ll be unearthing the Hacker’s Manifesto next.

You’ll be unearthing the Hacker’s Manifesto next.

Ah the memories, an a4 folder containing the Jolly Roger cookbook which in turn contained said manifesto. The paper was probably more of a fire risk than most of the crap in there.

Excellent. I worked with a guy who was at least one variant of Mel (@donald will probably recall him). His was the archetypical write-only code. One function of 4,000 lines – no bother.

He’d written an encryption program for floppy disks that relied on reading past the disk sectors, and hiding hash keys in those dead blocks (I think – I tried to understand it, written in 8086 assembler, but never mastered the code).

It was for a while a great earner for our company in the early days.

There were other veterans from previous companies who were absolute whizz at ICL microcode. Brains the size of planets. Not sure they were any good at indexing gears though 🙂

Before I start to read that,is it worth my time or some weird in-joke? I’m not an IT guru.

Cougar

…You’ll be unearthing the Hacker’s Manifesto next.

After my time. 🙂

Before I start to read that,is it worth my time or some weird in-joke? I’m not an IT guru.

Unless you’ve programmed assembler or machine code, I’d say don’t bother….

Ah the memories, an a4 folder containing the Jolly Roger cookbook which in turn contained said manifesto. The paper was probably more of a fire risk than most of the crap in there.

I had that on a 3.5″ floppy. Never did get around to making thermite.

After my time. 🙂

Bugger off, really? How old are you?! That was, what, mid-80s?

Cougar

…How old are you?

Pre Algol68.

Have you had your letter from the Queen yet? (-:

I’d sooner one from Admiral Hopper. 🙂

Yeah, and Mels are a significant reason why development projects are structured as they are nowadays. To stop bellends from writing unintelligible code, keeping the knowledge to themselves, and generally using that knowledge to be a difficult arse such as refusing to meet the (reasonable) requirements of their employer. Good for Mel’s ego, though.

It’s just not comparable.

These days we have the luxury of being able to write code for maximum readability. Back then, Mel’s code might have taken two bytes and yours eight. That shit was important, it was gold. Skipping a line of code to implement a delay because you knew you could achieve the same result by simply waiting till the disk spun back around, that’s genius.

I forget the exact details now as it was a long time ago, but paraphrasing roughly from memory I’ve seen code where the first step was to define a constant i=0, because storing i took 7 bits and storing 0 cost 8.

Write Elite in 32kB using modern programming techniques, I double-dare you.

But even then, you’d still expect it to be documented to such a level that the author of the poem wouldn’t have had to spend days figuring out some arcane looping shit to work out how the program cheated at the game.

As someone who’s been in the position of the author, I’m quite glad the days of Mel are gone. They were geniuses sure enough but some of the foundations they built for software development as an engineering disciple and profession are just horrendous.

I’m actually finding this one of the more interesting threads!

Write Elite in 32kB using modern programming techniques, I double-dare you.

I think the challenge applies to modern languages and architectures rather than techniques. The difference today is our tools and environments allow poor technique to get through. People still squeeze amazing stuff into tiny environments. Tensorflow on the Pi for example.

bensales

…They were geniuses sure enough but some of the foundations they built for software development as an engineering disciple and profession are just horrendous.

The be all and end all was minimising the time an exorbitantly expensive physical resource devoted to running a programme because there would be a queue waiting for the next slot.

The lack of documentation in this case would more than likely a decision by his superior not to waste valuable programmer time documenting a throwaway programme.

The genius here was not simply his ability to write short code fast, but his deep understanding of the inner mechanical workings of the computer – a true hot-rodder.

And at that time we expected all our code would be quickly redundant because of the way the industry was going. Stuff like the Y2K panic can be put down to decisions by the bean-counters to keep using systems running programmes long past their use by date. It wasn’t as if they weren’t told.

I don’t really know a great deal about computers or coding but Mel comes across as a bit of a tadger.

I’m glad Mels are (mostly) gone.

It takes twice as much brain to debug a program than to write it. Never be as clever as you can be when you write your programs.

See also The Soul of a New Machine.

I think what was important that the programming team wasn’t just comprised of Mels, there would be more broadly thinking folk as well – who would hopefully reign things in.

When there is no time allowed for testing, despite a programming team specifying that – I’m not sure that’s really the fault of the developers.

One of my first jobs upon joining a software house in the mid-80’s was to trawl through some undocumented code trying to save space. the target machine had no concept of virtual memory, so saving any space was worthwhile. I became a hero for finding a 4k array that could be shrunk to 1k by some cleaver coding.

It’s a bit sad to see retrospective standards applied to what Mel did there.

He was asked to knock up a one off programme for a demo, not a mission critical job. If you were his boss would you want him to spend no doubt considerable time to document it, or get him back onto revenue producing work?

He impressed his peers who were no slouchs.

Remember how people were explaining last week that Business Analysts are unnecessary, and the business should just talk directly to the developers and let them get on with it…

Totally this:

It takes twice as much brain to debug a program than to write it. Never be as clever as you can be when you write your programs.

Infact if I could be arsed I would find you some citations about software systems being about 20percent effort to write initially and the remaining 80 percent being (limited) improvement and maintenance. Which brings us right back full circle to the BA thread: only create what you absolutely NEED to. As Tyler Durden in fight club said: the things you own, end up owning you.
Never a truer word spoken when applied to IT.

And yeah the days of Mel were a lot different and you are right to point that out, The optimisation that needed to be applied was totally different then as it is today.
The problems involved in IT have changed over time as the industry has evolved along with the environment in which it exists.

However I DO NOT agree with the hero worship aspect. There were clever people then and there are clever people now. There wasn’t a golden period of cleverness. It’s just the problems and process are different – for the better. In modern day IT it is an anti-pattern to have heroes on your project. (It is an indicator that something is going wrong. I am fully bought into this view)

I used to get asked in interviews* what was the best piece of code of which I was most proud. I would say that all my code is trivially simple, because I always deconstruct the problem well enough in the first place. This is my idea of good programming craft – making it look easy.

Don’t be like Mel. It’s all well and good showing off for your own amusement, but it’s a shit thing to do to your successor and the business you work for. Ok so Mel is just amusing himself, but you’d be surprised how often this kind of thing happens in real life.

If you aren’t in the business, you won’t appreciate how radically things have changed since then. In those days it was like being a pioneer, cutting down trees and building your own log cabin. Now, it’s like building an office block.

* sometimes it worked, sometimes it didn’t 🙂

Eh.

The thing here is that however you slice it, maintenance coding is a shit hand to be dealt.

I’ve had to do it with my own code and looked back going “WTF was I thinking?” My documentation was always inline and it was 50:50 explaining what was going on and an insight into my own mindset when writing (like studying Shakespeare with the Cliff Notes).

One time I revisited a piece of code that I’d annotated: “don’t bugger about with this, you’ll break it.” I thought, that was years ago now, I can improve on that. Soon afterwards I figured out a way of optimising it and rewrote it. Everything broke. Two-years-ago-me was wise.

Another time I tripped over a paragraph of a brain dump. I’d written a calendar / diary app which processed data correctly, sometimes. Long story short, the back end database accepted UK date formats like 21/1/19 quite happily but if you fed it says 11/1/19 it assumed that was the first of November. No errors or alerts or anything. I had a full on rage in the source code comments about that.

You can have simple code, elegant code, easy code, efficient code, clever code… eh, pick any one.

+1 to above.

People that say their code is nice to work with are lying or have worked in some sort of environment that must have increable resources to to refactor. Never has to do live fixes under extreme pressure and code bases that are all either only a year old or under such constant rewriting they are triggers broom. 10, 20 year old code base, written for various architectures, ported they ported again, complex calculations with bodges to deal with io timing issues, management request at last minute while on-site. Live fixes put in place while a taxi waiting to take you to the airport. Garenteed mess.

I always aim for the well layed out and documented code but real life happens.

Maintenance programming is shit but also quite a fun challenge at times!

I think the Story of Mel should be viewed as a modern(ish)-day myth or legend, a sort of set of Platonic ideals, rather than a blueprint for how to actually behave.

Note, for example, that Mel is not programming in assembly or anything wasteful like that — it’s machine op codes. And you can’t port his game from one machine to another for the simple reason that they’re completely different machines and the machine code is therefore different.

The fact that Mel is only really discussed in terms of his programming artifacts is significant: he’s like the ur-programmer, so deeply intwined with the inner workings of the computer that he has ceased to exist in any physical realm and we only know of him through the code he left for us, like breadcrumbs on the path to enlightenment.

Complaining that Mel would be an pain in the butt to work with in Real Life is rather like complaining that you couldn’t figure out what Cypher was seeing as he gazed into the chilly green symbol-stream of The Matrix. The whole point is that you couldn’t.

So, yes, don’t literally be like Mel. That would be a bad idea, in the same way that it’d be a bad idea to literally fight dragons with swords. Instead, be like Mel in the best possible sense: become one with your code, with the machine! Follow with dedication the narrow path toward Nirvana. Because although you’ll never get there, you may get somewhere better: that place where everything compiles and actually bloody well works!

And of course, do comment your code, do indeed split it sensibly into functions, do give your variables sensible names, and generally do your best to retain order in the endless fight against entropy that is keeping any software project going. Because at the end of the day none of us are Mel, we all live in the real world, and we all want to avoid our colleagues murdering us over a badly written sub-routine.

I became a hero for finding a 4k array that could be shrunk to 1k by some cleaver coding.

Nothing like dropping the last 3/4s to save space, just hope there wasn’t any important data there 🙂

The thing here is that however you slice it, maintenance coding is a shit hand to be dealt.

I actually quite like the challenge of maintenance coding – it’s so much harder than green-field coding, which is very rewarding. Digging down into the code, trying to figure out WTF is going on…

actually quite like the challenge of maintenance coding – it’s so much harder than green-field coding

Not always true, I know some people who are great at refactoring code written by others, but lack the creativity when it comes to creating new solutions to new problems. I also know people who are the opposite.

I actually quite like the challenge of maintenance coding

Oh, sure. I quite like the challenge also. I just sure as hell wouldn’t want to have to do it every day.

I think the Story of Mel should be viewed as a modern(ish)-day myth or legend, a sort of set of Platonic ideals, rather than a blueprint for how to actually behave.

I don’t think it was ever intended to be a “be more like Mel” tale, rather I hear Simon Mayo’s Drivetime team going “different times Sister Bobbie, different times.” The machines mentioned would date “Mel” to the early 1960s, 20 years before that tale hit Usenet.

I also think it’s a function of a programmer’s path to that role – the guys I worked with, the more senior ones, were of an age were their degree (if they were degree educated at all – one was a plumber IIRC) was in a related subject – maths, likely – or possibly something else entirely, astro-physics anyone? I think that gives a different outlook – the industry in its infancy, they knew what didn’t work, even then rigid application of the waterfall method was not entirely a good thing, and The Mythical Man Month was required reading.

People that say their code is nice to work with are lying or have worked in some sort of environment that must have increable resources to to refactor.

hi

My code is nice to work with. It has to be. It’s also fully, and I mean all possible paths and logic combinations and permutations of inputs and the whole nine yards, tested and documented.

Yes, we’re expensive. If our stuff goes wrong people tend to die (aerospace).

This was the environment for the likes of Mel. Check out the cost of 1 bit of memory – especially in the early days. You can see why you would be economical.

https://en.wikipedia.org/wiki/Magnetic-core_memory

https://en.wikipedia.org/wiki/Drum_memory