Beauty Aint My Business No Sir
Beauty Aint My Business No Sir"My conversation is not bound to please."
We hear a lot, at least I hear a lot, from certain groups and quarters about how BeautyIsOurBusiness.
This bothers me, and is beginning to bother me a lot. Several objections:
Crass, commercial objections:
Basically, this: when I was a commercial software developer, I was paid to produce things that solved a problem. There are obvious virtues that a piece of software can have for the day to day user: usability, speed, and functionality being the usual big three. IT departments worry a lot about compatibility with other programs, maintainability, and scalability. Ain't nobody paying for elegance or beauty, except indirectly.
Craftsmanship objections:
At some point, and Lord I hope it's soon, we need to grow up and actually figure out how to build stuff correctly. Patterns are an interesting approach, methodologies are an interesting approach, code metrics are an interesting approach, flat out old-fashioned mentoring might be the way to go. But where's the science in this? I want some case studies, I want cross-project evaluative studies, I want .... At some point we actually have to have numbers and comparisons and start testing the various claims. Are we doing this and I've just missed it? Or are we still busy crafting slogans? See also: SoftwareBlueprints. -- BobBockholt
Beauty is just plain ill-defined. And an awful lot of people like it that way. I was at a seminar recently where the teacher, the guy with expertise, said something like "Programming is a blend of art and engineering. And it's always going to be that way." Which is a true enough statement (though I don't quite comprehend the way in which "art" has been surgically excised from "engineering"). But the conclusion that he seemed to draw, that therefore we can't quantify anything and the best we can do is sit at the feet of the grey-beards and catch the flakes of wisdom that fall from their skulls, seems absurd.
The questions are simple: What makes a program good? How do we build good programs? The past 40 years have contained many interesting approaches to these questions. Which leads to: How do we decide which approach works best? And saying BeautyIsOurBusiness just doesn't do it for me. At least not today :-)
There's something about elegance that just shouts sufficiency, but it shouts quietly, and tastefully. Elegance is classy and effective. -- BenTremblay
Would you prefer to live in a house designed by a scientist, or by an architect? To have your nose fixed by a scientist, or a cosmetic surgeon? To toast your bread in a machine built by a scientist, or a design engineer? To write with a pen built by a scientist? Is there anything in your life you'd rather have had done by a scientist? If so, you must know some different scientists than I do. ;-> -- RonJeffries (formerly Computer Scientist, now JustaProgrammer)
Yes. All of the science. I find it telling that you're pointing out that non-science occupations aren't best filled by scientists. This is a straw man. For the same reasons I wouldn't retreat to a science for facial surgery, I wouldn't want my surgeon doing signal analysis. Or, for that matter, my plumbing.
-- JohnHaugeland?
I want my random number generators and my medicines to be designed by scientists, not sophists like rj.
I don't quite understand RonJeffries answer. It may be a fine piece of rhetoric, but what's the point?
Recently, the American Film Institute released its list of the top 100 films of all time. I disagreed with many of their selections. E.g. we had a situation of "their opinion, my opinion." And, if the AFI had come over for a beer, we could have gone round and round all day, discussing various aesthetic issues til the cows came home, heard us bickering, and decided to spend the night at a Motel-6.
And lots of discussions about programming, about design, about how to build things correctly, about methodologies, all have the same flavor. And the only way I know to eliminate that flavor is to form and test hypotheses. Generate some hard quantitative data and draw rigorous scientific conclusions.
Returning to RJ's rhetoric:
'''Would you prefer to live in a house designed by a scientist, or by an architect?
There are two parts to this. User-interface design and skeletal construction (yeah, yeah, I know. Not a clear distinction). And the curious part is, in computers, the UI people actually do testing. There are labs full of prototypes, there are people making measurements, there are hidden cameras and there are statistical analyses being performed. UI design goes way beyond TogOnInterface? and Tufte's work (though they are fine starting points). I'd claim that usability labs aren't working perfectly, but I'd also claim that the usability guys are trying to measure and quantify things. And that this is perfectly reasonable stuff, driven by attempts to please the consumer (as opposed to the focus of BeautyIsOurBusiness which is more about the joy of the coder).
Past that? I want my buildings to be designed by people who know what works and what doesn't. Who can compute stresses, who can figure out whether a heating system will be sufficient, who understand that really long pipes are bad plumbing, who has a thorough sense of the necessary give and take. A good architect has that, and more. But, first, she has to have that. And the only way this fundamental data gets firmly established is ... that's right ... science.
'''To have your nose fixed by a scientist, or a cosmetic surgeon?
Ahhh. With this, I begin to better understand your objection. You are making the distinction between practitioner and theorist. Surgeons are practitioners, scientists are theorists. And when one's nose is on the line, one goes for the experienced hand (the person who's been there before, rather than theoretical knowledge).
A fine point. But, perhaps, not quite applicable. After all, in professions where that distinction applies (as it does in surgery), practitioners are required to be versed in theory first.
And in professions where the distinction isn't quite so rock-solid (e.g. in ours. If I'm the practitioner, who is my theorist?), shouldn't we, as we develop our theories and methodologies, try to adopt the tools of our theoretical cousins? When we try to make the jump from practitioner (programmer) to theorist (UML advocate? ExtremeProgramming Guru?), we ought to have solid proof. Or, at the very least, reasons why we don't have solid proof. Where reasons are things more concrete than things like "Hey, I do art" or BeautyIsOurBusiness.
Have you read TheTimelessWayOfBuilding? Roughly, science is a stepping stone on the way to beauty, not vice versa. First you flounder around, then you develop rules and measurements, then you internalize the rules so that you don't need them any more. Methodologies, code metrics, even patterns, are scaffolding, crutches, to be thrown away. Eventually we will program from our guts, by instinct. The code will flow.
This is because rules are too inflexible. The map is not the territory. Metrics never capture what we really want in software. Reality is a special case, an exception to the rules.
I agree we're not really at the beauty stage yet. It's too early to throw away our crutches - we don't even have good crutches yet. But that's what we're aspiring to. (ChristopherAlexander says it so much better.)
-- DaveHarris
Where BeautyIsOurBusiness is right on is that as practitioners we need to develop our sense of beauty, our sense of rightness (and conversely our sense of wrongness) so that we can rapidly develop good software. Knowing a million beautiful patterns cold is one "scientific" thing we can do ... but that's only one. The real beauty (e.g. that of simplicity) comes from a deep sense of when you're doing too much (usually), and bringing yourself back to DoTheSimplestThingThatCouldPossiblyWork.
I believe that the really great programmers, and I've met a few and even been one on a couple of days, have a very refined sense of the beauty of what they do. At the same time, we've all gone down the rathole of looking for beauty when what we really needed was to get the thing done.
To build a program that will work in time, and keep working for long enough to become legacy ... we have to build in enough beauty, and enough science. Maybe that's what engineering really is? -- RonJeffries
The only problem I have with this page is with the characterizations. I work with biologists, chemists, mechanical engineers, and electrical engineers. My software attempts to keep all of them happy. If anything, I find that people with engineering backgrounds do not look for elegance (OnceAndOnlyOnce). Getting something working, regardless of code redundancy or inelegance seems to be their main criterion. The philosophy is "I'm here and I need to be there and I don't care what the code looks like." Making elegant code usually requires reflection and a feel for the aesthetics of simplicity. Scientists, in general, are driven to that. I get the feeling that if engineers where in charge of discovering subatomic particles they'd have said "so you have these twelve things and they are unrelated, so what? How do I make something out of them?" Scientists, on the other hand, say "there must be something simpler which explains those twelve things."
I'm not trying to knock engineers. Often they are under incredible pressure. Scientist types (people motivated by discovery), by their nature, are probably much more inclined to AnalysisParalysis. But the engineering types (people motivated by the urge to make and fix) need something like RefactorMercilessly to give them simplicity whether they want it or not.
Saying "there must be something simpler which explains those twelve things" is a type of refactoring. -- JoachimNoreiko?
That's the point, we're saying that scientist types don't need to think of that as a methodology, because that's what they're driven to do -- it's engineering types who don't care about beauty that need to be reminded to RefactorMercilessly. -- Han
Michael, you mentioned several professions where my understanding is, that it is not of their primary task to create software, but to solve a problem in their working domain (biology, mechanical engineering, etc.). It is just not the business of these people to cut beautiful code. They have to deliver results.
In general, I always have a problem to classify software developers as engineers. For me, the world looks like that there are
Also engineers can use the theories of their trade to synthesize a work product ("construct it on paper"), which, through a predefined standardized process, can be build and will - with a high probability - work as designed. All this in a controlled way, including cost and quality control. They sometimes fail, but not very often. I haven't seen that happen for software development, it is still try-and-error, with a high probability of failure. (How many SW development projects fail?)
I always shiver a little bit when I hear the term "software engineering". For me there is no such thing. Since the '70 people try to establish such a discipline, but there is just no working system theory. No working system theory -> no engineering. Period.
-- ThomasWeidenfeller (who has an engineering degree, worked in research, is called a "senior software designer" by his current employer company, and calls himself a SoftwareCrafter", see also JustaProgrammer)
I disagree. Mechanical and civil engineers have to debug their designs, too, and being able to debug a simulation without actually building their design doesn't change that there is still much trial-and-error, and a "principle proof" counts for almost nothing. There is merely a superficial difference that software engineers don't "simulate" their designs, they just go ahead and build their designs to debug.
At least in the mechanical and electrical engineering projects I've worked on (which, granted, are quite limited), you start out with an initial idea that works in principle, and you try it, and it doesn't work, and you debug it until it does. Which is the same process by which I develop software.
Another superficial differences might be that there's "less" debugging, but I'd argue this is because the problem space is more constrained by "real-world" limitations, whereas in software the only thing standing between you and your goal is your own mistakes. In other words, projects that take the same amount of work might involve more (than in software) calculations that you have a "principle proof" for and don't really need to be debugged (although that's really because scientists debugged them for you), and so less work is spent on debugging, but I see that part as science -- the engineering part is the trial-and-error, debugging-the-design phase.
I think what I'm trying to say is: proving that an idea works is science, getting an idea to actually work is engineering. And developing software is all about getting it to work.
-- Han
Thomas, can you give an example of these proofs. Maybe in circuits as an example? Are you also saying that engineers do not typically breadboard their designs or run simulations and that correctness is typically determined by schematics alone?
I did not say that there is no model building and testing involved. I said that these disciplines have a working system theory (e.g. the laws of physics) they can build on top. And regarding simulations: These disciplines can simulate because they have this working system theory, and that's why the results of the simulation are so extremely close to reality and usable as a substitute for reality (e.g. in mechanical engineering). They simulate to save the effort to build a real model etc. These simulations are proofs of correctness.
Please also note that I said "in principle" when talking about proofs of correctness. I am fully aware of the fact that in practice it is sometimes just too complex and too time consuming to do that. On a small scale engineering schools teach these proofs to their students. E.g. EE students spend days and nights to manually calculate an impulse response of a given circuit. And voilà, when the circuit is actually build, it shows the calculated behaviour (with "engineering precision" - yet another thing SW developers still can not do: to quantify what GoodEnoughSoftware is). Being able to calculate such a response also means to be able to prove that the given circuit delivers/or does not deliver such a specific response.
An aside, regarding the engineers writing code. True, some do, but I see the same from point A to point B problem-solving approach when they are in their element.
Yes, and why not? Maybe these people are not paid to save the world, but just to go from point A to B. And that's what they do.
Because of discussions like these, just for fun, a couple of years ago, I started interviewing civil engineers whenever I met them, in the airports, buses, etc. I interviewed some of them about the arch in St. Louis, and just got done interviewing some about off-shore oil rigs. Basically, they build ball and stick models, or just stick models, and then test the bejeebers out of them. (They told me that the arch will fall down in a 45 mph wind from due north... that was one simulation that was only done after the thing was built.) In other words, they have no method that works, either. They just guess and test. I keep trying to find evidence to the contrary, but the oil rig builders told me the same thing. -- AlistairCockburn
When the BrooklynBridge? was built, a large percentage of bridges would fall within ten years of construction. So Roebling made his bridge TEN TIMES as strong as he calculated it needed to be, and, of course, it is still there, and not even sold. (But a pedestrian was killed a few years ago when a support cable snapped.) So, if you don't know what you are doing, overdesign.
OverDesign sounds good, but I still haven't figured what it means in software. Can you give me some idea? Thanks. -- Alistair
Yeah, it is hard for me to imagine any other way. I suppose that in things that have been done before, there is math that can tell you what to expect of various materials and configurations, etc.,. In EE, it would seem that you are dealing with more logical complexity, so more prototyping and testing would be needed to verify assumptions that are too tedious to verify by hand. At least that is what I see EEs do. Programmers just have the benefit of seeing being able to realize and test their designs immediately. After all, TheSourceCodeIsTheDesign. -- MichaelFeathers
I take it that the answer to my original question "At some point we actually have to have numbers and comparisons and start testing the various claims. Are we doing this and I've just missed it?" is "Nope, we aren't and many of us don't see the value in doing so."
I feel like this page is an example of the InterviewingTheBhagwan pattern.
Why? Where's the contradiction? -- RonJeffries
The point of InterviewingTheBhagwan isn't contradiction - it's about failure of communication.
CodeSmells is an application of aesthetics to development. I use the smells as a guide for future development- if I have ParallelInheritanceHierarchies AND I'm cruising around their code anyway, then I'll see if I can unify the hierarchies while I'm at it. The smells give me directions for development that are likely to pay off. This is kind of like searching for a lost set of keys by cleaning your desk. It is generally the quickest way to find them, and even if you don't find them, at least your desk is clean when you are done. -- KentBeck
See also SiteRepair?.
What is considered beautiful changes with experience and familiarity. It seems dangerous to use that as a measure of software quality or as a goal. Easy of maintainability may be a better yardstick (although this requires experience). Or our definition of beauty needs to be restricted. -- WayneCarson
Folks are talking here as if science and engineering are somehow more mechanistic and "crank it out", and we are uneducated savages bouncing on our heels and touching the magic obelisk.
Neither science nor engineering is mechanistic. The formation of hypotheses in science, and the devising of experiments to test those hypotheses - that's the essence of science, and skill at that is just as intangible as anything programmers do.
The core of engineering is design, not computing whether the bridge will stay up ... and even computing whether the bridge will stay up is still full of art.
(ad hominem comment deleted)
A good programmer senses what his evolving solution is telling him. The solution pushes back where it isn't as right as it might be. He forms hypotheses about what might be better, tests them, refines his hypotheses, moves on.
It's the same stuff as science and engineering. At the core, human creativity is the essential force. The trick is to harness it into rapid productivity. -- RonJeffries
This is not to say that software development is pure art, but it is according to my understanding definitely not engineering. The heart of an engineering discipline is a working system theory. A mechanical engineer can - in principle - prove that this machine will work, a civil engineer can - in principle - prove that his constructions will not crash, an electrical engineer can - in principle - prove that his circuits will work. Can a "software engineer" provide such a principle proof for a program? No!
I wonder if that's true. If it were, couldn't the Formula One engineers and designers all design the same optimized cars? The chief designer on a Formula One team still seems to do something magic, and they certainly are engineers.
You may not be able to prove that a program will work properly, but you cannot do that in engineering either. The best you can say is that, 'given everything we know, we are 99.99999% certain it won't fall down'. As knowledge and experience has progressed engineers have been able to 'overengineer' less and less. There has been 'lab science' involved but there has been a hell of a lot of watching things sink/crash/fall down as well. Look at modern aircraft. They are about as scientific as it gets but they don't just carry out a validation of the theoretical correctness of the design and pump out 400 of them do they? -- TomAyerst
Back to the provability, or not, of software...
Yes! At least that's what I thought all that stuff about loop invariants was. ;)
Seriously, one of the best ways I've learnt to lower defects in my code is to sit there and prove to myself whether a given construct was correct or not. This is especially important with MultithreadedSpaghetti?.
And there is a working system theory of software: mathematics. That beats physics hands down for proving correctness.
Programming is a very strange field. It's caught between engineering and mathematics (and only sprinkles of actual science), which is why it's really difficult to get a handle on BeautyAintMyBusinessNoSir vs. BeautyIsOurBusiness, because both are partially correct.
Provability has turned out to be a dead end in the goal of WritingCorrectPrograms? (see HaltingProblem).
P.S. Yes, this smells badly of ZenAndTheArtOfMotorcycleMaintenance.
P.P.S. If you think like ZenAndTheArtOfMotorcycleMaintenance, smelling badly isn't likely. Strongly, maybe. ZATAOMM is the truth.
In my opinion, there are ThreeTypesOfScienceAndEngineering.
Code is developed and maintained by humans. And beauty does matter to us. We might think that different things are beautiful, but we still seek beauty in everything we do. We are made like that, and I like it.
The scientific point would be that the worker who likes what he does is more productive. I guess you can test it.
I think people get the mechanistic reproductive elements of the physical engineering disciplines mixed up with the design element. I don't know if anyone here has sat in on an engineering design session, but I have. Let me tell you, it's every bit as hectic and uncertain as programming is, if not more so.
Cars are assembled in factories and shipped to dealer lots, but this isn't how cars are designed. CPUs, like the Pentium, are manufactured en masse every day. However, Intel has several layers of design departments that range from the totally what if to the how do we take this cool stuff those nerds gave us and make a product out of it?.
My father-in-law is a mechanical engineer. I've watched him mess around and try so many different combinations of metals, glues, woods, nuts, bolts, plastics, paints - you name it. When he's working on a design, it's a mess - until it's done.
We think we're the only ones that feel unsure, but this simply isn't true. The nature of creating something simply is uncertainty itself. -- JeffPanici
There's nothing as lonely as a point which has been missed.
PersonX and PersonY may discuss(debate) at length about which "objective" properties of a program might contribute to "beauty" -- just as sophomores sometimes argue(d) 'til all hours about Hamlet, or Tommy, or whether Paul was dead. However, they won't be likely to have such dialogue unless
-- JoelNeely
People here seem to be arguing different definitions of beauty. Some are arguing elegance, others aesthetics, still others the deeper sense that things are correct. I tend to value beauty, whose definition I take as my final example, but for its own sake. Whether or not you have the sense that you've Done It Right (tm) is unimportant. There should be harder criteria, regarding input and output constraints, the successful answering of test suites and criteria, time guidelines, response to insane input, et cetera. I tend to take the Fuller quote in rather less absolute terms than those in which I feel it was presented; whereas I too don't feel comfortable if there's still a smell, I set very real rules, and when it comes down to it, I don't trust my nose all that much. I follow it when I'm dealing with multiple stinks, and trying to figure out which way to turn first. I follow it when I'm trying to figure out what to test first. But I don't trust it to know when something is clean; it's nothing better than a rule of thumb.
Beauty is my business inasmuch as it is that of Craftsman. Their tools aren't bright garish colors, nor hideous tartans and dithers; they have relatively comfortable handles, and conveniences like swappable battery packs. In a shallow way, beauty is their business; their tools have to be usable, they can't be uncomfortable, they can't be annoying, loud, a pain in the rear to use. But the engineer at Craftsman has a higher priority: the job has to get done, it has to be safe, it has to be reliable. In some ways, yes, beauty is the job of the engineer at Craftsman: they have inventive guides, reliable fast-switch bits, hand guards, cord guards, reversible gearing. They have to be utilitarian, reliable. But their priority above all else is to do their job. I am not an artist. I am an engineer. Engineers may weave beauty into their work; perhaps that is the hallmark of a craftsman. But it's not the job at hand, IMO.
-- JohnHaugeland?
EditText of this page
(last edited November 13, 2014)
or FindPage with title or text search