It Can Be Done (2003)

by kaycebasques • 2 years ago

340 137 2 years ago

agumonkey2• 2 years ago

didn't know about andre bensoussan, but here's a pic of him with louis pouzin (of cyclade and RUNCOM fame) https://multicians.org/shell.html

that said, i always love stories of people taking time to find aesthetics and quality with pen and paper

rokkitmensch• 2 years ago

I don't even smoke, and think that photo is amazing.

agumonkey2• 2 years ago

There's a clint eastwood western style to it I guess

331c8c71• 2 years ago

It can be done no doubt (with some training as any other skill). And probably not by everyone (in the same way as not everyone has the will, motivation and means to, say, completely master a musical instrument or certain sport).

The issue is that this way of working would be even less acceptable in 2024 than in 2003.

That being said, even now there are places where you can work the way you like but the irony is those places won't be on the radar and of much interest to your run-of-the-mill career developer.

onion2k2• 2 years ago

I imagine the main reason he could do that is because he had a very clearly defined set of requirements. Most of what makes software buggy and slow today is that no one actually knows what they're building, and even if they do it keeps changing because "agile". Give a dev a clear API and a well defined set of criteria, and most will write code that works very well.

temac• 2 years ago

Depending on the definition of "dev", they can be the ones who define the requirements and API.

OtomotO2• 2 years ago

That plus a thousand special cases, that are quite often absolutely meaningless to implement in code, but still have to be done.

What do I mean by that: I work for big corporations mostly and quite often there is the average case that is about 90%-99% of all incoming work.

Then there is a myriad of special cases some of which happen every third year on a blood moon, if an eclipse is happening at the same time and the witches chant in the woods...

Instead of managing these unicorn-cases by hand, they have to be implemented in code and lead to bugs and a ton more code to review and maintain.

Speaking of maintenance... oh, don't get me started on that one, it's a sore spot!

makeitdouble2• 2 years ago

TBF, the current dev team might right now is aware of the edge case how to deal with it, the poor shmuck three years down the line when blood moon eclipse witch chant happens probably wont.

In particular, these edge cases tend to be more complex, require more knowledge and have less margin of errors than the standard errors happening 90% of the time. Leaving them as a gift for the future maintainers is a special kind of dick move.

Muromec• 2 years ago

Don't need the moon and witches even. Some datetimes serialized to epoch time around third week of October and here it comes.

nudgeee2• 2 years ago

If you work at a big enough company, that 1% edge case could affect millions of people, so it is definitely worth the brain cycles to consider.

Cthulhu_2• 2 years ago

Clear requirements and a singluar task, doesn't sound like he also had to balance a load of other projects, meetings, rituals, etc. He was able to do deep work as the hype books call it.

I'm probably romanticising it, but it was a time where software engineers and their skills, time and attention span were still respected.

creshal• 2 years ago

We learned to code this way in school, exams gave us a printed copy of the API docs and as much paper as we wanted. Any compiler errors or warnings were point deductions, so people eventually got good at writing code that compiled on the first try.

But in actual professional coding practice over 10+ years, I can count on one hand the occasions where I had clean enough reqs and enough uninterrupted time to design software like that, and still have enough fingers left over to hold a pencil.

lieks2• 2 years ago

Note that Multics had a particularly good work environment: https://multicians.org/devproc.html

In particular, management was tech-savvy and everyone liked and respected each other. Most were also talented.

necovek3• 2 years ago

Nope, he had a well documented set of APIs to program against. In one instance he didn't, they had a crash.

He did "invent" internal and external APIs for his service, just like developers do today: that's the part requiring developers to be like "engineers".

kybernetyk2• 2 years ago

I'm building plain old boring desktop software. The bugs all (ok not all, but most) come from edge cases with users doing "dumb" (totally unexpected) stuff.

If it weren't for users my software would be perfect ;)

shaan7• 2 years ago

It is even more fun for folks writing window managers, they have literal edge cases to deal with xD

lukan2• 2 years ago

You have to expect users will click everthing, any time, while holding any key and if only by accident. If your UI cannot handle it, your states were not clearly defined.

pooper• 2 years ago

I wish we had give the ability to push back on nonsense like even when making a web page, ok make this whole div clickable but inside this div, put another button that when you click the button something else happens.

Or at least spend the time to tell us why we are doing this nonsense and maybe I can come up with a less asinine solution.

onion2k2• 2 years ago

If you put a stopPropagtion in your click handlers by default that problem goes away. :)

