Get the top HN stories in your inbox every day.
breck
olau
I can recommend The Design of Design. It's a bit chatty, but I haven't seen the material in there elsewhere, and it did change my perspective quite a bit, to the point where I could see some "conventional wisdom" at the time being entirely wrong.
simulo
> but I haven't seen the material in there elsewhere
Indeed. The references are full of works to studies from the Design Studies journal, in-situ work studies, works of philosophy etc.
jlukic
The Design of Design was one of the primary inspirations for my open source project Semantic UI.
"[Progressive truthfulness] is perhaps a better way to build models of physical objects...Start with a model that is fully detailed but only resembles what is wanted. Then, one adjusts one attribute after another, bringing the result ever closer to the mental vision of the new creation, or to the real properties of a real-world object
...Starting with exemplars that themselves have consistency of style ensures that such consistency is the designer's to lose."
Frederick Brooks - The Design of Design
ArcMex
Thanks for sharing this.
pjmorris
MMM deserves all the attention it gets, but there's more!
1. I've got to track down the source of the quote (it may be the linked video), but Brooks has said that the most important architectural decision he made was to have an eight bit byte rather than the cheaper 7 bits (Edit: 6 bits) being considered for the IBM 360. To call that influential is an understatement.
2. And he has said the most important management decision was sending Ted Codd to graduate school, where Codd laid the foundation for what became relational databases.
3. A paper [0] he co-authored with Amdahl and Blaauw introduced the term 'architecture' to computer hardware, later borrowed for software. From the first page: "The term architecture is used here to describe the attributes of a system as seen by the programmer, i.e., the conceptual structure and functional behavior, as distinct from the organization of the data flow and controls, the logical design, and the physical implementation."
He gave an interesting talk at the 50th anniversary of the International Conference on Software Engineering (ICSE) a few years ago, [1]
[0] 'Architecture of the IBM System/360', Amdahl, Blaauw, Brooks.
dalke
> eight bit byte rather than the cheaper 7 bits being considered for the IBM 360
That's 8-bit vs. 6-bit bytes. See "Interview: An interview with Fred Brooks", Communications of the ACM, Volume 58, Number 11 (2015), Pages 36-40 https://dl.acm.org/doi/fullHtml/10.1145/2822519 .
> Gene's machine was based on the existing 6-bit byte and multiples of that: 24-bit instructions and a 48-bit instruction or floating point ... Of all my technical accomplishments, making the 8-bit byte decision is far and away the most important. The reason was that it opened up the lowercase alphabet. I saw language processing as being another new market area that we were not in, and could not get into very well as long we were doing 6-bit character sets.
From your [0], "Architecture of the IBM System/360" (1964) at https://cpb-us-w2.wpmucdn.com/sites.gatech.edu/dist/8/175/fi... see the section "Character size, 6 vs 4/8", which discusses 4/6, 6, and 8-bit codes and the reasoning for 8-bit, and which comments:
> The selection of the 8-bit character size in 1961 proved wise by 1963, when the American Standards Association adopted a 7-bit standard character code for information interchange (ASCII).
FWIW, [0] is from April 1964. He also used "computer architecture" in the earlier "Architectural Philosophy", which is chapter 2 of the 1962 book "Planning A Computer System" concerning Project Stretch, at https://archive.org/details/bitsavers_ibm7030Plam_46781927/p...
pjmorris
Thank you for the corrections, I learned something.
kristianp
7 bits was enough for ASCII and lower case, why not 7?
sedatk
I'd guess because it's not an even number. I don't know why even number of bits were considered infeasible, but there hasn't been a single computer architecture with odd number of bits as word length: https://en.wikipedia.org/wiki/Word_(computer_architecture)
dalke
My one email exchange with Brooks had nothing to do with Mythical Man Month.
In the 1990s I was was the junior co-founder and, for a while, main developer of VMD, a program for molecular visualization. I wanted to include molecular surface visualization, but me being me, would rather integrate someone else's good work.
I looked around and found "Surf", a molecular surface solver written by Amitabh Varshney when he was at the University of North Carolina. (See "Computing Smooth Molecular Surfaces", IEEE Computer Graphics and Applications, https://ieeexplore.ieee.org/abstract/document/310720 .)
Brooks, you may not know, heard Sutherland talk about using the screen as a window into another world, which got Brooks interested in VR. Back in the 1970s, at UNC, they started experimenting with head-mounted displays. Brooks worked on VR for the rest of his career.
The UNC VR group worked on many different VR approaches, including haptic (tactile) feedback. As I recall, the first was a used hydraulic-powered robot arm. People had to wear a lab coat and helmet when using it because it would leak, and had a tendency to hit people.
One of the experiments, the NanoManipulator, hooked up the VR and haptic feedback (not that same robot!) to an atomic-force microscope, so people could feel the surface and move nanoscale objects around. http://www.warrenrobinett.com/nano/ .
Brooks felt that VR would be very useful for molecular visualization, and developed the GRIP Molecular Graphics Resource. Quoting https://apps.dtic.mil/sti/pdfs/ADA236598.pdf , some of its early achievements were "the first molecular graphics system on which a protein was solved without a physical model", "using remote manipulator technology to enable users to feel molecular forces", and "Real-time, user-steered volume visualization of an electron density map".
As that document points out, their goal was to "wildcat radical new molecular graphics ideas to the prototype stage. Winning ideas are spun off to the thriving commercial industry or into autonomous research projects."
Surf fit very well in those lines, as VMD was an "autonomous research project".
My exchange with Brooks and UNC was 1) to get permission to distribute Surf as part of the VMD distribution, and, 2) a few years later, to provide numbers about how many people had downloaded VMD with Surf.
gregcoombe
Side story: the haptic feedback for the NanoManipulator was through a hydraulic system (kinda like this? https://www.sarcos.com/wp-content/uploads/history_5-339x280....). There were hydraulic lines that were piped through the building down to the machine room (where the SGI Infinite Reality Engine was!). Someone read through the manual and realized that the force that the arm was capable of could easily break someone's arm, and since it was usually grad students working late at night programming it, they decided it would be safest to just decommission that. I think I got one of the last demos during a UNC grad school recruiting event.
dalke
I may be mixing up my robot arms! I visited the lab around 1995 and saw a smaller robot arm than the one shown in Figure 2 of https://dl.acm.org/doi/pdf/10.1145/166117.166133 .
The big arm from Figure 2 is "an Argonne III Remote Manipulator".
Oddly, I can find no mention of that ARM outside of its use for the NanoManipulator. I did find https://www.ks.uiuc.edu/History/VMD/ (my old haunting grounds!) say:
> Computer scientist Frederick Brooks describes his chance encounter with the man who designed the manipulator as providential. In the 1950s, at Argonne National Laboratory near Chicago, Raymond Goertz and his group developed the ARM, the Argonne Remote Manipulator, a force-feedback device used to manipulate radioactive material in contaminated areas unsafe for humans to enter. Users gripped a device and moved it with their hand, and then signals were transferred to a robotic hand inside the contaminated area, which the users could see through glass. In the late 1960s or early 1970s Brooks met Goertz, the primary developer of the ARM, and Goertz arranged for Brooks to receive a manipulator that was no longer in use. ...
> While trying to use the donated remote manipulator with a computer in the 1970s, Brooks realized that he needed at least a hundred times more computer power than was feasible at the time, and he sidelined his work with the ARM until 1986, the arrival of the VAX computer. ...
Oooh! And you can see a few pictures of a young me in that UIUC link!
parag_chandra
Yes, the NanoManipulator! I remember getting a demo of it during the grad student “research assistant job fair” when I first started there over 20 years ago. It was like magic, and what got me excited to study computer graphics. Unfortunately after taking the intro class (taught by Brooks himself) I realized I wasn’t cut out for all the complex math involved, so I switched to medical imaging instead. Still, Dr. Brooks was a great lecturer who injected a lot of his own personal experiences into his classes, and I ended up taking his computer architecture class later on.
rychco
I have fond memories of attending his "No Silver Bullet" lecture only a few short years ago.
A favorite quote of mine from MMM: "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures...."
lolinder
The quote is worth reading in full, available here [0]. Brooks captured so perfectly my own experience programming. Sometimes the job is boring and hard, but then there are the moments that are pure magic:
> Yet the program construct, unlike the poet's words, is real in the sense that in moves and works, producing visible outputs seperate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on the keyboard, and a display screen comes to life, showing things that never were nor could be.
thundergolfer
“Castles in the air” was an inspiring quote to read as an undergrad, and helped me recognize programming as my vocation.
I have a beautiful Docubyte print of the IBM-360 in my room, as a reminder of the great endowment that is our computing past. Well done to Brooks on a remarkable life’s work.
pjmorris
I read that section of MMM during a down time in my early career where I was doubting my choice of programming as a career because of my limitations. It buoyed my spirits enough that I decided to stick with it and I am glad I did. I owe a great personal debt to Brooks.
oblio
> Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.
Yeah, and then you have the core banking system tied with scotch tape and bubble gum in the 1950s, that drives a business worth tens of billions of dollars and for which a modern rewrite would probably cost a billion dollars.
And then you realize some pieces of software are harder than a mountain made of titanium.
zelphirkalt
"No silver bullet" in itself must be one of the most misused or misunderstood phrases used by people to argue not to try better ways of doing things. If one suggests, that there is a safer or somehow better tool to get the job done ... no silver bullet! Your tool is not perfect for everything in the universe, so we will not even use it where it works significantly better!
_0ffh
I suspect there is no bit of wisdom in the world, that is not misunderstood, distorted, and abused by lesser people.
WesolyKubeczek
The thought that there is no ultimate perfect way to do things is liberating, if anything. It means that we can pick something we deem good enough and roll with it, or we can try and find an infinity of other good enough ways with acceptable tradeoffs, instead of searching for that end all, be all holy grail. Or we can stop trying at some point, because of diminishing returns. It's all okay.
The important thing is not to worry that what we have is merely good, because the perfect might be waiting around the corner. It's not.
kaba0
Also, the most important part of that quote is that due to there not being “free lunch” productivity boosts, we really should focus on reusing existing libraries, “standing on the shoulder of giants”, not reinventing the wheel for each platform/language.
goto11
To summarize, "No silver bullet" claims no single innovation will increase software developer productivity tenfold across the board. He does not say an innovation can't increase productivity greatly in a specific area, neither does he deny that many improvement can accumulate to a tenfold increase.
rychco
When I attended his talk ~4(?) years ago on No Silver Bullet, the audience had the chance to ask questions about recent technologies like ML/DL, AI (though CoPilot didn't exist yet), modern safety features, etc. I wish I could remember his exact responses to those questions, but of course he still maintained that there is no silver bullet :)
kaba0
Also, he speculated it decades ago (though, arguably it still stands. There is no new managed language that would be 10x more productive than any already existing one)
P5fRxh5kUvp2th
It's also a warning against those proselytizing solutions.
Agingcoder
I came here to mention this quote.
I bought the book years ago when I was on my 'let' s learn everything I can about computers and software ' spree. Very few books have left such a lasting impression on me, even though at the time I had no notion whatsoever of what professional software engineering was like.
shever73
One of my favourites too. I use this with my students all the time to capture the magic of programming.
KrisJordan
"The teacher's job is to design learning experiences; not primarily to impart information." -Fred Brooks
A favorite, lesser known quote of Fred's from his technical communications course at UNC and a SIGCSE talk. Beyond a software engineer and researcher, he was an extraordinary educator. His design ethos carried through to pedagogy, as well, and has been an inspiration to me. Thanks, Fred.
Jare
During my short stint in academia, I once addressed our room full of students with something like "Our role here is not to teach you; it's to provide you with the best context in which you can learn." I have often wondered where that philosophy came from, and I an very happy to have an idea now.
dhruvmittal
During my first week at UNC Chapel Hill, I had an incredibly opportunity through the honors program where a handful of new students (including myself, an aspring CS student) got to hang out with Fred Brooks for an evening. I don't think I really knew who he was at the time, but I did recognize his name as the one on the CS Building.
When we talk about Fred Brooks now, we're usually talking about the things he's written (MMM, No Silver Bullet, etc.) or the impact he's had on computing (8 bit byte, founding the CS depts, etc.). He didn't talk about any of that with us freshmen. Other than a brief introduction, he didn't talk about any of that at all.
Instead, he talked to us about what he saw as the future. The most exciting thing going forward, as he saw it in August of 2011, was the development of the interface between biology and computing. One of the things that stuck with me was that he said he hoped students today looked at biology the way he looked at computer science back in the 50s and 60s, as a land of unlimited potential.
tkhattra
> he said he hoped students today looked at biology the way he looked at computer science back in the 50s and 60s
that's interesting, i believe ken thompson said something similar re: getting into biology in an interview about 20 years ago.
avg_dev
I know a lot of people like MMM - I too enjoyed it. “The bearing of a child takes nine months, no matter how many women are assigned.” Still totally valid, IMO.
But I really enjoyed The Design of Design as well.
R.I.P. Mr. Brooks. I thank you for introducing to me the idea of conceptual integrity.
thyrsus
Message from the Chair of the UNC Computer Science Department (personal phone number elided):
Dear Friends,
It is with great sadness that I must share the following update on the health of the Department Founder Dr. Frederick P. Brooks, Jr. I know how much Dr. Brooks has meant to the department, to computer graphics, to the world of computing, and to each of you. So I wanted to reach out and pass on the following message from his son, Roger Brooks.
Dr. Samarjit Chakraborty Chair, UNC Department of Computer Science
– Begin Forwarded Message – Subject: Frederick's condition and his Hope
Dear ones:
As you may have heard, on Saturday my father came home from the hospital into hospice care. He spends most of the time sleeping. When (slightly) awake, he is only slightly responsive, and not able to respond verbally to questions. He seems to be in no pain and no particular discomfort. He is eating and drinking small amounts, but far from enough.
Frederick P. Brooks Jr. has fought the good fight, run the good race, been an outstanding husband and father and mentor and friend of many . . . and is now fading away. His hope and his coming joy, in death and in life, is in his Lord Jesus Christ, who I know will welcome him with “Well done . . .”.
The hospice nurse tells us that my father may live several days to 10 days or so.
You may share this information with all who would want to know. I know that I am missing email addresses for beloved friends which exist somewhere in my parents’ contact lists, and I apologize that I do not have time to dig for those.
With family and aides around, we have ample help. If you would like to come and visit my mother, or bring your last respects and prayers to my father, please just call the house first. Close friends are welcome, but it is hard to predict in advance when things will be busy or peaceful.
Kori Robbins, associate pastor at Orange Methodist Church, visited yesterday and prayed what I thought was exactly the appropriate, loving, and merciful prayer, which she tells me she adapted from Douglas McKelvey's A Liturgy for the Final Hours. We ask you to join in this prayer:
O God our Father, O Christ our Brother, O Spirit our comforter,
Fred is ready.
Now meet him at this mortal threshold and deliver him to that eternal city; to your radiant splendor; to your table and the feast and the festival of friends; to the wonder and the welcome of his heart's true home.
He but waits for your word. Bid him rise and follow, and he will follow you gladly into that deeper glory,
O Spirit his True Shepherd, O Christ his True King, O God his True and Loving Father, receive him now, and forgive his sins, through the blood of his Savior Jesus Christ.
Roger Brooks Sr.
atdrummond
It is clear that beyond his accomplishments in the world of computing, he achieved what is most important - being a good friend and family member. The warmth and love in those recalling his life is evident and is a reflection of his profound impact on others.
Rest In Peace.
avg_dev
By no means am I a religious person, but that certainly is a beautiful prayer.
hcrisp
Another quote of his;
"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)
Stated a different way:
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." -Linus Torvalds
mekoka
While I agree with both quotes separately, I don't think that they necessarily mean the same thing.
To me, the first (by Brooks) seems to be about grasping the domain model to understand what the system does (or can do) in general.
Wheras the second (by Torvalds) seems to be about how best to organize data in code for efficient processing. Array, hash, tree, heap, etc and their associated access time complexity. The efficiency of your solution depends on your choice of a data structure that fits the local problem.
atdrummond
What if the table includes a poorly labeled column entitled “fiat@“?
gilbetron
Underrated comment that would have been perfect if you said "labled"
zelphirkalt
The Linus quote is ripe for misinterpretation. Not worrying about the code can lead to an unreadable mess, that ones future self or others will hate working with. So a really good programmer will probably rather go the Sussman way and realize, that programs are firstly meant to be read and only lastly meant to be run by a computer (paraphrasing here).
lloeki
> The Linus quote
I always attributed it to Rob Pike, but it turns out Pike's is following:
> Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
> Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
https://users.ece.utexas.edu/~adnan/pike.html
Interestingly enough, the above link has this to say:
> Rule 5 was previously stated by Fred Brooks in The Mythical Man-Month.
Which I guess references GP's excerpt.
Also says this, which kinda loops back to Linus's way of saying it:
> Rule 5 is often shortened to "write stupid code that uses smart objects".
citrin_ru
Designing good data structures is very important for code readability too. If you struggle to understand how given data structure is used / what it contains it would be hard to understand the rest of the code.
Cthulhu_
There's a lot of code out there that would improve massively with better data structures though.
I mean I've waded through tons of code where the original author abused strings to indicate relationships in a table - a column with semicolon-separated values referencing other tables / rows. And a ton of code to check references.
Mind you, that's more database design than data structures, but they're close enough for this example.
wodenokoto
In reality though the tables are going to be like: Column named “price_usd_incl_tax” is neither in usd nor does it include all taxes.
retSava
Don't worry, the code is self-documenting. /s
Self-documenting code (what I take in practice means "no comments"-culture) is something I don't understand how it can work, never seen a good implementation of it. It _can_ be successful in describing the _what_ but is poorly or not at all describing the _why_. Perhaps I'm in the wrong domain for that though.
jalapenos
In practice it really does mean self documenting code.
Like variables called "daysSinceDocumentLastUpdated" instead of "days". The why comes from reading a sequence of such well described symbols, laid out in a easy to follow way.
It doesn't do away with comments, but it reduces them to strange situations, which in turn provides refactoring targets.
Tbh, its major benefit is the fact that comments get stale or don't get updated, because they aren't held in line by test suites and compilers.
Most comments I come across in legacy code simply don't mean anything to me or any coworkers, and often cause more confusion. So they just get deleted anyway.
the-smug-one
The why should be clear from the domain that you're working within. A line of comment should count as something like 10 lines of code, if you're reading a comment then you're treading into real complexity. If you're in a code base where that isn't true, then is the comment really necessary?
Fairly hot take from me, life is more ambiguous than that :-).
lightbendover
Documentation without accurate and descriptive method/member names is much more harmful than the inverse. If an abstraction is sufficiently complex to warrant a lengthy description of why it exists, then it should have a design doc. In practice, most code within a repo is pretty simple in what it accomplishes and if it's confusing to a reader, then it is most likely because they don't understand the design of the larger component or system or simply because the implementation is poor. There are of course cases where comments are really useful or even necessary (e.g. if going against best practices for a good reason or introducing an optimization that is for all intents and purposes unreadable without explanation), but they are exceptions.
ilyt
I like that term. When I hear it I can with 100% accuracy know the person touting it is a hack and their code is garbage.
ethbr0
The dream of self-documenting code requires solving two problems, only one of which programmers are typically good at.
1) Communicating with computers
2) Communicating with other humans
Self-documenting code is essentially writing prose. Granted, to someone with similar knowledge as you.
But most people suck at writing.
cafard
I would remark here that The Mythical Man-Month did give a page or two to documentation. My copy seems to be out on loan, but as I recall the section included a figure showing the documentation for a sort function, perhaps 25 lines or so.
Kranar
At my company code is required to be self-documenting. My attitude is that if you can't determine the why then you likely are not familiar enough with the problem domain to be working with that code. It's fine not to be familiar with the domain and there are ways to address that, but reading source code is not one of them.
croes
I've seen lots of documentation that I only understood after I understood the code.
quickthrower2
It used to mean that, but a programmer changed the meaning. They could.
(a) rename the column, be the guy who broke the system and spend all weekend trying to fix 6 systems he never knew existed, written in Access, Excel, Crystal Reports, VB6, Delphi and a CMD file on a contractors laptop.
(b) keep the column name, deliver the feature, go home.
Ma8ee
I really hope you are joking 100%, because
(b) Go home and be happily oblivious that six other systems silently started to produce wrong results since the meaning of the column has changed. But, of course, that is someone else’s problem, some other day, when several months of reports and forecasts have to be recalled and updated.
deniska
We prefer option c: add a new table/column with similar looking name. Then few years later start wondering why there're two almost identical entities, and why one of them behaves weirder than another.
pif
There's no point in keeping the same name so that a system can keep running, if the data meaning has changed.
Bad programmers chose (b). Good programmers choose (a). Better programmers refuse the change request.
ilyt
If data meaning changed tho those 6 systems would break too, no ?
js8
That's why you should also have comments, and maintain them. Then if the name is hard to change, you can at least document the new semantics.
quickthrower2
To be clear I am pointing out incentives to make a worse choice, rather than the better choice.
javawizard
Which is exactly what Linus' quote is about.
bazoom42
In that case the code will probably also be difficult to read.
In my experience, studying the database schema and IO data structures is indeed the best way to begin understanding a complex system.
lucideer
This is only in the reality where nobody is shown the table.
Showing things acts as a forcing function to fix the thing being shown
lightbendover
I can just barely count the times I have seen a production failure due to someone assuming a millicent value from a column with ambiguous naming was in centicents or vice-versa.
mejutoco
At least you can grep that column name in the source code to find out where other taxes are calculated. Of course an ORM can further complicate this.
dt3ft
This hits home. Not only in databases, but also in code.
po84
I had the privilege of attending some of Dr. Brooks' lectures. His views on the role of a computer scientist have helped me find meaning and direction in my career. May he rest in peace.
In a word, the computer scientist is a toolsmith--no more, but no less. It is an honorable calling. If we perceive our role aright, we then see more clearly the proper criterion for success: a toolmaker succeeds as, and only as, the users of his tool succeed with his aid. However shining the blade, however jeweled the hilt, however perfect the heft, a sword is tested only by cutting. That swordsmith is successful whose clients die of old age.
monksy
I'm pretty sad about this.
When I was in high school and learning how to program, he let me borrow a copy of his Mythical Man Month book.
AnimalMuppet
Wait, what? You knew Fred Brooks when you were in high school? How?
nl
So many question!
Was he at the school somehow?
Was Mythical Man Month useful for a high school programmer?
monksy
Not so much, at that time I was making projects putting them out on the internet etc. I tried talking with other adults that were programmers about some of the issues I had and occasionally got advice.
But when I got to grad school.. their convervsations about "the industry" and ways of working was massively inexperienced. I also read a lot at that age. It also did give me a leg up in identifying high pressure of delieverying. (The 9 women in 1 month for a baby reference).
monero-xmr
Don't be sad - he lived a long productive life full of people he impacted, and as you can see from the comments here he was well respected. All of us will die one day, let's not feel sadness.
cortesoft
Nothing you said means you can't feel sad. No matter how long and full someone's life is, there is still sadness when they are gone. It doesn't have to be debilitating sadness, but it is ok to feel sad.
sirsinsalot
Let's not try and tell others what is OK and not OK to feel.
khazhoux
The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.
Get the top HN stories in your inbox every day.
I exchanged a few emails with Fred over the years. RIP Fred. Thank you so much for all the wisdom. Sharing one of the last responses here: