Slashdot Mirror
Explaining Complexity in Software Development?
BMazurek asks: "I'm stumped by how to explain software development complexity (not theoretical big-O notation, that's easy) to non-developers. When it comes to people who aren't in the code, my explanations fall flat. It's not that the people I'm talking to are stupid, they're quite honestly people at the top of their respective (non-tech) fields. How do -you- explain software development complexity to non-developers? What analogies do you use?"
"I often try the famous Fred Brooks, Jr. quote (seldom to much success):
'Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into a subroutine--open or closed. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.'
Spanning 20+ years in computer programming I've stopped trying to explain what it is like and how it is done. Heck, we can't even clearly explain to peer programmers why vi is better than emacs, XP is better than Linux, Gimp is better than Photoshop (NOTE: these do not necessarily reflect my opinion, FTR, I prefer: vim; Linux; and Photoshop)
I shrug my shoulders and explain it's mostly dull. It's kind of like doing Math homework, except I have to do it every day for my job. It's always about solving and debugging, and people's eyes glaze when I begin poking programming nuance with a ten-foot pole.
Fortunately I find most people don't really care. (Also for those who would "get it", my experience has been they are ones who dabble and experiment in it anyway already.)
(Aside: as for the original poster, congratulations on being able to explain "big O notation". I sometimes suspect my girlfriend of faking it.)
Easiest way I've found- though it's begining to get a bit outdated thanks to bloatware. Charles Dicken's famous novel is about 100k. This makes it easy to estimate source code in terms of number of copies of that novel. The quarter-million lines of code project I'm currently working on takes about 25 MB to store- 25000k, or 250 copies of A Christmas Carol.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
Tell them to imagine something constructed from LOC pieces of Lego.
:) )...
More usefully, try explaining why code is complex. Focus on the idea that you have an insane number of moving parts (effectively), but modifying is nearly free, which is why it works at all. Also mention things like spending most of your time writing error handling (well, I do, anyway
pictures help, metaphores help, madlibs help
by madlibs, i mean things like "think of [concept] as like a [cute noun (bunnies, kittens, etc.)]"... draw funny pictures, and connect them up with arrows... you can't over simplify enough, and the more fun you make it, the easier time the audience will have following you
remember that 9 times out of 10 you aren't explaining it to these people because they need to understand, you're explaining it so they have confidence that you know what you're doing and that the outcome will reflect well on themselves
I often try the famous Fred Brooks, Jr. quote (seldom to much success):
'Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into a subroutine--open or closed. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.'
See, that's the problem, and it's the programmers that caused it. Stop making subroutines. Monolithic code be da shizzle on da bizzle.
For the generic question, "What is programming?"...
:P
I say along the lines: "Think of programming like any job, where you have employees and you need them to do things for you to make your business work. You usually give your employees a list of instructions, things to do. They do what you tell them to and then come back to you for more instructions. Computer programming is similar, inside that box under your desk are a bunch of employees. Without a boss, they don't know what to do. So, what I do, is I tell each component inside there what to do. I tell the video card to turn on so you see stuff on your monitor as one example. I tell the main processing unit (think of it as the manager of the office, where as I am the big-cheese boss)) to run the "office" while I am away. I give the main manager, or CPU a big huge list of instructions that say this is how we run the place. The CPU (or manager) then follows my instruction sheet and tells all the other components inside the computer how to act, behave and what to do. We do it this way because it take months to write the instruction sheet out for the CPU, but the CPU can execute that instruction list super fast, much faster than if I were telling each component (e.g. employee) what to do directly...".
I actually just came up with this example right now on the fly... I never use the same example, I always think about what that person does for a living, spare time, hobbey, and I can almost always draw parallels that make them say "Ahhh, I wish someone else would of explained it that way before".
I've even explained how interrupt handlers work in regards to a USB joystick to a Lawyer... He was so happy in the way I explained it to him, he kept asking more and more questions until I told him I have to go
Modesty is one of life's greatest attributes
What you want to convey, to the non software initiated, is why software is difficult, why it is complex, and why it is hard.
I would put it this way; software is really "soft", being only instructions a computer reads and interprets. A physical analogy is perhaps clay, something equally analogously soft, malleable, and easy to work with. Now imagine another physical analogy; take that clay, and then try to build a car out of it. A working car. Ignore the physical impossibilities, like combusion temperatures, but make the point that each component first has to be designed then baked, and that each component has to be integrated with each other component.
So that is what software is like. They may ask, "Why?", and here are a few reasons:
1) Software is easily copied, not easily designed. The hard part is making the first copy, as in the car example. Once you get one product finished, you can copy quite easily, but actually designing and building is not necessarily easy.
2) Software is REALLY malleable. You can continuously change the design as you are working, not unlike building an entire car out of soft clay.
3) Because software is so malleable, each time you discover a new problem you discover a new solution. In other words, the second car you make will be totally different than the first car because instead you will be going from a car to a boat or a train or a helicopter.
4) Also because software is malleable, every "customer" with different requirements brings in new design directions. Imagine if every person working on the car, viewing the car, and interacting the car wants a totally different car? You aren't designing one car, now, you are designing 17 or 18 cars; trucks, vans, compacts, sedans, and sports cars. Now take all these vehicles and merge them into a single multipurpose vehicle.
GPL Deconstructed
say a sentence constructed full of acrynoms that describes are you build your system
it is me
As with explaining the complexity of anything, you have to try thinking either in terms that are completely universal, or in terms that the person you're explaining it to will understand from their field (assuming you know enough about their field to make an analogy, of course).
I usually end up rambling on until the listener's eyes glaze over, but I've had some success with demonstrating some relatively simple things with a deck of cards... sort and random algorithms are especially well suited to this type of explanation, for obvious reasons.
Anything that doesn't have an easy analogy in common knowledge, I don't generally worry about explaining beyond some noncommital answer involving a basic description of the task, then asking the listener to think about breaking it down into simple parts, with directions that a six-year old could follow. Generally works, and gives an idea for the complexity of a program, at least sufficient to give somebody who doesn't really need to know everything about the programming side an idea of the work involved.
Imagine having a huge legal contract. Then, add in a huge, convoluted yet intertwined legal system.
Furthermore, imagine that instead of writing this legal mumbo-jumbo in english, you use a language that is extremely strict and math-based.
This would be a fraction of the real complexity (mutiple threads/processes anyone? How about poor documentation?) but it starts the ground work.
To be honest, this way of thinking sounded better when I first started, and I'm kind of disapointed with my end product.
Am I open minded towards open source, or closed minded towards closed source?
LOC != complexity.
When it comes to people who aren't in the code, my explanations fall flat.
Before I changed line of work (I'm not a computer professional anymore thank goodness), I used to explain my work like this:
See, what I do is programming. Programming is like writing a cooking recipe, only slightly more complex but not much more. But it's a very large recipe, and it relies upon many more recipes to make an actual dish (the program). Many cooks write recipes in different languages separately, and all we cooks have to coordinate to prepare the final dish. So we need chief cooks (managers) that call meetings and prepare Gantt charts to do that. Then sometimes a cook writes a recipe that has the wrong combination of ingredients, or that make no sense to describe how to prepare food (bugs), so we need tasters (QA) to tell us busy cooks if the overall result will be pleasing to the restaurant's customers. In the end, you get a huge dish that has some nasty morsels in it, as well as tasty ones. We then have to refine the dish so the nastyness goes away and more goodness goes in (new versions). etc etc...
The cooking recipe analogy has always worked great to explain what I did.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
If you're looking for the perfect 4-course meal at a fancy restaurant, you need to match flavors, textures, and colors from a lengthy menu, weigh the transitions from appetizer to main course(s) to desert, and fit in the perfect glass of wine and the ideally sized, shaped, and sweetened dessert.
Only it's a 100-course meal, the menu is 1000 items long, there's a cellar full of wines (most of them are unpronounceable) and it takes months to find a sequence that people will even TRY to eat all the way through.
And even then, they probably won't be satisfied enough to tip you very well, so you keep making slight tweaks to the courses until someone finally gives you the tip you want. At that point it's good enough, but everyone knows it's never perfect. (And they call you on it, too.)
As soon as someone notices that you're making a decent tip, the owner invariably decides they're going to serve Chinese food instead, so you start over.
Not only that, but 250 copies of A Christmas Carol where if you get a word wrong, the whole novel may crash and burn.
Or you could compare it to a DVD of "Dumb and Dumber", which at 4.7G is 188 times bigger than your 25M quarter-million line code project.
In short, bulk? Don't go there.
True- but novels= complexity in people's minds, and they're always measured in numbers of words. Note- I only put forth my quarter-million lines of code project as an example- the real comparison is space taken up by the source code of both the novel and the project. 25 MB is 250x 100kbytes....
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
You time will be better spent teaching them the basics of programming that will give them something concrete upon which to build abstractions.
I suggest using an elementary teaching aid such as the Cardiac Cardboard Computer. You can still buy them or you can download pdf's and make your own. I don't know about the legality of the downloads.
We don't see the world as it is, we see it as we are.
-- Anais Nin
Not only that, but misspellings and grammar mistakes are the least of your worries. More important is that everybody reading it interprets the meaning of the sentence/chapter/paragraph in exactly the same way you do.
If that were the case imagine how many English degrees there wouldn't be.
Easiest way I've found- though it's begining to get a bit outdated thanks to bloatware. Charles Dicken's famous novel is about 100k.
You're way behind my friend: data bloat has grown so much these days it isn't measured in Charles Dickens units anymore, it's measured in tax code units:
- 1 tax code = 25MB
- 1 tax code table of content = 300KB (to measure smaller data units)
And no, I'm not kidding, the complete internal revenue code really is that big.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Actually... it's pretty close, but not for the same reason.
Roughly speaking, adding more lines of code (or compressing what should be multiple lines into one) adds more complexity to the application (when you look at debugging, maintaining, and improving it). It is not a measure of value, but can demonstrate how complex an application has become.
Make a rough analogy. Every line of code is a part of a machine. It interconnects to other parts.
-A mouse trap has maybe 4 or 5 parts.
-A transistor radio has perhaps 100 parts.
-A 35 MM camera has maybe 200 parts.
-What does a car have? 10,000 - 50,000 parts?
-An airplane? 200,000 parts?
-A smallish computer program has between 10,000 and 50,000 lines of code.
-Something like an OS kernel might be between a million and 50,000,000 lines of code
-A typical commercial billing application might have 300,000 lines of code.
-A nice set of apps to run telephony switches might have 10,000,000 lines of code.
-Even your stupidest sort of hackish utility has 100 lines of shell script.
Programs are gigantic machines - you just can't see them or weigh them.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
I tell them it's like chopping up your bowl of spaghetti and trying to build a model ship.
In Soviet America the banks rob you!
The difficulty arises when a programmer tries to teach someone that isn't even computer savvy programming in two minutes or less. It'll never work! Instead of trying to teach programming, simply explain the level of difficulty.
They usually have an intimate understanding of their field of expertise. Pick a complex process from that field and ask them to detail it mathematically. Or better yet, ask them to detail it using nothing but ones and zeros.
They'll think it's a joke at first but, assuring them that you're serious and that it is that complex, they'll start to understand. They'll also probably not need the lesson in programming to understand that it's complex.
Otherwise, you could just piss them off by using the standard line; 'It's technical. Someone like you really wouldn't understand.' Then stand back and watch their blood boil.
I disagree. What's more complex? A 100 line verbose function or one that does the same thing using recursion but is only 10 lines. A trash novel or a haiku?
"Software entities are more complex for their size than perhaps any other human construct because no two parts are alike"
I don't believe this. I think developers think that's true because they haven't been exposed to other large constructs.
I tend to think it's complex because we haven't figured out a really good way to do software engineering yet. Just like every car was handmade and fragile when horseless carriages were first concieved of, software today is handmade and fragile. Someone, somewhere will eventually figure out how to grow it or make it on assembly line or whatever.
there is no need to sign your posts. this isn't usenet. your username is right there above your post. stop it.
I think I'll use that at our next team meeting when the project manager asks why something breaks every time we fix something else.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
Think about how complicated a car is.
Think about how difficult it must be to design something that complex.
Computer programming is thousands of times more complicated than that.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
First off, friends would say that they had four essays, with exact word lengths for all of them. In the course of talking about what we all had to do I got asked how many pages my final project was supposed to be. Naturally I said that I didn't have a set page length, as long as it worked and was written efficiently and with good form.
Programming can't be correlated to word counts. Talented programmers can do stuff with less code. Bad programmers can do stuff with much, much more code. Clever programmers can do the same stuff with tiny amounts of code, but $DEITY help the poor guy who has to maintain it.
If you're just trying to get across a general idea of how complex code is, I'm somewhat fond of the 'full course meal' analogy. It's like cooking anything from a snack to a twelve course meal for a large number of people. Even though each dish is independent (if you do it right, I'd hate to see a dinner without good division between the dishes), each of them affects the meal as a whole as well.
Software development is hard because at its core it's as much about design and invention as it is about implementation. Implementation, in the general sense of the word, is often fairly easy. You have a plan, possibly a well known and understood plan, you can track progress, things are more predictable. With design and invention, you are often in unexplored territory so it's hard to tell where your next steps should take you and it's hard to track the progress you've made to date. What makes software development even harder, is often that the customers don't actually know what they want nor can they really be expected to know what they want. Problems are often not well understood.
One analogy that I've always liked is to look at software development as a mapping problem. When you start, you're pretty much dropped in the middle of nowhere without much understanding of the surrounding terrain. You then have to go exploring the area around, get an understanding of the feature space. Maybe the best approach is to climb a mountain or a hill, implement or design a major well understood component, and see what you can see about the area around you from that peak. You make little scribbles and notes on your makeshift map outlining what you've seen from the top of your mountain. Later, you climb a different mountain and all of a suddent everything looks completely different from the new perspective and you realize large parts of your old scribbled map are wrong. Maybe walking in between mountains one day you discover a large impassable ravine that was masked from above by foliage. Your in unexplored territory and there can be lots of surprises and setbacks.
Only, I think this kind of mapping analogy really falls short because it only takes into account a single perspective, that of the developer, and it assumes there is some well defined terrain that just needs to be discovered. In reality, the terrain being explored is much more mercurial. Much of it is visible only through the inconsistant and confused descriptions of customers or other developers. It's quite possible that the mountain you climbed yesterday, and the things you saw from the top, will not exist tomorrow.
Anyways, that's the best I've got at the moment. It probably doesn't make much sense, but then, what does?
I like your cooking analogy, but there's one thing missing:
One thing I can't stress enough to people is that programming is all DESIGN/ARCHITECTURE. The "do" part is essentially instantaneous. You figure out how to do something and write it down, in every minute detail (in code) and it's basically done. Then you compile it (or not even for some things). This process is nearly instantaneous (perhaps minutes but never days for almost any project, and never something you need to do yourself...)
To expand your cooking analogy, it would be like you work really hard on these recipies, but whenever you want you can "zap" create a new set of dishes. (Except that then you have to taste them all again to make sure your changes are ok..)
This is fundamentally different from the construction of anything else ever in my opinion. Code is akin to a recipe or blueprint. The "compile" part of programming, which takes zero work on the part of the programmer, replaces what is one of the longest and most costly parts of developing anything else.
Furthermore, it replaces the only part that you can reliably predict the duration of - making it very, very difficult to predict how long it will take to develop a piece of software.
I think it's important to realize that this makes software much faster to develop - if less predictable - but therefore we develop much more complex things in software. So to borrow from another analogy I saw here - because we don't have to physically build them, the expectation when building a car is that it'll have every feature of any car, boat, bicycle or plane that ever existed.
(The other important ramification is that it never saves developer time to remove an existing feature - and in an agile development process it may take more time to DECIDE whether a feature is important than it would have to simply implement it.
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
A lot more people know something about cars than about software. There is an old rule of thumb that a line of code adds about as much complexity [design complexity, implementation complexity, maintenance complexity] as adding one moving part to a mechanical system...and cars are the one mechanical system most people have experience. [just pray they don't ask about the computer chip in todays cars...which in general, has saved detroit from a horrendous complexity of mechanical feedback systems that would otherwise accomplish pollution control] Cars also have subsystems, eg electrical, transmission is a complex gizmo in its own right etc. so composition of systems from subsystems...one of the essential aspects of modern software, has a good analogy in the automobile. And besides...nobody likes to sound stupid: they might be ok with saying your explaination of software is confusing but they won't admit the car analogy is over their heads...just talk, they'll nod and shut up and leave you alone pretty soon so you can go back to coding.
SLASHDOT: news for people who can't concentrate on work or have no life at all and got tired of yelling back at the TV.
if someone building a house does something the same way more than once, it's a good idea. they use what they know works, and apply it over and over again. maybe some variations on a theme, maybe add another story here or a differently angled roof there.
but software is different. if you're doing something the same way more than once, it's generally a warning sign that you could be doing it better somehow. following that to its logical conclusion, a good programmer will never do the exact same thing twice. meaning that, as a good programmer, you're always doing something you've never done before.
that is why programming is hard.
it's like being an automobile manufacturing plant that never produces the same car twice. one day it's a civic hybrid, the next day it's an M1A1 tank, and the day after that you need two vespas, one that runs on gas and one that runs on fryer oil.
I tell people to imaging drawing a simple window on the screen
with text. Now your job is to make any one line of text
slide right when you hold down any one key. simple, right?
Ok, here's a sheet of paper that has text on it.
And here is a Royal mechanical typewriter.
Modify the typewriter to slide the text right when i hold down
the L key.
Oh, and I need it working by tomorrow.
In other words, the better the kitchen, the more reliable the dishes will be, and the faster the cooks will be.
Because it interfaces the most complex product of evolution(people) with the most complex creations of those people(computers and software). Computers are utterly rigid in what they do, and humans are nearly infinitely variable. Dealing with the differences, with a comparitivly small amount of experience, is hard.
Some software is pretty simple, because it solves simple problems. Is it any wonder that it often takes a complicated system to solve a complex problem?
Nerd rage is the funniest rage.
I've had some success illustrating the challenges of programming to the more visual or artistic types with this. Then you tell them to multiply that by tens of thousands, at least.
In general, more lines(useful, functional lines) = more complex, simply because there will be more than what we can hold in our conscious memory at one time. Extremely slimmed-down, tweaked, and optimized code can become nasty, too, but it will usually take more developer time to make the code that small than to do it in a naive, straightforward way, get it "good enough to use," and then move on.
One of the reasons higher-level languages are always touted as being better for rapid, maintainable development is because they can use fewer LOC in almost every area, from the heading boilerplate to the number of expressions used in each algorithm.
So yes, I would say that LOC are a good way to go about explaining it to the layman. The per-line complexity is merely a technicality if you're talking about any sort of sizable project, because it will almost always average out to some medium-low level of complexity, even if some bits are very clever. (though as the project gets bigger the average complexity is likely to creep upwards as features start conflicting with each other)
Ask them if they've ever seen a foreign movie with really bad subtitles. Ask them why something that seems so easy is so badly done. Ask them if they've ever had to explain something to a child who's only response is "Why?".
Everything that goes wrong with software is a result of miscommunication. From failed projects, to difficult algorithms, to null pointers. Programming is taking difficult to communicate ideas and concepts of human creation and translating them into the most literal and OCD afflicted of entities -- a computer.
You can talk about system size, deadlines, complexity, etc., but it all really boils down to communication. UML, JavaDoc, unit tests, forms, screens, blah blah blah. "Exactly what I asked for and not what I wanted."
Communication is difficult enough between two intelligent adults sharing the same goals. Now imagine trying to explain something to a machine.
emacs would make a *great* operating system, if only it came with a decent text editor.
(I'm sure you've all heard that one before)
Think of every if statement and loop as a moving part. Using the analogy, a computer program is like a machine with thousands of moving parts.
No, I will not work for your startup
How do -you- explain software development complexity to non-developers? What analogies do you use?
There's a T-shirt that sums it up nicely: I See Dumb People
"The main processing unit in a computer has Millions of transistors, which are like little switches, turning on and off. These switches flip automatically Billions of times a second. Every second Quadrillions of switches flip, and if a single one goes wrong the computer 'crashes'. That's not even counting the Memory, or the Graphics card, or all the extra devices from Hard Drives to Tempurature sensors that are hooked in. All of these switches are controlled by programs that were written by the combined efforts of thousands of people, most of whom have never met each other. I'm continually amazed every second that a modern computer keeps running."
I can think of a few legitimate reasons and many less honest goals. The world is awash with non-free propaganda, which is designed to make the user feel helpless. "Here there be dragons, trust us and stay out," they tell us at every turn right before blowing their horn about how many million lines of code they have bought and hacked together. Raise my spirits with a story of educational and respectful conversation. I'd love to hear about it.
Friends don't help friends install M$ junk.
Given the dying state of society, I find anyone suspect when they claim to have a boyfriend or girlfriend. If people against homosexuality spent as much time helping people get together as they did harping against homosexuality, I wonder if there wouldn't be as much homosexuality because it seems some of it is due to lack of options.
Ok, it's complex enough. But, the examples I'm seeing in these comments, while they will impress people, are just a bit extreme.
For instance, the analogies around building a car. No, software is all about design. When building a car, you have to deal with real, physical possibilities and impossibilities. In software, if your design is good, the components are flawless.
Also, abstraction helps. A lot. The example of 25 megs of source vs a 100k Charles Dickins novel isn't relevant unless I actually have to work on all 25 megs -- that, and english can often be much more compact. I often make a point of showing people Bash one-liners as an example of good abstraction -- probably millions of lines of code went into what I just did, but I only needed one line of code to make all that other code work together.
When it comes to explaining program complexity, it really depends what misconception the person has. The most common one is that computers are capable of some form of human-like thought -- the form varying from person to person. However, it's usually easier to convince people that something isn't possible than that something is possible, because people are used to thinking of computers as huge, complex, rigid, and buggy.
Honestly, though, the best way to teach someone why programming is hard is to teach them to program. Second-best way is to teach them philosophy. Third-best is to teach them Calculus.
Don't thank God, thank a doctor!
Imagine a very complicated machine, like the Boeing 777 airplane, which took years to design and build, and has millions (? actually not sure) of parts.
Imagine that each of those parts can directly affect 2-3 other parts.. the ones that it is connected to physically or electrically, etc. That gives you a huge set of possibilities for parts to fit wrong, or wear out in unexpected ways, or otherwise fail.
That's a pretty complex system, right? In fact, it's almost amazing that human minds can conceive, let alone build and deploy, such a complex system.
Now.. imagine that you've got millions of parts, and each part can potentially interact with EVERY OTHER PART. Also, imagine, because it's such a young field, there really isn't much common vocabulary or theory, and incompetent practitioners pretty much have the same power as seasoned veterans (perhaps more so in some cases). So things are designed and built in an ad-hoc manner rather than with careful engineering discipline.
That's what programming is like. So don't complain when Windows crashes or you can't get to your favorite web site.
Just say the magic words: 'tight coupling'
Slashdot - where whining about luck is the new way to make the world you want.
If I've got 5-10 minutes, I use a simple exercise of getting them to sketch out a program for a humanoid robot to set the table, i.e. to carry cutlery and food from the kitchen to the dining table. Before they begin, they consider it a trivial task. After about 5-10 minutes, they accept that even this "trivial" task is close to impossible. Here's an example: First, you have to get the thing to walk from the kitchen to the table. So you have to teach it to walk. Then you have to teach it to avoid obstacles. I tell them that their robot has just crushed the cat (it's not a chair or table, which was their understanding of an obstacle). So they modify it to avoid small furry objects... and kill the dog, which is large and furry. So they modify it again, and find that it's frozen in front of a throw rug, which is small and furry. So they modify it again, and find that it's been halted by a sleeping cat. Then you throw in exception conditions, e.g. a fire, or even just the phone ringing so the robot has to clear the way for someone to get the phone... it's fairly easy to demonstrate that even the apparently most trivial task is in fact incredibly complex once you have take all the different conditions into account, and depending on how much time you have (and how long they take to convince) you can keep throwing hurdles at them almost indefinitely.
> Here's a challenge: try to explain bayesian filters to a non-technical native japanese speaking boss.
:-)
I think you'd say something like, filling in the blanks as required:
"Battousai-chan no jutsu ____ na shime wa kokorono. Hikariga to ____ fuiteru Kwabaru-baka na Kagome-sama de arimasu."
Don't worry if their eyes glaze over and they look *REALLY* confused. That's perfectly normal...
Well, there's zapping and there's zapping. Our full clean build takes the best part of 18 hours on the fastest dedicated hardware we can get.
This is kind of contrarian, but I don't agree with the premise that software is really that complicated. I am an embedded software engineer at a medium sized American company. I work in a group with about 30 other programmers, but the company as a whole must have more than 1000 people that write software. It's easy to sit back and think, "Wow, I'm really smart so this stuff must be hard." But certainly most of the people I work with _aren't_ so smart, they're just run of the mill college graduates with engineering degrees. Basically, given a progamming problem, it is solvable by about anyone who knows about programming. Sure, the solutions vary in elegance, code size, defect rates, etc., but it's kind of like every other engineering job. There are a few small engineering tradeoffs, you get more experience as you do it so you make better decisions, and everything else is economics - based on how long something takes to code up, will customers pay enough to generate a profit?
:-) But seriously, if you treat it like a discipline and not an art, the number of mistakes you make as an individual programmer should go down over time to basically nothing. (No, I'm not there yet... I am currently porting code from one embedded platform to another, and I am definitely introducing mistakes :-)).
:-)
The only thing I can think of that might make it seem like software is complicated is that it is error-prone. But this is by choice, people are just lazy
If I had to list some great software and think about how complex it is...
google maps... cool idea, fantastic implementation, but complex? It's a freakin' map with an API
The linux kernel - fantastic open source, but isn't writing an OS something you do as a sophomore in college? again, not rocket science.
gcc - actually, writing gcc would be pretty hard. But have you seen how badly it optimizes? The hard parts aren't done yet.
The fun part of software for me is the idea and the design... after that it's just implementation, trying not to introduce errors.
And not introducing errors in the idea and the design
When I tell people what I do, I either joke that I play games and watch movies all day, or I tell them I'm a typist if I'm being honest.
The 100 line function and the trash novel are more complex. The 10 line function and the Haiku are simpler. Also, more elegant and better.
...I guess. To my girlfriend, using a cooking recipe analogy would be more appropriate (fast food meal, 18 course high level fatcat state dinner in Paris, etc), whereas talking to any of my bubba gearhead friends, I would use cars (engine/drivetrain/body/accessories, etc).
You would have to tailor (there's another one, garment construction and weaving and different materials and threads, etc) the analogy to what that person already understands in their field of interest/expertise.
Myself, I don't want to know, I'd rather ya'all smart guys who can type fast slug it out, see who wins, I just want my browser secure and printer to print, thankew so much and stuff. And here ya go, have a nice fat strawberry just came out of my garden today, I manage "solar photosynthetic energy conversion" combined sentient and non sentient biological factories with a little "terraforming" on the side. You'll have to figure out what analogy might work for me to 'splain programming...what I have figured out is that part of it requires you to really rag on other dudes over whether to use sanskrit or aramaic or something like that. All greek to me...
Something simple yet power is the network node connection count. The potential interactions between nodes grows out of proportion to the number of nodes. In software, all factors can potentially affect all other factors, expecially in biz apps. Here is a sample chart:
Node - Interactions
2 - 2
3 - 6
4 - 12
5 - 20
6 - 30
etc...
This is not an exact metric, but gives one feel for how complexity tends to "fold on itself".
Table-ized A.I.
Whatever analogy you've just given, PLUS,
Having to share resources with other programs, threads, drivers...
Having to deal with sudden power loss, bad hw, actual bugs...
Having to deal with multiple cpus, connectivity, scalability...
Having to deal with malformed input, lax standards, bad guys...
Having to deal with legacy code, buggy libraries, the STL...
The only person I can ever explain anything to is my Dad. We learned C++ and Java together although he has about 40 years of experience in computers.
I work in security, have worked for Network Associates, Symantec and two other security related companies. When I try to explain something, I usually start at the problem end. Explaining why it is such a problem. About two minutes into that, they don't want to know the rest. Saves me the trouble.
Sometimes I go out to eat at Taco Bell or Arby's or a Chinese Buffet. Usually they're empty, though sometimes there are people much older than me there, mostly grey hairs, sometimes a mother with her, I'm guessing junior high school daughter, sometimes there are couples. There are stores, a Wal-Mart and Gamestop. What should I do? Saying to get out of the house is one thing, but everyone else is hiding out in their house, because there's nowhere they want to be, nowhere to be.
With this, I (almost) always get "If it's red, you stop. Green, you go." and which point I interrupt "And yellow (or orange for you Aussies out there)." It's about here that they start to think about it. Then I ask "What if it's raining?" quickly followed by "What if it's the first rain of the year?" and shortly thereafter followed by "What if you see someone else running the light in front of you?" I then explain that if I were writing a program to do something as "simple" as deciding if it's safe to go thru a traffic light, I'd have to think of ALL of these issues, plus everything else that could ever possibility happen while traversing an intersection. If I manage to miss something, it becomes a "bug" in that program.
In my experience, people pretty much "get it" with this analogy. Course, YMMV...
"1984" was ment to be a warning, not a guidebook. You hear that Kim Jong-il!? BushCo?!
I've even explained how interrupt handlers work in regards to a USB joystick to a Lawyer... He was so happy in the way I explained it to him, he kept asking more and more questions until I told him I have to go :P
Ah great.... Now your lawyer is going to wager a class-action lawsuit on behalf of all USB devices for illegal discrimination and unfair employment practices by the interrupt controller. The PCI bus will be named as a conspirator and the CPU will be charged with negligence. The PCI sound card will be the chief witness.
I think that really does it! I (count my lucky stars) rarely have to deal with non-techies in an official work capacity, but the world still abounds with them, and they seem to divide into two categories, those who are like "Hey, wow, you can program a computer! You must be a genius!" and those who are like "so, you just tell the computer to do this, and then that, and you're done!" (those who imagine that every programming language has a "do-what-i-mean" statement.
---
Play Six Pack Man. I
That's who and why and I can understand that.
Her reaction is generally "just plan better". I argue that the industry has been struggling with this issue for decades. I don't think we're all morons to have built so much infrastructure and come so far, but we still can't solve the simple parts like accurately identifying how long it will take us to accomplish our goal.
Hmmm, I'm still not sure what you want to explain but I'll take a swing anyway. I can think of social, technical and legal complexities to software development. I've talked to my wife about all three. You might be thinking of something completely different.
Talking to my wife is not all that hard, even though she has no interest in programming. Her first and only practice was some kind of basic in grade school. She was an interior designer for a Steelcase for eight years and understands all three classes of difficulties.
Others have done a great job explaining complexities in terms of free software. Voices from the Open Source Revolution has a lot of clear thinking from software masters. Vixie's article about software engineering is particularly germain. You can also get a lot of good thought from the Free Software Foundation's philosophy pages. The Cathedral and the Bazaar deals with the issue explicitly. Indeed, there's an embarrassment of riches matched only by the wealth of text editors in the free software world.
So, how do you get from there to dinner table conversation with the wife who's never written a line of code? It's the same way you try to simplify everything and the largeness of the subject actually helps.
You start with what a program is and everything flows from there. My wife, like most people, understands modularity. "You eat an elephant one bite at a time," is one of her favorite sayings. She also has a basic idea that a program is something that takes information and does something with it. It does not take too much to explain that programs expect specific organization of their inputs to be able to deal with it and that smaller, simpler programs are easier to work with that big complex ones, and the wife then understands modular programming. It's a division of labor kind of thing that runs right into group development and organizational and social complexity. How do you know what the customer really needs? How do you make decisions about meeting those needs and turn those into a blueprint that you can follow? The free software world has solved those problems by letting the customer make the software themselves, and those customers have been organizing themselves very well. At that point, you zoom back into the perspective of a developer getting their hands on some huge project. If you can imagine that the free software developer knows what they want to accomplish, you are then faced with another embarrassment of riches: so many great tools, each of which can take years to explore. Did I say "free software developer"? Yes I did, because I did not want to wade into the swamp of NDA's, cross licensing, binary blobs and other horror stories of legal complexity. That can come later. By now, your wife's head will have popped but you will have explained software development complexity.
Like most things, none of the parts is particularly difficult, there's just a lot of parts.
Friends don't help friends install M$ junk.
6 million parts in total or 6 million unique parts?
When i'm discussing a request for implementing a new requirement or changing an existing requirement with the non-technical person making that request, a trick i usually do to show the complexity of apparently simple requests is to right there, present the high-level (eg. design) logical steps on how we would implement that request.
...
Non-technical people will understand the complexity of doing something when they follow you through the sketching of the process of making a solution that does it. For example, if you are asked to change a form so that a free text input field becomes a pull-down with a number of options you can:
- Ask them if the list of options is fixed or if an application administrator can change them
- If it's fixed, then it's easy to do, otherwise:
- Explain that you have to store those options somewhere. Maybe you already have a database, so explain that you have to add storage tables to the database, then add code to the application so that it can load and save that information to and from memory. Also explain that you have to pre-load some sensible default values into the database so that the application works out of the box.
- Since they want that some administrator can change it at runtime, figure out if said administrator is a developer/dba type of person or not. If not, explain that to allow an administrator user to change those values you have to extend your administrator interface, which means adding menu entries and one ore more new pages.
- Also figure out what are the rules (if any) that constrain the values that the administrator can configure for the pull-down. Depending on the complexity of the rules you might want to follow through into how you would do it, for example, if the rules are based on other values in the database which can also be changed by an administrator:
- Explain how you have to add code to retrieve and process the needed values so that you can check that the rules are not being broken, and that you also have to change the administrative interface for those other values so as to make sure that when they are changed or deleted, the values in the pull-down box do not become invalid.
-
The point here is that most non-technical people which actually use computers understand concepts such as memory and storing "data that cannot be lost when the application stops" (persistent data) somewhere other than memory. They can be made to understant the basics of a relational database: "a place to store data which has tables - a bit like excel tables - one table for each kind of information" (not exactly it but close enough) and they can usually follow a logical chain of steps (eg to show the data in the interface we have to get it from somewhere, since it is configurable, we store it in the place where we put the data that can be changed by the program but must be preserved even when the application stops).
Try and stay away of techie words and expressions ("We're gonna have to persist that data to our relational database and that means creating new tables, adding new data objects and changing the Hibernate mappings"). Instead assume non-techies are ignorant but not stupid ("We have to store that data in the database so that we don't loose it when the application stops. This means we have to configure in the database the tables where the data is stored and also have to add support in the program so that it can load that information into memory and use it").
Also, simplify:
- Don't try to be overly exactly - for a non-techie is enough to say you have a "database" no need to say it's a "clustered configuration of a <insert-brand-here> relational database".
- Don't go into deep details - you "configure the place in the database to store the data" no need to say you're "extending the tablespace, creating new tables, adding foreign keys to the related tables, and setting up a couple of indexes to speed up cross-referencing"
- Try and tune your words to the audience - for some people you can say you're gon
The other important ramification is that it never saves developer time to remove an existing feature - and in an agile development process it may take more time to DECIDE whether a feature is important than it would have to simply implement it.
That's only true if the function is a separate piece of code. I've been in enough situations where noone really has the overview but it turns out that some code isn't being used at all anymore, often because the entire function/module has been depreceated and then deactivated, but the code remains. It can be a horrible mess.
Live today, because you never know what tomorrow brings
So, you have tried to explain to other intelligent, competent techies why programming is so much more complex than what they do, but you can't seem to convince them, eh?
Have you considered that maybe, just maybe, you are wrong? Maybe programming isn't harder than hardware design, or mechanical design, or mathematics, or physics? I mean, if it were, it would be a really convenient excuse, wouldn't it? "Your OS crashes so much because software is really complex." "You got infected by this virus because security is software, and software is really complex." "I missed this deadline because programming is really complex." Personally, as a professional, I am leary of ideologies which promise to exculpate me of professional responsibilities.
Brooks writes, "software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound." This is certainly true. However, you have to ask yourself if it is necessarily true or only accidentally true; that is, is it the only way software development can be or is it merely the current state of software development, perhaps because we don't yet understand programming well enough? For example, better programming languages let you abstract out more complex and varied patterns in software than worse ones; the result is simpler, more regular programs. As our understanding of how programs operate and are structured improves, we can expect to make them smaller and more regular with such tools.
The proper response to, "Programming is hard!" is not, "Therefore I am not responsible for bad programs," but rather, "How can we make it easier to meet our responsibilities?"
BH
Fools! They laughed at me at the Sorbonne...!
The simplest is browser compatability. Does the site owner care? Well yeah if you can get their head around the fact that if the site is IE only they will be losing a percentage of customers. It is very odd. Supermarkets understand they need an extra wide register for people with special needs. They know they need staff on hand to help disabled people because no supermarket can afford to turn that tiny percentage of people away who need help. Most brick and mortar stores would be horrified to learn that their to narrow door would loose them say 5% of visitors. So why is it acceptable on the net?
Then their is the proper use of standards. It ain't just that you got to use CSS but more that you got to choose a standard way of doing things. Use font tags if you want BUT then ALWAYS use them. Not some horrid combo of font tags, inline css, external css and included css. Makes it a pain to figure out what the fuck is supposed to affect what.
Finally there is the coding itself. Every damn time I get called into to fix a site I find that some kiddie has hacked it together and totally forget to do any kind of error checking let alone proper security. Most just take values straight from the user and insert them into sql queries. And why does anyone create a login page for the site CMS without https being enforced?
I seen code that would make you weep. Yet the site works doesn't it. Well no that is why I am called in but it then is very hard to explain why you need a week to upgrade the site before you can even start fixing things. (Note that the sites are generally so poorly designed that the original builders are no longer willing to support it wich is when I get involved).
But how do you explain to the customer about the difference between bad code and good code.
Recent page had a simple form for the usual add, update and deleting of a record. The code contained no functions and had the most horribly arranged IF/ELSE statements you could imagine (IF(user_logged_in) {ALL THE CODE} else {error_msg} EWH!!!!!
Worse it had the HTML/FORM 3 times for each type of action. Except that they were practically the same. Just an empty form for add, a filled in form for update and again a filled in form for delete. 3 Times the same HTML all because the idiot never grasped the concept of functions. (He didn't use them anywhere in the code).
Yet how do you make this clear to the customer. If you know the answer please tell me.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
PS. I am not sure if there is a duck in Christmas Carol.
I would keep on quoting No Silver Bullet and expand onto the rest of the "complexity, conformity, changeability, and invisibility" mantra.
Especially the invisibility part is usually easy to grasp.
One textbook also made a comparison with a steel bridge: if the bridge crashes the damages are huge, if software crashes a boot can usually solve the situation temporarily. Also, civil engineers are rarely asked to move the almost completed bridge mile upriver and turn it 90 degrees by the lengthwise axis.
Karma: Good! Napster: Baad!
Try it in terms of decision tables:
Each condition requires a true/false decision, plus an associated action.
Rule1 y y n n
Rule2 y n y n
Actn1 x - - -
Actn2 - x - -
Actn3 - - x -
Actn4 - - - x
Therefore the mathematically possible combinations = 2^n *2. (The example shown is 2^2 * 2 = 4 * 2 = 8.) A two rule program has 4 mathematically possible conditions and 4 mathematically possible outputs, therefore the programmer has to attend to 8 elements to cover the complexity of the program. With five conditions, the programmer would have 32 mathematically possible conditions with 32 mathematically possible actions, so the programmer would have to consider 64 elements to cover the complexity of the program. Of course, a good programmer recognizes that many of these elements are redundant and not logically possible, but the programmer still has to administer rules to cover the logically possible elements and actions. Now consider that a reasonable inventory program may have over a thousand conditions and you see the exponential increase in complexity.
I usually show a table with 2, 5 and 100 conditions and watch their eyes glaze over. No more arguments.
Mike
"The mind works quicker than you think!"
Isn't the US Library of Congress (28 million volumes, or roughly five terabytes) still the standard unit of absurd information-theory metaphors?
Just say the magic words: 'tight coupling'
That's not sexual harassment?
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
A computer program is a recipe for cooking a fancy dinner, for someone who can barely make kraft dinner.
The amount of detailed information the person who can't cook needs to cook a meal is in every single computer program.
It's that simple, I've used that analogy often and always gotten comprehension.
J. Henager: If the average user can put a CD in and boot the system and follow the prompts, he can install and use Linux
If I remember correctly, I was in grade school when we had an assignment to teach someone how to do something. The thing that I "taught" was how to make a peanut butter and jelly sandwich. The catch, though, was that you had to explain *every* little detail of it.
For instance, you couldn't just say "put peanut butter on one slice of bread." Instead you had to go through:
* Get the peanut butter from the cupboard
* Get a knife from the drawer
* Unscrew the cap from the peanut butter
* Using the knife, scrape some peanut butter out of the jar
* Take the knife with peanut butter and place it on one slice of bread
* Smear the peanut butter onto the bread, covering a reasonable portion of it
That's the analogy I use to help "teach" the concept of programming to non-programmers. The computer needs *every* instruction from you, with the added complexity of what to do if you don't have peanut butter or bread or a clean knife, etc. This seems to get the best response of any other method I've tried... but again, YMMV.
PS. I am not sure if there is a duck in Christmas Carol.
There is a goose (Pigs and turkeys apparently being highly unusual in 19th century London butcher shops at Christmas).
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
Explaining to company executives why complex software development takes a long time is often necessary during the development of a system. There's a tendency for management to unwittingly sabotage software development in many ways, such as by not recognizing the true costs of their unplanned-for requests. If management has even a vague understanding of the issues involved, it can help a lot in having a good relationship between developers and management, and ensuring that projects aren't cancelled to early due to unrealistic expectations, or don't end up in "death marches" which burn out programmers and sour management on all software development. As a consultant, I've seen this happen both ways. In all the cases where management "got it", it was only because developers had been successful in communicating to them why the job can be so difficult.
Of course it is communication. But it is not that communication that makes it s hard. All a a red light on a plane closet is doing is communicating. And the thing it commnicates is mind boggling simple. A single bit so to say. The communication is so mind boggling simple, because the thing it has to communicate is so mind boggling simple. If you try to communicate the works of Shakespeare with that light, it suddenly becomes not so simple.
So the communication is the easy part. Analysing and thoroughly understanding your problem is the hard thing. Once you have done this, the code almost writes itself.
Just because I can imagine doing a hippopotamus, doesn't mean I'd like to do it.
Good thing I didn't try to explain how "complex software systems are", then I wouldn't of given you the opporitunty to play the roll of the Slashdot Troll.
Modesty is one of life's greatest attributes
Simple, use something familiar to whoever you are trying to reach. For a business person, talk about how programming is similar to a business process; for a teacher, talk about how it is like putting together their teaching plans; etc. You will never reach anyone if you don't illustrate it with something that is familiar to them - it also helps to be generally familiar yourself too, though you can always get them to help fill in the details of how whatever it is they do works. Basically - relate it to their job.
However, that would only work for describing how a program in general works and is put together (i.e. inc ax; mov [ebx+4], cx; etc.). When it comes to other kinds of concepts (Design, requirements, etc.) you need to still use something familiar to them, but perhaps something other than their job - though that might still work in some cases. For example, in describing how one project does its job but could really stand a lot of improvement in its design, I described the original version of the project as a 'tape player' and the new version as what we wanted - a 'cd player' - but it pulled a lot from the old version, so we made the 'cd player' understand "tapes"; however, what we really want is the 'dvd player' that can play the "cd's" and do more too. Make it connect, and make it make sense.
A good reminder might be - if a 5 year old can't understand what you're saying, then you need a different analogy. Not perfectly true, but something that works. Alternatively (if you don't like 5 year olds), one of my teachers use to say to document our programs like his grandmother would be reading them - if she couldn't understand it, don't expect him to either. In the end, just remember to keep it simple - apples vs. oranges type simple.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
the easiert way ive found to explain it to my freinds actually came from one of them telling me how he builds houses. each part of the software has elements like windows, doors, room size, and each room peforms different functions like a bathroom has different elements than a living room. so i say building a program is like building a house, only you dont want windows or itll break! :-p
I'm not trying to suggest that an appropriate model is to always add every feature anybody thinks of. There are very valid reasons not to bloat your code like that, to keep it easier and simpler to maintain, test, audit, secure, etc.
But there is still a difference there. Perhaps I could best explain it as: You can never take your existing software, spend time/money optimizing it, and somehow make it cost you less to produce a million copies of the software.
(More USERS, maybe, but not more copies of the software - in a situation where you make it handle bigger load on smaller hardware. More PROFIT maybe, if more people want to buy the new version.)
Very rarely is the reason a feature shouldn't be present that the cost-to-make-copies is too high. In cars, for example, a lot of work goes into taking existing components and making the production cheaper. There are plenty of other things you can optimize code for, but you can only rarely spend significant time optimizing existing features for "cheaper" You never go back, take your existing really well-written function and replace it with a less-effective one because the less-effective one because the worse one is cheaper to copy. (Unless you've licensed that great code from someone else, but that's somewhat artificial)
You might choose a faster algorithm over a more accurate one - or a simple and therefore easier to audit algorithm over a complex but more accurate one. But you are still missing the entire optimization about the "produce copies" part of the development of _anything_ else that people produce. To me this is the dominant reason why it's so easy to make complex software and the dominant reason why software is massively more complex than anything else for a given number of hours of development.
(Which is not to say that, say, the CPU hardware isn't very complex. But a LOT of people have spent a LOT of time on that. )
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
That depends. Are you watching the Disney version?
You know the annoying kid you knew in college who would repeatedly interrupt every discussion demanding definitions of all the words being used, and who would argue endlessly about flaws in the definitions so that you couldn't really talk about the topic you wanted to? Imagine you're writing a book, and that guy has to personally approve every sentence.
Now image one doing thousands of more things.
When I am asked why a certain program is broken, or why building one takes so long, I respond in terms of "moving parts".
The average automobile has about 150 moving parts.
The space shuttle has 100,000 moving parts.
A complex computer program (Windows, Linux, OSX, Photoshop, Quark Xpress, SAP, Great Plains, etc.) have 1 million or more moving parts.
(I generally consider a subroutine a "moving part").
I then equate installing a new program to adding a new stereo to a car or installing a hitch with a hitch brake. Or I compare different types of factory cars: The low-end models with a manual transmission, no A/C, and manual steering/locks/windows/seats vs. higher-end models with all the options. The more options you add to your car (programs), the more things there are that can break and need to be fixed.
Along the same lines, writing computer applications is like building a space shuttle with lots and lots of moving parts. The more "things" you want a program to do (the more "options" you want on your car), the more "moving parts" you have to build that can eventually break down.
When explaining how programs interact with each other or with the operating system, I use the analogy of aftermarket car parts like stereos: When you install a new stereo in your car, how long it lasts depends on the quality of the car (operating system), the quality of the stereo (the program being installed), the quality of the technician installing the stereo (the programmer), and last but not least, the actions of the driver (end user).
I have found that explaining complex issues in terms of physical everyday activities and objects really helps most people understand just how complex computers are.
Most people are not experienced in virtualization and abstraction, and have a difficult time imagining something that they do not have a physical reference on which to base their visualization processes.
You need to think of the CPU as like an employee with a really bad passive-aggressive personality disorder. He does exactly what you ask him to, except that he always manages to find an interpretation of your instructions that frustrate your intentions.
When you get to the point that you realise that you have to sack him and hire somebody else, there is no way to get him to do the job right, you find out that he is the boss's son and you are stuck with him. You have to hire lots more staff to give him ever more detailed instructions, until there is no loop hole left and no way to screw up by doing what you say rather than what you mean.
McCabe's complexity measure (count no of conditions and add 1) perhaps?
SCIREV.NET - fanfics,reviews & more
The 10 line function and the Haiku are simpler. Also, more elegant and better.
I disagree with the idea the cramming the most amount of logic into the least amount of lines is elegant. Brian Kernighan said it best, "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
"Nature doesn't care how smart you are. You can still be wrong." - Richard Feynman
Software is like cooking Blow-Fish / FUGU.
Since fugu's poison can lead to instantaneous deaths of diners, only licensed cooks are allowed to prepare fugu. You must have special skills and knowledge about fugu to be licensed. Poisonous parts of fugu differ, depending on the kind of fugu.
However, managers usually go and get the cheaper/unlicensed cooks. And then complain about the project's failure.
We are Turing O-Machines. The Oracle is out there.
What's more complex? a 10 line readable section of code, or the same code crammed into one unreadable 200 char line?
It's possible to simplify code by stretching it out.
Me, I like the 200 char unreadable line. Don't even know the whole ugliness of it. Just scrolls by, like the wind.
Man, you really need that seminar!
A DVD of "Dumb and Dumber" is 9.4GB, you filthy pirate.
Man, you really need that seminar!
On blocks.
With a palm tree growing out of the engine block.
Man, you really need that seminar!
I didn't say anything about cramming in the most code possible. I define a line of code as a bit of code that SHOULD be on one line. I'm quite aware that you can write an entire program in many languages that is technically on one line, but that it definitely should not be.
The Haiku and trashy novel example is actually better because you've given something to go on -- provided the two express the same idea (they are functionally equivalent) then the Haiku is simpler, more elegant and to be preferred. As for debugging, imagine you're going to proofread both for spelling mistakes. Which would you prefer?
For the code, I was making some assumptions: that they were functionally equivalent (implied by your comparison), your lines of code obeyed my definition (not a fair assumption) and nothing really crazy was used to write those ten lines.
Saying that, I've seen lots of 100 line functions that can easily be written in ten good lines. The ten lines are simpler, more elegant, and to be preferred. They're also MUCH easier to debug. The 100 line function usually comes about because whoever wrote it didn't understand the problem sufficiently.
Very rarely am I passed. I suppose when I lived in Muncie two years ago, with Ball State University, if I waited for classes to let out, I would have run into someone, but everyone else would have been busy getting to their next class for the most part.
You insensitive clod!
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
If you need to do the same thing many times, use a subroutine. That way you only need to write it right once and use it many times.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
theres not really any point in explaining software engineering to a user
the whole idea behind designing a software component is to hide all the details and present a easy and usable interface
25*10^4 lines of code, stored in 25*10^6 bytes, would make your average line 100 chars long. That is, visually, your code would indeed look like a novel...
Programming is like writing a novel. If you are a good writer, you can whip up a short story without any trouble. With enough effort you could write an entire novel.
Now image you wanted to write a HUGE mystery novel. Each clue and detail needs to fit in with the story. That in itself is hard.
Now complicate the project by having 30 people write that novel in 9 months. Each writing a part of it but it having to meld together as if written by a single person. And it still needs to be coherent and be good writing.
Get the picture?
and for a practical example set your wayback machine to January 15 1990 and try to make a long distance call inside the USc kdown/hack_part1.shtml
http://www.voidspace.org.uk/technology/hacker_cra
The crash was a grave corporate embarrassment. The "culprit" was a bug in AT&T's own software (caused by a stray semicolon)
Any person using FTFY or editing my postings agrees to a US$50.00 charge
Eventually people learn that this really means "I don't feel like doing it." When that happens, I get a new job and start again.
I still have the remnants of a drawing on a white board at work that includes:
... among other things.
a fishing boat
lots of hooks in the water, some with fish on the line
people using a radio in the boat
a radio tower
people with fish and radios in a building
Somehow, i used all of this to help co-workers understand the architecture of a project that i've been working on. Afterwards, they sort of understood the meanings of Hook and Proxy to developers
Unfortunately, now they all think they understand development better and, every time i say something they don't understand, they say "that's like a hook, right!?"
Lukily it's not all MY code....and most certainly a good deal of it does. This has got to be the most complex project I've ever worked on, and it doesn't help one whit that while the project is designed to follow good software development life cycle standards (with all of the extra documentation that implies), quite often the coding is being done before the analysis of user requirements is complete in practice, thus createing a horrific hodge-podge of patches on top of patches on top of patches.....
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
Programming is a little like quantum mechanics. Just read this article and replace the various keywords with proper software jargin. http://en.wikipedia.org/wiki/Quantum_Mechanics
What's unusual about computer programming is the fragility of programs as much as the complexity. Laws are complex, too, because they try to cover every situation -- but if the law doesn't cover some situation or there's bad logic, life (usually) goes on. In software, unhandled cases or bad logic cause bugs and crashes.
:)
Part of the cause is that computers don't know what you mean. When a law is ambiguous we've got judges and so forth who can apply common sense and work out the details (and sometimes make stuff up). If the text of a statute is missing a semicolon, the judge can usually figure that out and read on.
We have none of those luxuries with computers. Compilers only know a small set of rules about how to assemble simple instructions into bigger and bigger chunks -- they only know at a really superficial level which arrangements of instructions make sense (so they can't correct logic errors), they usually don't learn through observation (only by being explicitly taught), and they don't know much at all about reading programs that are incorrectly phrased (because we haven't taught them). (That gives me a great startup idea...)
Explaining things to sufficiently young kids can be hard because they often don't know what the concepts in your explanation mean. It takes a while to explain the sentence, "Before Mommy and Daddy got married, Mommy tried to make Daddy jealous by going out with another guy." It's far, far more complex teaching a computer to do something -- they're not as intellectually flexible as your average kid and they know even less about the real world.
In 8th grade (1974 before computers were common), my teacher did an exercise with us. We were to write instructions to shoe laces. Then the student read the instructions to the teacher. She did exactly what the instructions said. Nobody ended up with tied shoes. Everyone understood that computers do exactly what you tell them to. Do this for fun at your next family gathering.