CraigJPerry• 2 years ago

> Give a dev a clear API and a well defined set of criteria

If you've got that - why do you need the developer? Genuine question. If the technology requirements are that well defined why on earth do i need to pay engineer level salaries for such basic work? As you said, and i agree:

> Give a dev a clear API and a well defined set of criteria, and most will write code that works very well

At that point of having clear criteria, there are only 2 tasks left:

    1. write some code that satisfies this outcome
    2. write it in a way such that it can be cheaply changed in future

As a business owner, i care about 1 to make bank and as an astute business owner, I care about 2 to keep making bank.

But but but performance! durability! ... <many more of the -ilities of software that an experienced engineer will claim to just take in their stride...>

As a customer of this software developement process, these are just the next cycle of requirements to feed into the machine - hey take this thing you did, make it faster while obeying rule #2 above.

It would not surprise me if ChatGPT were able to cover 80%+ of a problem that well defined.

I totally get the attraction to focus on the fun bit, but it's not how the business world is designed to work in most cases.

For what it's worth i think you nailed the actual value opportunity for a strong dev:

> no one actually knows what they're building

If you can nail that, you're always gonna be valuable. We talk about programming and coding but actually, this is more of the role. The coding part of the puzzle is easy in comparison.

As for:

> and even if they do it keeps changing because "agile"

If your understanding of why requirements are in constant flux amounts to pinning it on "agile", you're not even on the field yet never mind winning the game.

anon22981• 2 years ago

You do realize that good specifications and requirements do not necessarily mean trivial and easy implementation?

Also, indeed, not all dev work is equally costly / hard / basic. It’s a crazy thought, but maybe that’s partially the reason why different devs can have different pay grades. :O

CM302• 2 years ago

This 100%. The issue is that much of the time, project planning is done terribly. The stakeholders have no idea what they want, and will demand extra features/sweeping changes at seemingly random. Lots of edge cases are needed for things that probably shouldn't be done with this tool, but are being done so anyway. The designers often create designs that are at odds with the features needed, how the existing system works, what said stakeholders want, etc. The various teams developing parts of the system don't communicate well and build things in silos. Poorly thought out 'agile' processes end up trying to cram everything into a certain timeframe based on some questionably decided points score. Etc.

For the most part, it's those types of issues that lead to a system not working as intended, or being buggy as hell. If you can get a good setup going where the requirements are clear and don't change and the people on the project communicate well and have full control over the process then things will work out fine. That's seemingly what happened in the source article.

sanderjd8• 2 years ago

I see so much dissonance in this attitude. It's right here in your comment:

The stakeholders have no idea what they want

And yet, you want to put together a project plan up front based on them telling you exactly what to build without assuming there will be sweeping changes? That makes no sense!

Building iteratively recognizes this reality that people aren't sure what they want or need, rather than peevishly ignoring it. The goal is to figure out what would be valuable in a short period of time; if it isn't valuable at all, that's fine, it was not a huge investment and can just be thrown away; if it is valuable but not quite right or not as useful in its current form as it could be in a different form, but the change needed is large or fundamental, that's still fine, even sweeping changes are no big deal on top of something small; and if it's already valuable just the way it is, that's great, move on to the next iteration.

This seems to make a lot of people uneasy, I guess because it provides no formula for answering the question of where things will stand in a year, or even in six months. But it honestly recognizes that nobody knows, rather than setting the expectation that where things will stand is exactly where they project plan says they will, with everyone inevitably getting mad that reality didn't match that plan, or worse, being exactly where the plan said you'd be, except the thing the plan called for was the wrong thing to build and the whole thing was a useless waste of time.

BiteCode_dev• 2 years ago

If you think there were good old days were all software was well specified, you are wearing very rose tinted glasses.

We are inventing the field as we go. Have been for the last decades.

Also it's one of those fields where the expert in the topic must build a system for something he is not an expert with.

Again and again.

And most project are custom.

Agile has nothing to do with it.

It's the nature of IT right now.

himinlomax• 2 years ago

and even if they do it keeps changing because "agile".

Agile is precisely the response to the fact that requirements keep changing, not the cause of it.

makapuf• 2 years ago

Sure, but the fact that it's taken into account gives the message that it's free now and you can without consequences change anything anytime.

itsoktocry• 2 years ago

Give a dev a clear API and a well defined set of criteria, and most will write code that works very well

Someone still needs to do this work, and sometimes that's the developer. Isn't that what he was doing in this anecdote?

m_st• 2 years ago

I fully agree. Yet I'm in the same boat.

Started as a Windows line of business software developer almost 20 years ago. At first we got clear specifications with UI mockups and a description what each and every button should do. When there were questions, these specs where updated and we implemented and tested and fixed until our boss was happy.

Over the years we got more and more customers yet less and less time for tests and fixes. So we switched to "agile" and dropped the specs, instead wrote quick notes about what must (roughly) be done. At first all were happy. But now we have a huge amount of features that not one dev knows. You have to ask and search around until you find all the lose specs.

Now I'm managing such a team of developers and have the same issue. I don't have the time to write a clean specification, yet alone discuss it with the actual customer, which anyway doesn't really understand all the implications. So they start coding by adding more if and else blocks to an already bloated code base.

Pity the days we would start with a class diagram or just some quick drawing about how the components would interact and be testable.

sanderjd8• 2 years ago

People always seem to be scoffing when they say stuff like this, like it's a bad thing. But I don't get that attitude at all. I don't want to work on things where the whole shape of the project is known up front. To me, that feels like doing art with a stencil. I love the process of seeking the most valuable next step to take while we feel our way through a dark room with an ambiguous destination.

Now, the (common) version of this that I don't like is when there is no way to know whether a sequence of steps ended up in a better place than where it began. So feedback is very important to me, but there are lots of ways to get it; there are quantitative measures of growth in usage or revenue and there are qualitative measures like surveys or for things like internal platforms, seeing the roadmaps of other teams be unblocked or accelerated by your work.

But I find significantly less joy in being told "we need this exact specific thing, please go build it and report back", and I have rarely seen it be the case that what they needed was actually that exact specific thing.

holoduke• 2 years ago

Also because many devs do not understand multiple execution layers. From react devs who never heard of javascript native loops to Spring devs who have no idea how sql looks to c devs who have never used a memory heap tool to node devs who never seen io performance impact to ..... You need an all seeing eye to make things performant. Those are scarse. Probably one in the 20 devs max.

rapind• 2 years ago

The reality that most people don't want to hear is that he could do this because he himself was the domain expert.

Requirements isn't just making lists and tickets in swimlanes. It's actually learning the domain you are building for. Sure you can still build for something you don't really understand, but it'll be garbage. In fact, writing this garbage is OK if you accept that it's just a drafting process for learning the domain challenges and potential solutions. There are no shortcuts to quality.

My advice for stakeholders is to make sure you have access to the person(s) building your application and see if they understand your domain (you can do this without constantly pestering them!). Beware bullshitters using buzzwords.

My advice for designers / programmers is to make sure your stakeholders & domain experts are keen and engaged, otherwise getting requirements and understanding is like pulling teeth. Sometime a stakeholder doesn't even want to solve the problem. They may have wanted to go in a different direction entirely or maybe there are politics involved that has them miffed. Nothing sinks a project like lazy or uninterested stakeholders.

JamesLeonis• 2 years ago

My advice for designers / programmers is to make sure your stakeholders & domain experts are keen and engaged, otherwise getting requirements and understanding is like pulling teeth.

I can vouch for this. At the other end of the spectrum, programmers getting thick with their domain experts is like having clairvoyance. I can sometimes spot problems before my PM does!

chrsw• 2 years ago

When I entered the engineering workforce in the late 00s I felt like I was on a team of experts, myself excluded since I was fresh out of school. We were building some complex systems but we had a bunch of people that really knew what they were doing.

Fast forward to today, I'm in a different part of the industry, we're building things that aren't quite as complex but they take longer to finish and the experience is very frustrating. I feel like I'm working in teams where many people don't really know what they were doing but we keep getting pushed for higher story point "velocity" and whatnot. Quality is suffering, tech debt is piling up. This whole thing feels broken.

Jensson2• 2 years ago

Being close to a or being a domain expert yourself isn't enough. Most domain experts don't know the domain well enough to automate solutions for it, you need a much better understanding to program than to do it yourself. So most domain experts will come up with very bad rules for the programmers to implement, and those rules are buggy even when implemented correctly since the domain experts didn't think of everything.

gumby• 2 years ago

The reality that most people don't want to hear is that he could do this because he himself was the domain expert.

Also he was an engineer. Most programmers these days aren't engineers (despite the title) and that's OK for how things are done. But in the 60s most programmers were engineers, and that process is different.

phailhaus• 2 years ago

even if they do it keeps changing because "agile".

If you think "agile" is the reason requirements change...I don't know what to tell you. Requirements will always change, full stop. It's like a force of nature, there is no universe in which everyone just "knows" what to build up front and has a fully spec'd out API that you can go off into a cave and implement. Real life never works that way, and software engineering is not the right profession for you if you need that.

AnimalMuppet2• 2 years ago

Agile is the reason requirements are allowed to change. Non-agile is not changing the requirements, and continuing to build the wrong thing.

But it's not that binary. "Agile" is the reason requirements are allowed to change constantly. At worst, it can be like trying to steer down the freeway by slamming the steering wheel from one extreme to the other. And pure waterfall is also blatantly unworkable.

The real question is, at what rate do you allow changes to be made to the specification/requirements? How much dampening do you apply? And maybe under that, there's another question: How fast can you respond to the real world, and still maintain a coherent direction? The faster the better, but don't try to respond faster than you can maintain coherence.

EasyMark• 2 years ago

It depends on the industry. What you say about not knowing requirements (or at least 95% at the start) isn't true in many industries/situations. They know exactly what they want. And I have worked at those places. I have also worked in agile environments and they are usually organized chaos right up until release. I just code, and I don't care if I have to erase things, I get paid as much to erase as I do to create. I figure it's all part of the process. I do my best for 8-9 hours and go home and let it stay at work, it's the only way I've stayed sane doing the thing I love for many years. I'll do a "push" for a couple here and there but I take that as a sign of trouble when I work someplace if it happens often. So yeah real life does work that way sometimes, some projects do have 95% of the spec at the beginning, just probably not in Silicon Valley.

nerdponx4• 2 years ago

Requirements will always change, full stop

But that doesn't mean you have to stop what you're doing and go chase those requirements.

Why did the requirements change? Is it mandatory that the change happen right now? What research was done to support the requirements change? Was the original requirement bad in the first place? Was insufficient alignment and understanding achieved at the start of the project? Do you actually talk to the stakeholders at all, or does your PM just forward you their emails and expect you to do whatever is in there?

There's a lot of room between "design everything up-front and never change anything" and "allow requirements to change arbitrarily".

cushychicken• 2 years ago

If you don’t understand a problem well enough to write it down, you don’t understand it well enough to solve it.

If you don’t understand a solution well enough to write it down, you don’t understand it well enough to implement it. (Much less get someone else to implement it.)

An overwhelming number of engineers I have worked with seem to think any kind of written design document is busy work, and not actually a part of the process of making something worth using. My experience shows it is not that at all: design docs are a tool to externalize your own thinking, and reflect on its quality without the overhead of keeping it in your mind. That’s their first and foremost purpose. To explain your rationale to others is a secondary objective.

I’m not talking about lengthy requirements documents or specifications, either. I mean a two or three page white paper outlining a problem or a proposed solution in plain English. This is something you can bang out in a half hour or hour if you’re diligent.

Many of the folks I work with never even seem to bother.

raverbashing• 2 years ago

This is a bit of a specific idiosyncrasy

I just can't plan things on paper. Sure, I can try to plan then, but then I see I have no idea how things can/should work or how to best arrange things unless I'm actually typing code

Also the planning on paper usually looks nice but doesn't consider all the real-world imperfections, so your beautiful planning becomes "ugly" quickly

jpgvm• 2 years ago

My experience is that it's a skill like any other, I was bad at it, I wanted to be better at it so I did it more often and now I'm good at it.

Being able to anticipate and find nice design level general solutions for hairy real-world problems is where systems design becomes most rewarding.

Megranium2• 2 years ago

It might also have to do with how programming was taught to a certain generation? At least from my own experience, when I was at university OOP and UML was all the rage, so we had to specify through diagrams in fancy diagram editors, then generate the code from that, and then still re-write everything by hand because it never really worked out quite that well.

I never touched UML again after university ...

kunley• 2 years ago

UML was an abomination, and it's a relief it's completely dead.

bux93• 2 years ago

Well, the code generation was a mistake, but drawing diagrams is explicitly what the guy in this story did:

He started by sitting at his desk and drawing a lot of diagrams. I was the project coordinator, so I used to drop in on him and ask how things were going. "Still designing," he'd say. He wanted the diagrams to look beautiful and symmetrical as well as capturing all the state information.

Cthulhu_2• 2 years ago

I think the modern-day equivalent would be test-driven development; in both cases (unless I don't get it) is that you make sure you understand the problem and write verifications before you start on a solution.

Of course, this doesn't work for every problem / task.

quickthrower2• 2 years ago

As well as a bit of genius the key here is being able to understand every layer of the stack from the chip upwards which was probably more achievable then.

musiciangames• 2 years ago

I worked with a defector from the Soviet Union. He told me the reason Soviet programmers were so good was that they had very limited access to computers. If you had to program using pencil and paper, you wanted to make it work first time. (Coincidentally we were working for Honeywell).

viraptor• 2 years ago

Alternatively: only people who were into it enough to handle doing things on paper and with limited access to computers kept working afterwards.

So: was it a good way to teach or a good way to filter out less motivated people?

Megranium2• 2 years ago

I guess it was at a time when computers weren't ubiquitous as they're today, and an average non-technical person might have never touched one.

In that days, designing on paper was probably just the default mode of working ...

littlestymaar• 2 years ago

It cannot be the only effect, since this pen-and-paper effect manifests itself in other places: when you kook at old industrial systems' plans (nuclear power plant in the example I have in mind) you're very surprised to see how small the number of revision is for the plans: because it's very tedious to re-do the entire plan from scratch by hand, people used to be extremely cautious when design them. Today with CAD software, revisions are cheap and producing half backed plans that need later correction is the norm.

Maybe the new way of doing thing is still more efficient in the end, but maybe not.

schnitzelstoat• 2 years ago

It's only relatively recently (like since the 00's) that CS has become this sexy field due to sky-high salaries (at least in the USA).

Before then filtering out less motivated people wasn't as much of an issue, as they had little incentive to study CS in the first place.

treprinum• 2 years ago

He must have been one of the privileged few with access to pencil and paper then.

lieks2• 2 years ago

I can attest to this. Once, a college teacher gave us a programming exercise, and then went on to suggest how we might go about solving it.

While he was talking, I started outlining a solution on a piece of paper. At school, I couldn't use a computer during class, so I'd gotten used to programming (and debugging!) on paper.

When I arrived at home, I typed it in and tried it out. Could I possibly reproduce that Multics story I'd read about?

It didn't compile the first time, but after correcting a variable name, it worked perfectly.

Arisaka1• 2 years ago

When we learned COBOL in high school we did it in pen and paper mostly because the school labs didn't had enough PC's for every student, and we ended up working 3-4 students per computer.

m463• 2 years ago

I learned on computers where cards and printouts were the I/O system.

I remember a number of years where the edit->compile->print loop was much better with listings than terminals, simply because you couldn't see/navigate/edit your code as efficiently. It eventually improved with better/visual editors, larger terminals and faster compiling and running.

An analogy might be early firearms, where things like wet gunpowder, unreliable flintlocks and pushing everything down the barrel made for an inefficient transition time from the longbow.

xeyownt• 2 years ago

How did André do this, with no tool but a pencil?

Using his brain. Intensively ;-)

Reminds me a story that happened to me. I was doing some heavy changes to some library, then started running the tests. The tests were failing, and without looking at log I knew immediately where the bug was. So I fixed that, launch the test and again same story. And again. At the 4th time, the cause was not immediate so I was considering looking at the log when I noticed I was not actually running the program at all, but was executing something else!

So to find bug, you just need to ask yourself where it will fail, and fix that ;-)

euroderf• 2 years ago

pebkac ?

defrost• 2 years ago

Programmer Exists,

Bug Kausing Almost Certain.

virtualbluesky• 2 years ago

Problem Exists Between Keyboard And Chair

ChrisArchitect• 2 years ago

(1994)

necovek3• 2 years ago

Well, the systems are way more interconnected today, esp over less stable interconnects (internet!), with nothing really being done serially. That in itself makes programming multiple times harder. Add to that that devs are usually dealing with external, badly documented interfaces (eg. The Cloud, frameworks...), and it's impossible to know how something will work without trying it out (just like they had with the error handling bug they hit: now multiply that by 1000 or 10000 of today's usual external API usage in a non-trivial program).

But the other missing piece to this is how much time did this actually take (there is an implication "designing" took its sweet time)? Would the modern way of coding on a computer be faster with the same number of incidents?

szundi• 2 years ago

Back then it was possible with the human brain.

dang• 2 years ago

It Can Be Done (2003) - https://news.ycombinator.com/item?id=18415231 - Nov 2018 (18 comments)

countWSS• 2 years ago

The software at that time was just much smaller. The size of most projects, anything above a toy program is in megabytes and will be impossible to "write down" as single file.

tgv• 2 years ago

OTOH, there were practically no examples to draw from. There was no virtual memory class in their OS-101 course. These people pioneered OS design.

adrianN• 2 years ago

I often find it easier not to introduce bugs while I pioneer something than when I integrate with a mountain of existing stuff.

LAC-Tech4• 2 years ago

I'm sorry but the line of business software most of us work on is not more impressive than writing a major component of a file system from scratch.

kragen2• 2 years ago

i was surprised to find that my natural-language notes from my electronics notebook from the last month total a quarter megabyte already. about 37000 words of markdown

a small fraction of that is urls for electronic parts, but nearly all (90%, say) is just english text. another 10% is stuff i quoted from other people (web pages, manufacturer app notes, books, etc.) it is a single file and will probably continue to be a single file forever, at least for the rest of the year. if i continue at the same pace, that will be 12 megabytes. there is nothing impossible about that at all

(if you're interested, git clone http://canonical.org/~kragen/sw/leatherdrink.git. it's currently almost 200 megs because i checked in the avr toolchain. there are also photos and videos and schematics and stuff)

in a programming language the growth would be fewer bytes per month, but perhaps by a factor of five

coldtea2• 2 years ago

The software at that time was just much smaller.

Do go check the code: https://multicians.org/vtoc_man.html

This is both bigger and more complex than most stuff people work on today (which is glorified glue code for bullshit CRUD/REST/etc). It might be smaller than the overall LoC of their project, but it's more than the units they deal with (and this is part of an overal OS code anyway).

This is a whole "manager, to manage file description information. It had to transport the file information between disk and memory, manage a shared memory buffer pool, and manage space on disk for the information."

Dare most current programmers to write such a thing, with the requirements and semantics it has on his version, today, in their language of choice.

Most would be lost at even contemplating that. Much less write it in paper and type it in and have it work.

kandelt• 2 years ago

Everytime something impressive is posted, a real feat, the comments mostly pick on it. Please stop

kybernetyk2• 2 years ago

Modern devs are frustrated. They don't do anything of importance or significance anymore. They're not the guy designing a virtual memory manager for a novel OS. They're just some cog in a machine converting SQL queries into HTML to show ads to kids and old people.

One can only become cynical and bitter.

kome• 2 years ago

spot on. plus using a lot of js because they don't know html and css (or just very superficially). :-)

elzbardico• 2 years ago

Since the beginning, most developers in history wrote payroll and accounts software. Now they do cat photos sharing apps. If anything, I consider this an improvement.

Etheryte• 2 years ago

Every time comments are posted, a real interactive discussion, other commenters pick on it. Please stop.

LAC-Tech4• 2 years ago

But you don't understand, I once had to replace chart.js 3 with chart.js 4 and the documentation didn't cover all of the changes. This man would have collapsed into a heap if he'd had to face the challenges I've faced.

Perz1val• 2 years ago

Like unironically, the things we deal with would be equivalent of somebody coming in, dumping a bucket of mud on his pretty diagrams and saying "integrate with that"

necovek3• 2 years ago

Every time someone posts a counter argument, people pick on it. Please stop.

Oh really, don't: that's what the discussion should be about.

You are certainly right to a point, but a better way to redirect positively is to ask: how can we come to a state where similar feats are possible today in a company setting?

sanderjd8• 2 years ago

I understand this attitude, but FWIW, when I got here 5 hours after your post, all the top comments were very positive and not picking on it at all. And that's how it usually is when I see one of these comments like yours. It takes a little time for the sieve of user moderation to bubble the better comments up to the top.

frozenwind2• 2 years ago

As I sat down at my desk to start the work day and finish a dreaded task, my mind of course immediately drifted away and felt the urge to check some news on reddit or HW. I opened HW and this is the first title.

"It can be done".

Thanks for the motivation!

P.S. Of course, I also read the article :).

siwatanejo• 2 years ago

s/HW/HN/?

frozenwind2• 2 years ago

HN.... I have an app on my phone that's called "Hews". It's morning and everything is confusing :(

DeathArrow• 2 years ago

How did André do this, with no tool but a pencil?

When I was 14 and went to highschool, for programming classes I did most of my code on paper. I was a poor kid in a poor country, so not only I did not have a PC at home, but the few "computers" we had in the computer lab at school were ZX Spectrum clones which didn't run Turbo Pascal, the programming language we used at that time.

LAC-Tech4• 2 years ago

I would love a more systematic approach to this none-coding part of coding. I mean I doodle little diagrams and write notes on scrap paper but nothing so rigorous as what Andre is doing.

revskill• 2 years ago

Given the input, the correct data structure, you can.

i_am_proteus• 2 years ago

There's a good comment from account jrd259, who worked with Andre, in the previous HN thread about this article (https://news.ycombinator.com/item?id=18415231). It relates the importance of a private work space with large desks and no notifications.

sssilver• 2 years ago

This comment really deserves more attention.

Multicomp• 2 years ago

Agreed, here's the quoted copy/paste for those scrolling by:

Former Multician here. Andre was super-smart, but it is perhaps also relevant that even the most junior developers (as I was then) had quiet private space to work with large desks. All design was done offline. Multics terminals were like type-writers (although video did show up near the end), hence no stream of popups. The environment both allowed for and demanded focus and concentration. This is no longer so.

paganel• 2 years ago

Multics operating system at Honeywell in Cambridge

Still surprising how much entrenched the computer industry was (and probably still is) within the military complex.

I'm curious if there is a list somewhere with big, consequential IT/computer programming stuff that has NOT had any direct connection with the military.

p_l3• 2 years ago

Scams and ad-pushing? Persistent Invigilation by ad-serving companies also surprisingly started out in commercial space, not military, from what I know.

Timwi• 2 years ago

This is reminding me of two times in my life that I was programming on paper.

The first time I was maybe 10–12 years old. We were visiting my grandparents, who had no computer (and there were no smartphones). They did, however, have a (mechanical) typewriter that had the ability to type in both black and red with a switch. Back then my main hobby was Turbo Pascal, so I used the typewriter to write a Pascal program that I would later type up into the PC and run when we got back home. We spent a week at my grandparents, so I had plenty time to think it through, debug it by hand, and re-type sections that were faulty.

The second time relates to an esoteric programming language I invented called Ziim (https://esolangs.org/wiki/Ziim), and more specifically, the binary addition function you see on that page. It's huge and complicated... and it had a bug, which I knew because I ran it in an interpreter, but I had no idea where the bug was and how to fix it. — Around that time, I had a long bus ride coming up; sitting in a coach for like 6 hours or so. That was a perfect opportunity to debug this. I transferred the Ziim addition function to square-ruled paper using a pencil, and then, on the bus, I executed it by hand, step by step. I found the bug and was able to fix it. It required redoing the entire function layout.

I guess the moral of the story is that restricting your own ability to do things the “easy” way can sometimes lead to well thought out code. Despite, I don't do this regularly at all. I will just as soon write half-arsed snippets and iterate, grab a debugger to step through code, etc. Maybe I should rethink that?

donkeybeer• 2 years ago

It works because normally you do most of the thinking in your head, so the few occasions you are doing deep thinking using paper and pen, you have the discipline and care to only write what is important and keep the rest in your head. If you do everything on paper, it will start being not much different than doing everything directly on computer because you will be writing everything and you will lose that abstraction and care.

lqet• 2 years ago

Here is the code written by André Bensoussan: https://multicians.org/vtoc_man.html

coldtea2• 2 years ago

Hmm, have never seen much of PL/1.

Control flow aside, the syntax looks surprisingly clean.

smikhanov• 2 years ago

So the answer to "how did he do it?" is obvious -- it simply wasn't too complex of a task (by modern standards).

abecedarius• 2 years ago

I wouldn't measure difficulty of a design problem by the complexity of a solution. "This is so much simpler than I expected" is some of the highest praise.

(About this particular problem I have no idea.)

gwern• 2 years ago

I don't know about that: is it 'not complex' or did he succeed at the design? Implementing core components of a file system in a few pages sounds quite complex to me - I'm getting a bit scared just reading that comment explaining why the race condition is harmless.

ChrisMarshallNY• 2 years ago

Well, when I started, it was the waning days of "big iron."

In Ye Olde Days, "programmers," were usually little more than data entry clerks (often, women). The people who wrote the software would be in offices, filled with smoke, writing the programs on paper.

Compute time was expensive and precious. If you got a bug during your run, you wouldn't get a chance to fix it, until you could schedule another data entry session, and another CPU run.

It encouraged a "measure twice, cut once" approach. Since most software, in those days, was fairly humble, compared to the de rigueur, these days, it was easier to do. Also, software usually had extremely restricted I/O. UI was not even a term, and peripheral connection was a big deal.

These days, I often "throw stuff at the wall, and see what sticks," when writing software. It's easier for me to write some half-baked crap, and debug it in the IDE.

My software development tends to be "iterative." I write about that, here: https://littlegreenviper.com/miscellany/evolutionary-design-...

stavros• 2 years ago

This is exactly it. People are lamenting the bygone days of having to think a lot about your software before you wrote it, but the truth is that, today, the same programmer would have been able to iterate his way to the same program in perhaps half the time.

I remember an assignment in my university course, where I had to write a (simple, admittedly) OS kernel. I didn't know C very well, and I didn't know what kernels did beyond the theory, but we had to write a few hundred lines of C code to manage tasks. I knew that there would be absolutely no way I could debug this program if it didn't work, as it was all parallel code and a bug would mean mysterious race conditions.

I reasoned about the system as a whole, and I spent a few days writing small, self-contained functions that I thought a lot about. I then compiled and ran it, and, after the obligatory "missing semicolon" compilation errors, it worked first try.

virtualritz• 2 years ago

My first exposure to programming was GWBASIC on the 8086 PC clone of my uncle. I was 12. My uncle lived over 500km away from my home.

I saw him once a year, when my family came together for xmas at his house.

In the 12 months in-between I wrote tons of BASIC code with pencil. And then typed it in at xmas. That lasted for two years, until I had saved enough pocket money to buy my first PC.

The experience was very similar. Stuff just ran & worked as expected.

If you write code by pencil you just think a lot more before putting anything down on paper. As any corrections are a nightmare -- except for the last line. You can't just insert a code block etc.

alphazard• 2 years ago

Certain kinds of systems really have to be designed ahead of time. The alternative is an incomplete system. You might never get anything working without a design.

Observability and trial-and-error tooling are a big deal. They enable the workflows that allow developers with a poor conception of the system to brute force their way to fitting requirements. The popular ethos around shipping the first thing that works, often, only works when you can see what you're doing, and the cost of bugs in production is low. That's software in 2024: mostly unimportant garbage.

For this kind of system at this point in time, a full design was the only way. The article hints at a touch of perfectionism (which probably didn't help the timeline), but it's not like he would have been more likely to guess and check his way to a working memory management system in less time with the sans-design development style popular today.

RugnirViking• 2 years ago

Wow, that sounds like a dream work environment. Sounds like he had a good amount of time to get it right, a well defined but tough task, and near total freedom to architect it. Gotta admire everyone involved.

andai• 2 years ago

A friend told me that when she was in school, they'd hand in their programming assignments on paper, and a week later they'd get the output. She said week-long "compilation times" make you learn to double check your work!

deely3• 2 years ago

Im not sure that I like this approach. Documentation very rarely cover all 100% of nuances. There always will be "test and see" part of learning in my opinion.

For me its like you can use paper for drawing but only 10 minutes a day. Or piano but only every second Monday for few hours.

shermantanktop• 2 years ago

I love the idea of this but it is so, so far from the iterative approach I normally use.

When I have taken this approach - pencil and paper - I find that it accelerates the initial big decisions (e.g. "what will this module's responsibility be?") but sometimes causes rework when I discover that I was optimistic or unaware of how two areas of the code interact.

Perhaps I'm just not doing it thoroughly enough.

tanseydavid• 2 years ago

How did he do it?

Simple. Agile/Scrum had not yet been conceived of.

edub• 2 years ago

Many great anecdotes in this thread. Many regarding lack of access to a computer while designing code.

Mine is as a child wanting to try to work on the computer every moment I was awake, but parents insisting that it is important for me to got to bed so I can go to school the next day. My solution to continue to working on the computer when I was expected to be in my bedroom was to keep writing code from my room but on paper.

I'd often stay awake with pen and paper until 4am, and maybe sleep during class the next day. But without the computer to give you the feedback of compiling your code and being able to test it, it forced my mind to try to reason the code I wrote on paper to think through if it would work as I expected.

So maybe 15 minutes writing on paper what I thought the code should be, and 45 minutes reasoning with myself if what I wrote would work the next day when I typed it into the computer. It kinda trained me to compile code in my head, and it was a practice of mine for years throughout middle school and high school.

I'm not sure I would have had the same understanding today as I do now if I had access to the computer throughout the night and could keep doing trial and error with the computer to get my code to work. Even though I was working with BASIC at the time, I think it shaped how I think about working with the languages I use today.

It Can Be Done (2003)

Related Stories