A couple of weeks ago I finally got around to visiting Stack Overflow, the new Q&A site by Joel Spolsky and Jeff Atwood. It's a simple concept that I found both fun and engaging, a place where users can ask and answer specific programming questions.
It's easy to submit new questions, so there is a constant stream of inquiries to be answered. For each question you ask or answer you give, you get a collection of reputation points (some positive, some negative, depending on content). As you answer more questions, you get more abilities, you can do more things on the site. Also, there are these cutesy little badges that you can earn for specific milestones, adding an extra amusing level to it.
It's a great site, completely engaging with a decent interface. It is simple enough to use, and it has the feel of being a cross between a social site, a news feed and a repository of answers. In concept I think it's a great idea, but I was finding that in practice there were some interesting issues.
Sites come and go rapidly on the Internet, it is a very volatile medium. Things move very quickly. This makes it an interesting place to observe how people interact with each other and their software. You don't have to spend a long time to get an a good sense of what is happening. Web 2.0 has provided a large number of good public examples for analysis.
For this entry I figured that although I like Stack Overflow, the dynamics were interesting enough that I could spend a little time digging into the types of problems that may occur with the site. It's a good place for analysis, and we usually don't have to wait long to see if its right or not.
AT THE EDGE OF CONTROVERSY
My short membership on the site has been fun, but not without its share of controversy. Not being one to lurk for too long, I jumped in pretty quickly with a few questions and a fair number of answers.
What surprised me was that my first question "Success vs. Freedom" got into trouble right away. The title was re-edited to "What kind of programming method do you prefer? Success vs. Freedom", and then a discussion broke out in the comments about whether or not it was an appropriate question.
The mandate of the site is to answer "programming" questions, and it seems that some of the "stackers" as they like to call themselves, take that very literally, while others would prefer a wider latitude. A problem with this is that roving stackers with high reputation are allowed to enforce any rules as they see fit. If they have enough reputation points, they are allowed to alter the questions. The site content is completely controlled by its users.
My first question was closed initially because there was no way to answer it with just facts, all answers were inherently subjective. However it was re-opened shortly thereafter by another stacker, and managed to stay around for a while.
My next question was trying to provoke a discussion on this issue, clearly against the rules, but it too failed. It was "Are there legitimate programming questions that cannot be answered by facts?", a loaded question making reference to the fact that the FAQ says any question asked should be expecting just facts as answers.
The problem with Computer Science is that it is a highly subjective industry at the moment, we have precious few 'facts' that are not actually contained in a manual somewhere on the web. I wanted to get people thinking about the scope of this site, and whether or not facts are just far too limiting.
In a very real sense the questions with subjective answers are the ones that are above and beyond just the simple RTFM questions. Facts might be nice, but they are too simple to really be helpful, at least not in the long run.
Most surprisingly, my third question, which was really relevant to my current working situation got shut down immediately. I recently switched my main programming workstation to a quad core chip and I was wondering how to best set it up. Here for the first time I really needed an answer to a real problem, yet my query "What are the best performance options in XP for a quad core ship?" was shut down right away for not being relevant to programming.
The comments suggested that a cheap spin on the question -- like following one of those future cookie tricks were one adds "in bed" to the end of each fortune -- might have allowed the question to remain open. In this case one might simply tack on "for programming" to each question and possibly get away with it. I was thinking about trying that, but it just seemed far too lame.
Judging by the range of the various questions in the site, there seemed to be some disagreement going on, as to how to interpret the FAQ. As often plagues these sites, the old guard is struggling against the new guard for control of the content. Wherever there are people, there are disagreements.
THE LEFT VS THE RIGHT
The rules of the site are very specific, but some stackers feel that the interpretation should be lenient, while others want a very strict enforcement. That matches any large group of people, where the more serious people often get worked up about the little details, while others advocate a more relaxed approach to life.
The conservative members do have the noble goal of trying to keep the site from degenerating. Clay Shirky famously pointed out that the group is its own worse enemy, so it's likely they are right; if left unchecked the content on the site will go down-hill quickly. Still, one has to be careful with simplifying any situation to that degree. Behavior is dependent on the context and the type of people involved.
A site like this is mostly made up of two types of people, those seeking answers and those wanting to answer. The dynamics of those two groups will either help to the site to grow, or let it wither away.
The rules dictate little discussion, so the stream of questions is forced to be very specific and more or less junior in nature. Fact-based answers are really things that should be documented in help pages somewhere, thus the site's mandate is to essentially stick to well-known documented items or items that were missed for some reason.
Keeping the scope of the current questions down to a tight-nit range of purely factual questions will definitely keep out the fracas, but it will also heavily constraint both sets of users of the system.
New programmers go to the web to avoid reading documentation, and as I said, that makes up the majority of fact-based questions. The questions are simple, and direct, yet they belong to some larger, unknown context. They weren't asked at random. That means the usage of the answer may actually be more significant than the question itself. We'll get back to that point a bit later.
Also of interest, those answering the questions are not necessarily, as one might assume, the seniors in the industry. In fact it's more likely that they themselves are still in their first five to ten years of experience, just starting their careers. It's a leap, but not a far one since for most programmers who have seen several generations of technology come and go, there is a tendency to be more elastic with their knowledge.
When you first get into coding, you're driven to learn everything possible, but as time goes on and your favorite technologies get replaced again and again, you start to wise up. Why go deep into the technology if it's just going to get replaced again? There are, no doubt, many older senior programmers that maintain their high energies, but they are unlikely to be the majority. Most of us have seen it once too often to be impressed by seeing it again (in a crappier form). We lose interest in the little details as we get more experienced. You can't help it.
Thus, most of the people capable of answering the more modern fact-based questions are the ones that have learned that information recently and are still interesting in showing off how much they know. At the moment, it's fairly safe to assume that most of the people attracted to the site are juniors and intermediates.
Sure there are lots of seniors (you see this in the "How old are you, and how old were you when you first started coding?" question that they keep trying to kill), but their answers are probably more selective, and subjective. And they'll drift away faster.
Thus the conservative approach to keeping the site pure by weeding out questions then is to continually put pressure on the site to answer just fact based questions. But these type of questions, for both the asking and answering sides tend to drive the content down to a more junior level. A level that competes more heavily with the rest of the Internet, and also tends to become stale quickly.
The conservative side is perpetually in jeopardy of choking off the good and really useful questions, primarily because they don't have a long enough horizon to distinguish between the real issues, and the faux ones. My question on XP settings was a good example, as it very much relates to programming, yet it doesn't explicitly mention the word 'programming'. A limited scope means that limited usefulness.
Still, there always needs to be some type of constraints put over the content. If the site becomes too unruly, the signal to noise ratio will cut off its usefulness. There will be too much junk to make using it worthwhile. There are enough degenerated sites out there to know that it is a very probably direction for this site.
So we can can speculate that the site leaning too heavily in either direction will kill it. However, there are also other problems that will build up as significant issues over time.
THE REAL SOURCE OF KNOWLEDGE
A long long time ago, when I was a junior programmer, a coworker came in hurriedly and asked me a technical question. I can't remember the details, but it was an easy question for me to answer. Just as I was starting too, my officemate, a really skilled senior, battle-hardened consultant jumped in and started asking questions. They were mostly in the form of "why do you want to know that?". As he dug, it turned out that my coworker was clearly on the wrong track. A dangerous track that was minutes away from doing something dreadful to the system.
If we hadn't dug into the issues, I would have contributed to causing a huge mess. My coworker had glommed onto that specific question, because they were basing their knowledge on a series of incorrect assumptions. The question, being simple was actually a huge indicator of a serious misunderstanding. If they understood what was going on, they never, never would have asked that question.
The consultant, of course, chewed me out for having very nearly supplied the fatal piece of information. He told he, and I always remembered, that as a professional it was my duty to understand how people were going to use the information, before I was to give it out easily. In a case like the above, he said it was important to understand why they were asking the questions, because in many ways that was far more important than the question itself.
These days, that attitude feels very selfish, but there are certainly enough things out there that juniors shouldn't know until they are ready to understand them. They need the information, perhaps, but they need the surrounding context far more.
If we give out information, without giving out knowledge, then there is a huge chance that that information will be used poorly or in a wrong way. And its exactly that which has caused a shift for the worst in programming. It is too easy to get past simple problems, without having the prerequisite knowledge first. We're teaching toddlers to drive cars before they can even walk, and then we're surprised by the numbers of accidents.
JUNK FOOD DIET
The web brought with it a huge boon for programmers. Manuals were no longer hard to get things, hidden in some corner or on another floor. We no longer have to pour over them for hours to seek the smallest of answers to the biggest of questions. All of the sudden a quick search and *poof* you've got your answer, or at least a discussion of the answer.
That change is a good thing in that programming has become easier and diagnosing problems has become faster and more effective. However, all things good come with consequences ...
The web has made it easier to program. In fact the web has made it easier to know far less about programming. And in many ways this is a big problem. We are seeing far more code with a higher degree of artificial complexity that should never have been allowed into a production site. Sites like WTF are getting overloaded with content. Stuff that should have died because the programmer was flailing badly, suddenly gets released because the coder managed to route around the types of bugs that should have been fatal. Bugs, oddly have their value sometimes.
We've become so addicted to this fast-food information, and its having a huge effect. It's highly dangerous to give all of these programmers the simple stupid answers if they do not understand the content of what they are doing. We're not making software development better, we're ruining it. We're making it more possible for partially trained programmers to route around problems that they have no idea how to actually solve.
When you respond with "set the CosmicInverterThreshold variable to 24" it allows the programmer to get past the understanding of why that is the correct parameter, without really knowing what a cosmic inverter is, or why the old value was causing a malfunction. They can just happily ignore the obvious problems, and hopefully the non-obvious ones will disappear to.
We've been seeing the effects of this in the industry for years. Yes, the web opened up the door to quick information, but the quality of the underlying tools has degenerated. We're losing touch with how the machines works, trading it away for just poorly patching problems in a debugger.
It's nice on the one hand for making development faster and easier, but the underlying complexity of our systems has clearly outpaced our abilities. How many programmers actually know what is really happening in their OS? How much is just a big mystery? Are the little elfs that move around the bits red or green?
This both allows weaker programmers to create things that should not have been created, but it also helps to preserve libraries and utilities that should have died a nature death because they were poorly built. Too much information, with too little knowledge has become a serious problem to most disciplines, but a particularly sever one in software.
What is worse, of course is when you see those posts that ask or wonder if you need to learn any theory to program. The current answer: "no, you don't", but it should really be: "yes you do!"
You should absolutely have that knowledge, particularly if you are going to write something serious, but now because of the web, you can just skip over it and forget about the consequences. It's as if we've given the ability for home hobbyists to start building apartment buildings, in any manner they choose. Some buildings, of course, will be nice and well-built, but the rest?
THE QUALITY OF KNOWLEDGE
Quick answer sites serve up huge plates of junk food knowledge. Fast little tidbits that are incomplete platitudes passing for real answers, for real knowledge. The problem is that a steady diet of this type of fluff foolishly convinces most people that they don't need the real thing.
And like anything in this world, there is a huge distance between essentially understanding something, and really understanding the details. Baring those with photographic memory, most people don't really get the details unless they sit within a bigger more extensive conceptual understanding.
That is, you do need to know the theory, so that you can really understand the practice. No matter how well you know the practice, you cannot fill in the missing bits without understanding the encompassing theory. And its what you don't know that will cause all the problems.
You might get by, but you'll never be an expert in something if your only real tangible knowledge is relatively light. Sure you can program for instance, but without a bigger deeper theoretical background you probably will have trouble as an architect, for example. Precisely because you'll follow the popular trends, even when they are way off, and you won't be able to see why they are dysfunctional (until it's way too late). Software development is full of a lot of bad advice, and the only cure is to have a deep understanding.
This problem already occurs on a frequent basis in software. The industry relies on a huge number of domain specific programmers to write very specialized code for specific applications. That is fine, but if you've ever encountered a project were it's all domain specific coders, 100% of them, and no classically trained Computer Scientists, you're likely to find very esoteric code that fails on a very basic level. The domain specific stuff may be quite acceptable for the core functionality, but the whole package is often weak and unstable because of what's not known.
THE SOURCE OF ALL
Knowledge isn't just remembering a few facts or being able to ape a few movements. Information might be what you get, but when you can place something in it's context, it's real context, then you truly know it.
We take everythign we learn and we use that to drive our work. If there are huge gaps in what we know, then our efforts are more dependent on luck than they should or need to be. That, in an industry like software where we already rely on a huge amount of luck and guess work to see us through, puts any project driven by people without a lot of knowledge in a dangerous position.
We all know luck pays off sometimes, somebody wins the lottery, and good things sometimes happen, but the difference between an amateur and a professional is easily the amount of luck they rely on to be successful in their endeavors. Anybody can get lucky, and many people do. But most do not.
Software is exceptionally complicated, and now it's packed into endless layers, each a little more complex than not. For most of the code out there, there are plenty of real theories on which the original designs were based. The industry has a great deal more theoretical knowledge than most programmers are aware of. We know more than we think we do, it's just lost in old papers, private mailing lists or not disseminated to the masses. We're probably the worst industry for having the practitioners ignore most of the common knowledge.
Knowledge is really what most juniors needs when they start asking questions, however easy access to quick answers allows them to bypass that need, and get back to flailing at the keyboards.
GETTING BACK TO THE BASICS
Overall, despite the problems with the content I really like the existing site. Stack overflow is entertaining, however that is not necessarily a good thing. Fun may draw in a number of people in the short-term but it's not enough to keep them hanging around over time. Fun quickly gets dull, the users move on to the next thing.
It takes more than fun to keep users hanging around for the long term. Once the site is no longer the next cool thing, then it faces the real challenges. You need more than just fun to give people a real reason for coming back to the site. The content must go beyond just simple fact-based questions. If people aren't getting something more substantial, they'll quickly move on to the next form of entertainment.
Software, in its current state is a mess and the only real way out of that space is by evolving our knowledge. The reason this isn't happening is that every new generation of coders is rewriting, in a new technology, the same old stuff over and over. And in some weird ways, some strange memes like MVC become sacred cows, while other more significant ideas get lost and reinvented poorly.
What we really need is to honestly discuss our profession and to explore what works and what doesn't. It sounds simple enough, but programmers always fall back into defensive positions, thus making it nearly impossible to really discuss things.
One reason progress is so slow with software development, is that our culture is to hate something or believe in it 110%. There's no in between, so questioning becomes a lack of faith, and thus we get very few real objective discussions. This has been stagnating the industry for years. Once X has become the technology du jour, everyone jumps on the bandwagon or completely hates it. It never gets viewed objectivity for both its good and bad qualities. Once its old, its 100% crap, we never learn any lessons from the good parts.
We just go round in circles. Software will never improve until we find a way to improve it.
And we'll never improve it, until we find a way to discuss the strengths and weaknesses, honestly without rhetoric.
SUGGESTIONS
Discussion and deeper knowledge are huge issues that I think Stack Overflow will need to confront if it wants to remain current. These are the real value-adds that a site like this needs in order to continously drawn in people over a long period of time, and they are the real value-adds that our industry also needs in order to break out of its current mediocre bonds and start utilizing the potential of hardware.
With that in mind, there are a few simple things I think would really help kick the site up to a more useful level:
- allow polls (and let other people mine the data)
- set up a section for definitions (with the best ones floating to the top)
- limit the site to all of software development, not just programming
- open up separate domain-specific sections
- open up separate sections for environment issues (chairs, desks) and tools.
- allow discussions, but limit them; subjective stuff is very important to our industry.
As far as discussion go, find someway to allow them, yet contain them at the same time. Everyone should get their say, but just once or twice at most (I like how the current comments are way too short, so you can't respond with an essay).
And most importantly:
- Encourage alternative ways of thinking, expressing, working, etc.
The answers we have, are by no means at a significantly high state. Software is an immature industry, which eventually will grow tremendously over the centuries. What we know now, will get supplanted with better technologies over time, it's just a matter how fast.
No matter what happens with Stack Overflow, I'm finding it fun right now, so I'll hang around for a bit. But no doubt, like Slashdot, Facebook, Digg and most of the others, when the novelty wares off, I'll fad away. I always lose interest quickly in these types of things.
Monday, December 22, 2008
Wednesday, December 10, 2008
The Best of The Programmer's Paradox
Blogs always see a constant flow of new, possibly intrigued readers. To answer that all important question that every reader has for a new blog, I put together a selection of some of my better works. This should help in making that all important judgment between insane lunatic, crazy rambler or just run-of-the-mill nut job. It's an easier choice if I provide references to some of my more interesting pieces, ones that have a strong point, were more popular or just contain fluid writing.
I've collected together my favorites with short intros, which I'll update from time to time to keep it up-to-date. Hopefully I can tag this in Blogger to make it standout.
If you're a long-time reader and I missed a favorite or two, please feel free to leave a comment. If I managed to get a few more suitable entries, I'll update this document. Comments for older pieces should be left on the original piece, Blogger will let me know that they are there.
NORMAL FORMS
Probably the most influential thing that I'll write in my career is the basis for code normalization, however I fully expect that the software development industry will happily choose to ignore any points in these works for at least another hundred or hundred and fifty years. Because of that, don't feel obligated to read any of these, they probably won't be relevant for quite a while:
http://theprogrammersparadox.blogspot.com/2008/11/code-normal-form.html
http://theprogrammersparadox.blogspot.com/2008/10/structure-of-elegance.html
http://theprogrammersparadox.blogspot.com/2008/10/revisiting-structure-of-elegance.html
SIMPLIFICATION
Simple is a constantly mis-used term, in this entry I'm trying very hard to get clarify a definition of it. It's the sort of thing that programmers should really really understand, yet the kind of thing that they rarely do:
http://theprogrammersparadox.blogspot.com/2007/12/nature-of-simple.html
ABSTRACTION AND ENCAPSULATION
Most of the incoming searches from the web seem to find my abstraction and encapsulation writings. Again these pieces are focused around clearly defining these terms. The first entry references the other two, I threw in the fourth one because its also deals with more essential definitions:
http://theprogrammersparadox.blogspot.com/2008/01/abstraction-and-encapsulation.html
http://theprogrammersparadox.blogspot.com/2007/11/art-of-encapsulation.html
http://theprogrammersparadox.blogspot.com/2007/12/pedantically-speaking.html
http://theprogrammersparadox.blogspot.com/2008/01/construction-of-primitives.html
SOFTWARE DEVELOPMENT
I've been struggling for years with trying to find the right words to explain how to make it easier to develop software. Software development is a hard task, but people so often make it much much harder than it actually needs to be. More software fails at the root development level then it does from organizational problems. If it starts off poorly, it will fall apart quickly:
http://theprogrammersparadox.blogspot.com/2008/01/essential-develoment-problems.html
http://theprogrammersparadox.blogspot.com/2007/10/first-principles-and-beyond.html
http://theprogrammersparadox.blogspot.com/2008/05/software-blueprints.html
BLUEPRINTS
Another interesting post that got a fair amount of feedback. I think that a simplified high-level (but imprecise) way to specify functionality would go a long way in reducing risk and allowing programmers to learn from each other:
http://theprogrammersparadox.blogspot.com/2008/05/software-blueprints.html
TESTING
Coding is great, but as programmers we fill up our efforts with a steady stream of bugs. You haven't really mastered software development until you've mastered spending the least amount of effort to find the maximum number of bugs, which is not nearly as easy as it sounds:
http://theprogrammersparadox.blogspot.com/2008/03/testing-for-battleships.html
http://theprogrammersparadox.blogspot.com/2008/02/testing-perspectives.html
IN THE FUTURE
I did a couple of forward-looking posts about things up and coming in the future. Computer Science forces us to be able to understand knowledge in a new and more precise way than is necessary for most other disciplines:
http://theprogrammersparadox.blogspot.com/2008/02/age-of-clarity.html
http://theprogrammersparadox.blogspot.com/2008/03/science-of-information.html
http://theprogrammersparadox.blogspot.com/2008/12/lines-of-progress.html
BUILDING BLOCKS
These are some of my earlier writings. Similar to this blog, but often a little dryer. The whole repository can be found here:
http://www.lulu.com/content/1054566 (should be free to download)
Some of the better entries:
Rust and Bloat -- http://people.lulu.com/blogs/view_post.php?post_id=28963
Five Pillars -- http://people.lulu.com/blogs/view_post.php?post_id=35232
When Ideas become Products -- http://people.lulu.com/blogs/view_post.php?post_id=33933
THE BOOK -- THE PROGRAMMER'S PARADOX
This site is named after my first attempt at a book. I quite work and decided to push out all of my software development understanding onto paper. It was something I always wanted to do. I can't say that it is a good piece of work, but I can say that there is a lot there, it's just in a very raw form. It was my first big attempt at writing (besides research papers) and apart from a few typos, the printed edition looks and feels very much like a real book (my sister says so, and likes the quotes at the start of each chapter). Professional editing could bring it out, but I've never been able to convince any publishers that this 'type' of material should see the light of day. My advice, don't buy the book, convince a publisher to publish it instead (if you'd really like to read the book, send me an email and I'll send you a copy).
http://www.lulu.com/content/178872
RANTS AND RAVES
Sometimes the world drives me nuts, so I set up a place to vent. Some of the venting is horrible, but occasionally it's amusing:
http://irrationalfocus.blogspot.com/2008/06/seven-platitudes-of-highly-ineffectual.html
http://irrationalfocus.blogspot.com/2007/12/ho-ho-what-ho.html
http://irrationalfocus.blogspot.com/2008/02/edging-towards-third.html
GAMES PEOPLE PLAY
Andy Hunt suggested a long time ago that my writing was OK, but not entirely personal. He said I was delivering observations but not tying them back to the reader. As a sort of fun exercise I set myself the goal of writing just little thought-lets: two sentence expressions. The first sentence is completely general, an observation; while the second one must tie that back to the reader somehow. The earlier versions were on yahoo360:
http://ca.blog.360.yahoo.com/blog-jQ.RlBwherOgu.uuFz5qB.I1
but there is a full copy at:
http://idealeftovers.blogspot.com/2007/11/yahoo360-yahoo-360-rant-in-long-run.html
I've collected together my favorites with short intros, which I'll update from time to time to keep it up-to-date. Hopefully I can tag this in Blogger to make it standout.
If you're a long-time reader and I missed a favorite or two, please feel free to leave a comment. If I managed to get a few more suitable entries, I'll update this document. Comments for older pieces should be left on the original piece, Blogger will let me know that they are there.
NORMAL FORMS
Probably the most influential thing that I'll write in my career is the basis for code normalization, however I fully expect that the software development industry will happily choose to ignore any points in these works for at least another hundred or hundred and fifty years. Because of that, don't feel obligated to read any of these, they probably won't be relevant for quite a while:
http://theprogrammersparadox.blogspot.com/2008/11/code-normal-form.html
http://theprogrammersparadox.blogspot.com/2008/10/structure-of-elegance.html
http://theprogrammersparadox.blogspot.com/2008/10/revisiting-structure-of-elegance.html
SIMPLIFICATION
Simple is a constantly mis-used term, in this entry I'm trying very hard to get clarify a definition of it. It's the sort of thing that programmers should really really understand, yet the kind of thing that they rarely do:
http://theprogrammersparadox.blogspot.com/2007/12/nature-of-simple.html
ABSTRACTION AND ENCAPSULATION
Most of the incoming searches from the web seem to find my abstraction and encapsulation writings. Again these pieces are focused around clearly defining these terms. The first entry references the other two, I threw in the fourth one because its also deals with more essential definitions:
http://theprogrammersparadox.blogspot.com/2008/01/abstraction-and-encapsulation.html
http://theprogrammersparadox.blogspot.com/2007/11/art-of-encapsulation.html
http://theprogrammersparadox.blogspot.com/2007/12/pedantically-speaking.html
http://theprogrammersparadox.blogspot.com/2008/01/construction-of-primitives.html
SOFTWARE DEVELOPMENT
I've been struggling for years with trying to find the right words to explain how to make it easier to develop software. Software development is a hard task, but people so often make it much much harder than it actually needs to be. More software fails at the root development level then it does from organizational problems. If it starts off poorly, it will fall apart quickly:
http://theprogrammersparadox.blogspot.com/2008/01/essential-develoment-problems.html
http://theprogrammersparadox.blogspot.com/2007/10/first-principles-and-beyond.html
http://theprogrammersparadox.blogspot.com/2008/05/software-blueprints.html
BLUEPRINTS
Another interesting post that got a fair amount of feedback. I think that a simplified high-level (but imprecise) way to specify functionality would go a long way in reducing risk and allowing programmers to learn from each other:
http://theprogrammersparadox.blogspot.com/2008/05/software-blueprints.html
TESTING
Coding is great, but as programmers we fill up our efforts with a steady stream of bugs. You haven't really mastered software development until you've mastered spending the least amount of effort to find the maximum number of bugs, which is not nearly as easy as it sounds:
http://theprogrammersparadox.blogspot.com/2008/03/testing-for-battleships.html
http://theprogrammersparadox.blogspot.com/2008/02/testing-perspectives.html
IN THE FUTURE
I did a couple of forward-looking posts about things up and coming in the future. Computer Science forces us to be able to understand knowledge in a new and more precise way than is necessary for most other disciplines:
http://theprogrammersparadox.blogspot.com/2008/02/age-of-clarity.html
http://theprogrammersparadox.blogspot.com/2008/03/science-of-information.html
http://theprogrammersparadox.blogspot.com/2008/12/lines-of-progress.html
BUILDING BLOCKS
These are some of my earlier writings. Similar to this blog, but often a little dryer. The whole repository can be found here:
http://www.lulu.com/content/1054566 (should be free to download)
Some of the better entries:
Rust and Bloat -- http://people.lulu.com/blogs/view_post.php?post_id=28963
Five Pillars -- http://people.lulu.com/blogs/view_post.php?post_id=35232
When Ideas become Products -- http://people.lulu.com/blogs/view_post.php?post_id=33933
THE BOOK -- THE PROGRAMMER'S PARADOX
This site is named after my first attempt at a book. I quite work and decided to push out all of my software development understanding onto paper. It was something I always wanted to do. I can't say that it is a good piece of work, but I can say that there is a lot there, it's just in a very raw form. It was my first big attempt at writing (besides research papers) and apart from a few typos, the printed edition looks and feels very much like a real book (my sister says so, and likes the quotes at the start of each chapter). Professional editing could bring it out, but I've never been able to convince any publishers that this 'type' of material should see the light of day. My advice, don't buy the book, convince a publisher to publish it instead (if you'd really like to read the book, send me an email and I'll send you a copy).
http://www.lulu.com/content/178872
RANTS AND RAVES
Sometimes the world drives me nuts, so I set up a place to vent. Some of the venting is horrible, but occasionally it's amusing:
http://irrationalfocus.blogspot.com/2008/06/seven-platitudes-of-highly-ineffectual.html
http://irrationalfocus.blogspot.com/2007/12/ho-ho-what-ho.html
http://irrationalfocus.blogspot.com/2008/02/edging-towards-third.html
GAMES PEOPLE PLAY
Andy Hunt suggested a long time ago that my writing was OK, but not entirely personal. He said I was delivering observations but not tying them back to the reader. As a sort of fun exercise I set myself the goal of writing just little thought-lets: two sentence expressions. The first sentence is completely general, an observation; while the second one must tie that back to the reader somehow. The earlier versions were on yahoo360:
http://ca.blog.360.yahoo.com/blog-jQ.RlBwherOgu.uuFz5qB.I1
but there is a full copy at:
http://idealeftovers.blogspot.com/2007/11/yahoo360-yahoo-360-rant-in-long-run.html
Wednesday, December 3, 2008
The Lines of Progress
Some posts come easily, this one however was a struggle. Life it seems, conspires to keep us occupied making it hard sometimes to find long periods for focusing. And it's an age thing too, I think. One friend of mine believes that thirty is the age cut-off for great inventors, but I tend to favor the idea that our responsibilities grow as we age, along with our expectations. Often the combination far exceeds our abilities. Whichever way, sometimes it makes it hard to get any writing done.
Without bemoaning fate, in this entry I want to show why Computer Science, as well as many of mans other endeavors, suffers so horribly from our fuzzy perceptions of the world around us. It's as if we are walking through a fog with blinders on. The things that underpin our knowledge are often so much weaker than we know or really want to believe, yet until we can accept our knowledge as it is, we cannot fix our understandings. We'll just stay trapped in a world of both abundant truth and falsity that often balance each other out.
I'm sure that most people see our modern knowledge as extensive and nearly complete, we as a species often have a strange faith that somebody somewhere entirely gets it, even if we are personally no longer able to keep up. That might be the case for some limited branches of knowledge, but it has become increasingly clear that the sum of our understandings easily exceeds even the best and the brightest minds of our time. We collectively know way more than any individual can assimilate. And this overall amount of knowledge is increasing at a rapid pace.
It's in exactly this growth that the real dangers lie. Each new leap is becoming increasingly dependent on what preceded it, and increasingly likely to be built on some falsehoods, even if they are subtle and unintentional. This isn't a problem that just effects a specific domain. It winds it way through all of the sciences, no matter how rigorous our efforts.
We build on a house of cards, which often comes to light when we try to organize our understanding, or if we try to automate it in some way. The details reveal our weaknesses.
It starts close to the very roots of our knowledge. Mathematics is our highest abstract, theoretically pure system, far removed from the real world. It sits at the top of all of our knowledge. Below that, science is how we rationalize the world around us. It takes the real world and tries to make sense of it. Computer Science which sits in that shadowy middle ground between these two, ties elements of the real world to some type of theoretical foundation. Running code is theoretically pure mathematics, what it is calculating is not.
It's because of this positioning that software development is one of the few occupations that demands that its practitioners must be able to learn and understand the other disciplines. Software developers are frequently interlopers into other bodies of knowledge. We are free to delve into the details of other knowledge bases, in fact we have no choice, we must learn from their details in order to complete our own efforts.
Because we build on the other disciplines, we delve deep into their information. But so often, as we try to map this back towards our own purely logical systems, we confront all of the irrational inconsistencies that have been ignored and accepted as conventions. Knowledge in a textbook can lightly skip over a few dubious facts, but once in a computer these issues become glaring problems.
AN ANCIENT PERSPECTIVE
As we age, we trade our inexperience for a diminished focus. We may know more but we have less opportunity to change things, mostly because of our own priorities. It's not that we don't rise to positions of power, but rather that the limitless energy and enthusiasm of youth quietly disappears over time. We're higher in authority, but we choose to do less.
In experiencing this knowledge verses energy trade-off I can't help but think about all of the things that I've learned over the years that are slowly fading away. It's the natural consequence of aging that we start forgetting twenty year old details. This makes me realize the fragility of everything I understand. The details fade, but I retain the patterns; the justifications disappear but I remember the results. Learning fades first at the details, then spreads upwards.
Our knowledge is built on a foundation. In our modern age we have increasingly become more rigorous in studying and proving our advances, but that rigor is tightly focused. What we learn from scientific methods is combined with what we understand from the world around us. The melding of our theoretical and empirical understandings, which is necessary because we have to allow for the messiness of the real world, opens up a gaping hole whereby the underlying absoluteness of our understanding can become tainted. What might be perfect in a research paper, can become suspect as it reaches practice. What we know, even if it is based around islands of proof, is not nearly as correct as we believe.
To really understand this perspective, you have to set yourself in the position of an academic scholar several hundred years ago. Pick a time when it was easily possible to have a nearly complete and full understanding of all things known to mankind. If you studied long and hard enough you would reach a point where you knew all that there was to know, yet from our modern perspective you knew just a proverbial drop in the bucket.
Yes, you understood geometry, philosophy and farming, and the patterns of the stars and the moon and whatnot, but electricity, engines, flight and computers would all be pure magic. Our modern chemical based lifestyle with it's vast array of foods and materials would seem to be predicated on a mass of unknown information.
Information that would exceed a man's lifespan to learn. So much more detail than one could fill up on. It's not the differences in technology that are so stunning, or the increases in basic issues like human rights and fairness. No, rather it's that we have progressed from a time where a person might have understood most things, to a time where we can barely even keep up with all of the details of our own field, let alone the explosion of science and knowledge that are raining down on us.
As an ancient scholar we could probably cope with the concept of a car, and possibly the highway system. What might be more difficult are the actual details of a gas powered internal combustion engine. The things that are similar to what we observe, we have to accept, but we may choose to explain the underlying details with some other, more convenient explanation.
If you can set yourself back to that ancient time, then you might also be able to set yourself forward about the same distance.
Although to many it may feel like our modern society has opened all of the major doors to most branches of knowledge, there is still much to learn. As an ancient scholar we were equally confident of the fullness of our knowledge, but look how vastly we were mistaken. There is a huge amount we didn't know, just waiting for us. Cars, flight, and chemistry for instance.
In a sense we are probably only halfway between that old ancient knowledge, and the new future knowledge that we are still left to discover. There is as much waiting for us to learn as there was for the ancient scholar if he was in our time. We know a lot, but really we know so little.
HANGING LAUNDRY
I was buried deep in the functionality of a software program recently trying to get a sense of how it was working. It was old, maybe twenty or thirty years -- ancient by software standards -- and it's behavior was not as expected.
There was something wrong with the underlying algorithms, something pointing to code that was far cruder than anyone would have initially guessed. There are a lot of known algorithms, but this code wasn't matching any of them.
But then to some degree that is a common problem in software. Dig in something deep enough and you'll always find a programmer winging out a crude version of some known algorithm. Worse, sometimes that coder isn't actually a Computer Scientist, but a domain based expert that has moved in coding. There may be a multitude of better, faster, more accurate algorithms, but the one used forever in production is lame.
I can't even say anymore how many times I've been digging into the details, only to find a significant collection of systematic yet long-time accepted mistakes underpinning some well-known software. It's far too common.
It doesn't really matter the industry either, from round-off errors in finance, to printing errors in marketing, to calculation errors in scientific code, to threading errors in development products. The software we produce has a significant number of problems. Some known, some just ignored.
Often it's not even the software's fault. Not actually a bug per say. I can remember one financial product where the convention for a summary statistic was based around an entrenched hardware bug. The bug, extremely well-known, became the basis for the industry convention. A not entirely odd occurrence where an industry bent towards the irrationality of its history. It's always been that way, so why change it?
But it's exactly that digging over the years in so many different industries that has open up the door to my seeing the foundations of our real understanding. Or at least into accepting that most of what we're currently doing is guessing. I keep drilling down into the details, only to find that the details are wrong. Incorrect. Broken. Never by a huge amount, but almost always by something.
But whenever I've push this back up, the various industries are almost always aware of these errors. Small enough to be ignored, big enough to be significant.
Digging into any domain when building software, always involves digging into some industry's dirty laundry.
THE CRACKS THAT BIND US
If you sit on the fence between purity and reality, you quickly find that the cleanness and elegance of abstract mathematics holds an allure, a fascinating smooth, clean black and white philosophy for the world around us. Of course, it's completely untrue, the real world is a messy grey place with many more in-betweens than we want, but that region on the border easily high lights the differences.
Whenever my desire for perfection in the real world becomes to strong, I always fall back on my understanding of sidewalks.
In my neighborhood, at the top of the street the sidewalk has a huge crack running through it. The ground probably shifted sometime after the concrete was laid. Although this bit of reality in many ways is an ugly blight, that particularly sidewalk hosts a large number of people, going back and forth on a daily basis.
Everyday a large number of people walk by. And rarely, if no more than any other place, does someone trip on the crack. For it seems that however un-perfect the crack, it does not in most ways diminish the usefulness or working life of the sidewalk. It continues to serve a purpose, cracked or not.
When I've looked back at the software problems, although the errors get out there, the industries themselves just tend to route around them. That is, they become known, accepted, then move into being the convention. Often people just take that knowledge as if it were somehow absolutely true and undeniable.
BUGS THAT DON'T BITE
My understand of the sidewalk, always reminds me that much of what we have or need in this world does not have to be perfect. Of course, because I've seen software working for decades, pinned on incorrect calculations, or serious bugs, that have been worked around. Computers crash, software generates bad numbers, hardware burns out, and yet all things continue to exist. We live in a world, were our reality tolerates a considerable amount of incorrect data, flaws and disasters.
But that is exactly the key towards looking toward our future. The details in our knowledge, are immense, but they are filled with as many old wives tales, myths, mis-believes, lies, spin, half truths, and other assorted bits of incorrect, or nearly incorrect bits of knowledge. Even when we are sure that the things underneath are solid, it is not uncommon to dig deep enough and find serious mistakes.
Consider our earlier perspective of an ancient scholar drifting through life with the full complement of man's knowledge. Now, with the exception of man-made items, we as this scholar knew of as many things visible in this world, as people do now. Yet for all of these things, say perhaps lightning, while the sense was the same -- we can see and hear it -- the underlying explanation was completely different.
Since electricity was unknown, static electricity was too. Thus, there was some other theory attached to lightning to explain it, and in our studies we were taught these ideas. Doesn't really matter what we was taught, but it does matter that as time wore on, these explanation grew and grew more correct, probably by leaps and bounds, until it came to match the modern explanation for lightning. Lightning always existed, but much like a plant, the explanation for it has been morphing and growing all of these centuries, gradually working its way down farther into the depths of the details.
In a sense, if knowledge isn't get broader at least not at this moment, it certainly is getting deeper. Much deeper. But even with that trend, everyone can see lightning, and most people can explain simple elements of it, but how many really understand it?
OPENING THE FLOODGATES
My sense from exploring the other industries has always been that they each have their serious cracks. That the knowledge we know is vast, yet messy and incomplete, and more importantly filled with tonnes of misdirection.
Yes, we've learned how to be rigorous with some of the smaller details, some of the process, but we have no idea how to assemble this knowledge in a rigorous manner. We can collect the knowledge, interpret parts of it, but we cannot stitch it together.
Computers, while being great tools are also great at showing us our obvious flaws in what we understand. Software isn't hard in concept, but the messiness of our real world understanding makes it horribly difficult. System fail because people grossly mis-estimate the complexity. Complexity that stems from inconsistencies and misunderstandings.
And its in automating our efforts that we reveal the problems. Only a programmer really needs to understand how the calculations for financial instruments work for example. They are so messy and often incorrect. The financial industry has lots of quick cheats and rules of thumb for partially accurate calculation. That's all that is needed to start trading them. It's only at the deepest level of detail where you have to agonize over the tiniest of points, that you really start to see the holes.
Yes, we do know a lot, but we need a way to organize and contain that knowledge. It no longer fits in someone's head. We can't utilize what we know because we don't know how to connect the dots, to bring it all together into something coherent.
Really, if we did we could build one big massive all inclusive database, containing all of man's known facts. Yet while that idea is easy to write down in a blog post, nothing we have in the way of technology can do this. The best we can do is a great pyramid inspired scheme to throw massive manpower at it. We can create something like wikipedia which may seem impressive, but it's not our knowledge that allowed this to happen, it's our vast numbers that we're utilizing.
BACK TO THE FUTURE
In many ways it's easy to predict the our future. It is, after all, something that Computer Science will have to achieve one day in order to progress into a real science or perhaps engineering. To make things work we must follow an obvious path.
We will have to learn the structure of data and we will have to learn how to combine it together. We will have to learn how to sort out the truth, the real stuff, from the masses of mis-information that are swarming all over.
If in the past we saw a trend where our information was getting broader over time -- spanning out -- then in the future, it will be getting deeper. We know the categories, we just need to understand the details.
We won't just guess at what we know, we won't just optimistically collect it in little bits, hoping to find it useful later. We'll know we need it, and what to do with it.
I could always hope that we'll get there soon, but the truth about mankind is that it doesn't really like progress. Sure, we've become addicted to little fiddly electronics like iPod, and other toys, but while the advancement of these beads have gone at breakneck speeds throughout my lifetime, the really big leaps have been far slower. We shouldn't get the consequences of a few major jumps confused with the jumps themselves.
Of course we have more people with more effort, but those population advances have not been radically outpaced by our technological innovations. And we're easily lead astray. It's not surprising for example, to find that whole generations can succumb to easily ideas like Freud. We, as a species bend towards the static and easy. Perhaps when we are younger we have the strength and energy to change the world, but time wears us down.
Our next great leaps will come from our dropping the notion that thinking itself is somehow magical; that knowledge mysteriously appears out of nowhere. We've learned to organize physical labor, to control factories, yet we are careful never to apply these industrial ideas to our thinking in other areas. Why?
Oddly, software development, which interacts with so many other disciplines is the one that has been the most active in trying to stay far away from any attempt to organize our approaches to mental effort. Programmers despise order, organization and methodology.
The very things that we know we'll need in the future are the things that scare us most in the present. And it's not like another discipline will find the answer first, software development is the platform on which all of the others now rely. As we guess, and hack, and flail at our keyboard, they follow our examples with their own development. The limits of software now drive research and development.
That it seems may actually be a possible explanation for the high degree of systematic mistakes that pollute our technologies. Domain experts go at building their specific code in the same reckless manner that Computer Scientists have applied to their discipline for decades.
STILL HAVEN'T FOUND WHAT WE'VE AVOIDING
The things that we need to get to the next step are simple. We have the puzzle pieces, but we need to know what to do with them. We have a little bit of depth, but we need to perfect it, rather than just wrap it in more complexity.
We need to be able to put structure to our data, in a way that we know, not guess, but know that it is correct. Data forms the heart of our knowledge and while its still collected randomly with no provable basis for its structure, it is little more than useless. We have lots of it, but we can't combine it easily and we certainly can't mine it for anything other than trivial known relationships. We talk bravely about exploiting it, but you can't dig a mine in a tar pit.
We need to normalize our code and change our practices to stop wrapping the older crappy stuff. You can't build a technological base on mistakes and rampant complexity. You can't just endless whack out new code in the hopes that someday it will accidentally be the right stuff. Elegance is not a dream and it's not unachievable. We need and can have beautiful code, not as a means for itself, but as the only way to build a foundation stable enough that we can actually leverage it to really increase our knowledge. We need to know, what we know, and know how to know more of it.
We need to take the knowledge the we acquire in building today's systems, and apply it to tomorrow's. We need to capture our understandings so that we can extend them, not just restart each time with a new technology. Just as industrialization transformed factories, we now need it in our technologies. Software, of all the known industries is the worst here. We're polarized between ideas based around dysfunctional decades old large-scale manufacturing, that are too static and too large to work properly, and ideas based around cutesy fun game-like processes that are oriented more on being popular (to increase book and training sales) and less on actually being functional or improving the process. Old school dysfunction vs new school irresponsibility.
Still for all we need these things, they are absolutely not what people want, or our looking for. We've continually chosen the opposite, the fast food concept of knowledge, gorging steadily until we're ready to burst.
Judging from interest, programmers don't want blueprints, they don't want to be able to normalize their code, and they really don't want a methodology that works. They'd much rather go into work and wing it, making wild often incorrect guesses than spend the effort to figure out how to really make it work. Even when they have techniques like database normalization, they'd rather just whip it together on their own, basing their designs on instinct and hunches.
The state of the industry is that most projects fail because most programmers would rather that outcome than change their ways. In a couple of decades we've barely improved from a 15% success rate to a 30% success rate. That says a lot.
The web, of course, documents this. There's far more gossip and fanboy posting than there are fair and honest discussions of a technical nature. And those in the online community themselves, are only a small fraction of the currently practicing software industry. Most programmers stay far away from talking about programming. The industry wants to know what magical lines are required to fix a problem, but they don't want to know why they are required, or even whether or not the issue should be fixed.
FINAL THOUGHTS
We live in a age where every week you can read about a new scientific break-through study that supposedly changes the way we should think about something. But if you read a bit deeper you'll find that some of these studies, often it feels like more than half of them, are sitting on very dubious foundations. They make it to the news not based on their truth, but rather on their news worthiness. That is, they are entertaining enough to make it to the papers.
That might be OK if these questionable efforts where to disappear, but we're steady filling our knowledge banks with as much bad information as we are filling it with good. The world of infomercials has overflowed from our TVs and right into our research and development. The information age has promoted a kind of madness where rigor appears everywhere, and nowhere all at once. Who care what we know, if it's so padded with crap that we don't know what's true or not anymore. Proper marketing techniques are replacing proper critical thinking ones; grant money, after all, has become more important than progress.
In our future -- distance or not, that's our choice -- we'll eventually find the intellectual tools to quickly sort out the underlying truthfulness of what we know. We have to, as we are quickly being swamped by masses of questionable information. This circumstance cannot continue forever. One day people will look back on these as the dark ages, an information explosion perhaps, but one where we we flooded with propaganda and lies.
Without bemoaning fate, in this entry I want to show why Computer Science, as well as many of mans other endeavors, suffers so horribly from our fuzzy perceptions of the world around us. It's as if we are walking through a fog with blinders on. The things that underpin our knowledge are often so much weaker than we know or really want to believe, yet until we can accept our knowledge as it is, we cannot fix our understandings. We'll just stay trapped in a world of both abundant truth and falsity that often balance each other out.
I'm sure that most people see our modern knowledge as extensive and nearly complete, we as a species often have a strange faith that somebody somewhere entirely gets it, even if we are personally no longer able to keep up. That might be the case for some limited branches of knowledge, but it has become increasingly clear that the sum of our understandings easily exceeds even the best and the brightest minds of our time. We collectively know way more than any individual can assimilate. And this overall amount of knowledge is increasing at a rapid pace.
It's in exactly this growth that the real dangers lie. Each new leap is becoming increasingly dependent on what preceded it, and increasingly likely to be built on some falsehoods, even if they are subtle and unintentional. This isn't a problem that just effects a specific domain. It winds it way through all of the sciences, no matter how rigorous our efforts.
We build on a house of cards, which often comes to light when we try to organize our understanding, or if we try to automate it in some way. The details reveal our weaknesses.
It starts close to the very roots of our knowledge. Mathematics is our highest abstract, theoretically pure system, far removed from the real world. It sits at the top of all of our knowledge. Below that, science is how we rationalize the world around us. It takes the real world and tries to make sense of it. Computer Science which sits in that shadowy middle ground between these two, ties elements of the real world to some type of theoretical foundation. Running code is theoretically pure mathematics, what it is calculating is not.
It's because of this positioning that software development is one of the few occupations that demands that its practitioners must be able to learn and understand the other disciplines. Software developers are frequently interlopers into other bodies of knowledge. We are free to delve into the details of other knowledge bases, in fact we have no choice, we must learn from their details in order to complete our own efforts.
Because we build on the other disciplines, we delve deep into their information. But so often, as we try to map this back towards our own purely logical systems, we confront all of the irrational inconsistencies that have been ignored and accepted as conventions. Knowledge in a textbook can lightly skip over a few dubious facts, but once in a computer these issues become glaring problems.
AN ANCIENT PERSPECTIVE
As we age, we trade our inexperience for a diminished focus. We may know more but we have less opportunity to change things, mostly because of our own priorities. It's not that we don't rise to positions of power, but rather that the limitless energy and enthusiasm of youth quietly disappears over time. We're higher in authority, but we choose to do less.
In experiencing this knowledge verses energy trade-off I can't help but think about all of the things that I've learned over the years that are slowly fading away. It's the natural consequence of aging that we start forgetting twenty year old details. This makes me realize the fragility of everything I understand. The details fade, but I retain the patterns; the justifications disappear but I remember the results. Learning fades first at the details, then spreads upwards.
Our knowledge is built on a foundation. In our modern age we have increasingly become more rigorous in studying and proving our advances, but that rigor is tightly focused. What we learn from scientific methods is combined with what we understand from the world around us. The melding of our theoretical and empirical understandings, which is necessary because we have to allow for the messiness of the real world, opens up a gaping hole whereby the underlying absoluteness of our understanding can become tainted. What might be perfect in a research paper, can become suspect as it reaches practice. What we know, even if it is based around islands of proof, is not nearly as correct as we believe.
To really understand this perspective, you have to set yourself in the position of an academic scholar several hundred years ago. Pick a time when it was easily possible to have a nearly complete and full understanding of all things known to mankind. If you studied long and hard enough you would reach a point where you knew all that there was to know, yet from our modern perspective you knew just a proverbial drop in the bucket.
Yes, you understood geometry, philosophy and farming, and the patterns of the stars and the moon and whatnot, but electricity, engines, flight and computers would all be pure magic. Our modern chemical based lifestyle with it's vast array of foods and materials would seem to be predicated on a mass of unknown information.
Information that would exceed a man's lifespan to learn. So much more detail than one could fill up on. It's not the differences in technology that are so stunning, or the increases in basic issues like human rights and fairness. No, rather it's that we have progressed from a time where a person might have understood most things, to a time where we can barely even keep up with all of the details of our own field, let alone the explosion of science and knowledge that are raining down on us.
As an ancient scholar we could probably cope with the concept of a car, and possibly the highway system. What might be more difficult are the actual details of a gas powered internal combustion engine. The things that are similar to what we observe, we have to accept, but we may choose to explain the underlying details with some other, more convenient explanation.
If you can set yourself back to that ancient time, then you might also be able to set yourself forward about the same distance.
Although to many it may feel like our modern society has opened all of the major doors to most branches of knowledge, there is still much to learn. As an ancient scholar we were equally confident of the fullness of our knowledge, but look how vastly we were mistaken. There is a huge amount we didn't know, just waiting for us. Cars, flight, and chemistry for instance.
In a sense we are probably only halfway between that old ancient knowledge, and the new future knowledge that we are still left to discover. There is as much waiting for us to learn as there was for the ancient scholar if he was in our time. We know a lot, but really we know so little.
HANGING LAUNDRY
I was buried deep in the functionality of a software program recently trying to get a sense of how it was working. It was old, maybe twenty or thirty years -- ancient by software standards -- and it's behavior was not as expected.
There was something wrong with the underlying algorithms, something pointing to code that was far cruder than anyone would have initially guessed. There are a lot of known algorithms, but this code wasn't matching any of them.
But then to some degree that is a common problem in software. Dig in something deep enough and you'll always find a programmer winging out a crude version of some known algorithm. Worse, sometimes that coder isn't actually a Computer Scientist, but a domain based expert that has moved in coding. There may be a multitude of better, faster, more accurate algorithms, but the one used forever in production is lame.
I can't even say anymore how many times I've been digging into the details, only to find a significant collection of systematic yet long-time accepted mistakes underpinning some well-known software. It's far too common.
It doesn't really matter the industry either, from round-off errors in finance, to printing errors in marketing, to calculation errors in scientific code, to threading errors in development products. The software we produce has a significant number of problems. Some known, some just ignored.
Often it's not even the software's fault. Not actually a bug per say. I can remember one financial product where the convention for a summary statistic was based around an entrenched hardware bug. The bug, extremely well-known, became the basis for the industry convention. A not entirely odd occurrence where an industry bent towards the irrationality of its history. It's always been that way, so why change it?
But it's exactly that digging over the years in so many different industries that has open up the door to my seeing the foundations of our real understanding. Or at least into accepting that most of what we're currently doing is guessing. I keep drilling down into the details, only to find that the details are wrong. Incorrect. Broken. Never by a huge amount, but almost always by something.
But whenever I've push this back up, the various industries are almost always aware of these errors. Small enough to be ignored, big enough to be significant.
Digging into any domain when building software, always involves digging into some industry's dirty laundry.
THE CRACKS THAT BIND US
If you sit on the fence between purity and reality, you quickly find that the cleanness and elegance of abstract mathematics holds an allure, a fascinating smooth, clean black and white philosophy for the world around us. Of course, it's completely untrue, the real world is a messy grey place with many more in-betweens than we want, but that region on the border easily high lights the differences.
Whenever my desire for perfection in the real world becomes to strong, I always fall back on my understanding of sidewalks.
In my neighborhood, at the top of the street the sidewalk has a huge crack running through it. The ground probably shifted sometime after the concrete was laid. Although this bit of reality in many ways is an ugly blight, that particularly sidewalk hosts a large number of people, going back and forth on a daily basis.
Everyday a large number of people walk by. And rarely, if no more than any other place, does someone trip on the crack. For it seems that however un-perfect the crack, it does not in most ways diminish the usefulness or working life of the sidewalk. It continues to serve a purpose, cracked or not.
When I've looked back at the software problems, although the errors get out there, the industries themselves just tend to route around them. That is, they become known, accepted, then move into being the convention. Often people just take that knowledge as if it were somehow absolutely true and undeniable.
BUGS THAT DON'T BITE
My understand of the sidewalk, always reminds me that much of what we have or need in this world does not have to be perfect. Of course, because I've seen software working for decades, pinned on incorrect calculations, or serious bugs, that have been worked around. Computers crash, software generates bad numbers, hardware burns out, and yet all things continue to exist. We live in a world, were our reality tolerates a considerable amount of incorrect data, flaws and disasters.
But that is exactly the key towards looking toward our future. The details in our knowledge, are immense, but they are filled with as many old wives tales, myths, mis-believes, lies, spin, half truths, and other assorted bits of incorrect, or nearly incorrect bits of knowledge. Even when we are sure that the things underneath are solid, it is not uncommon to dig deep enough and find serious mistakes.
Consider our earlier perspective of an ancient scholar drifting through life with the full complement of man's knowledge. Now, with the exception of man-made items, we as this scholar knew of as many things visible in this world, as people do now. Yet for all of these things, say perhaps lightning, while the sense was the same -- we can see and hear it -- the underlying explanation was completely different.
Since electricity was unknown, static electricity was too. Thus, there was some other theory attached to lightning to explain it, and in our studies we were taught these ideas. Doesn't really matter what we was taught, but it does matter that as time wore on, these explanation grew and grew more correct, probably by leaps and bounds, until it came to match the modern explanation for lightning. Lightning always existed, but much like a plant, the explanation for it has been morphing and growing all of these centuries, gradually working its way down farther into the depths of the details.
In a sense, if knowledge isn't get broader at least not at this moment, it certainly is getting deeper. Much deeper. But even with that trend, everyone can see lightning, and most people can explain simple elements of it, but how many really understand it?
OPENING THE FLOODGATES
My sense from exploring the other industries has always been that they each have their serious cracks. That the knowledge we know is vast, yet messy and incomplete, and more importantly filled with tonnes of misdirection.
Yes, we've learned how to be rigorous with some of the smaller details, some of the process, but we have no idea how to assemble this knowledge in a rigorous manner. We can collect the knowledge, interpret parts of it, but we cannot stitch it together.
Computers, while being great tools are also great at showing us our obvious flaws in what we understand. Software isn't hard in concept, but the messiness of our real world understanding makes it horribly difficult. System fail because people grossly mis-estimate the complexity. Complexity that stems from inconsistencies and misunderstandings.
And its in automating our efforts that we reveal the problems. Only a programmer really needs to understand how the calculations for financial instruments work for example. They are so messy and often incorrect. The financial industry has lots of quick cheats and rules of thumb for partially accurate calculation. That's all that is needed to start trading them. It's only at the deepest level of detail where you have to agonize over the tiniest of points, that you really start to see the holes.
Yes, we do know a lot, but we need a way to organize and contain that knowledge. It no longer fits in someone's head. We can't utilize what we know because we don't know how to connect the dots, to bring it all together into something coherent.
Really, if we did we could build one big massive all inclusive database, containing all of man's known facts. Yet while that idea is easy to write down in a blog post, nothing we have in the way of technology can do this. The best we can do is a great pyramid inspired scheme to throw massive manpower at it. We can create something like wikipedia which may seem impressive, but it's not our knowledge that allowed this to happen, it's our vast numbers that we're utilizing.
BACK TO THE FUTURE
In many ways it's easy to predict the our future. It is, after all, something that Computer Science will have to achieve one day in order to progress into a real science or perhaps engineering. To make things work we must follow an obvious path.
We will have to learn the structure of data and we will have to learn how to combine it together. We will have to learn how to sort out the truth, the real stuff, from the masses of mis-information that are swarming all over.
If in the past we saw a trend where our information was getting broader over time -- spanning out -- then in the future, it will be getting deeper. We know the categories, we just need to understand the details.
We won't just guess at what we know, we won't just optimistically collect it in little bits, hoping to find it useful later. We'll know we need it, and what to do with it.
I could always hope that we'll get there soon, but the truth about mankind is that it doesn't really like progress. Sure, we've become addicted to little fiddly electronics like iPod, and other toys, but while the advancement of these beads have gone at breakneck speeds throughout my lifetime, the really big leaps have been far slower. We shouldn't get the consequences of a few major jumps confused with the jumps themselves.
Of course we have more people with more effort, but those population advances have not been radically outpaced by our technological innovations. And we're easily lead astray. It's not surprising for example, to find that whole generations can succumb to easily ideas like Freud. We, as a species bend towards the static and easy. Perhaps when we are younger we have the strength and energy to change the world, but time wears us down.
Our next great leaps will come from our dropping the notion that thinking itself is somehow magical; that knowledge mysteriously appears out of nowhere. We've learned to organize physical labor, to control factories, yet we are careful never to apply these industrial ideas to our thinking in other areas. Why?
Oddly, software development, which interacts with so many other disciplines is the one that has been the most active in trying to stay far away from any attempt to organize our approaches to mental effort. Programmers despise order, organization and methodology.
The very things that we know we'll need in the future are the things that scare us most in the present. And it's not like another discipline will find the answer first, software development is the platform on which all of the others now rely. As we guess, and hack, and flail at our keyboard, they follow our examples with their own development. The limits of software now drive research and development.
That it seems may actually be a possible explanation for the high degree of systematic mistakes that pollute our technologies. Domain experts go at building their specific code in the same reckless manner that Computer Scientists have applied to their discipline for decades.
STILL HAVEN'T FOUND WHAT WE'VE AVOIDING
The things that we need to get to the next step are simple. We have the puzzle pieces, but we need to know what to do with them. We have a little bit of depth, but we need to perfect it, rather than just wrap it in more complexity.
We need to be able to put structure to our data, in a way that we know, not guess, but know that it is correct. Data forms the heart of our knowledge and while its still collected randomly with no provable basis for its structure, it is little more than useless. We have lots of it, but we can't combine it easily and we certainly can't mine it for anything other than trivial known relationships. We talk bravely about exploiting it, but you can't dig a mine in a tar pit.
We need to normalize our code and change our practices to stop wrapping the older crappy stuff. You can't build a technological base on mistakes and rampant complexity. You can't just endless whack out new code in the hopes that someday it will accidentally be the right stuff. Elegance is not a dream and it's not unachievable. We need and can have beautiful code, not as a means for itself, but as the only way to build a foundation stable enough that we can actually leverage it to really increase our knowledge. We need to know, what we know, and know how to know more of it.
We need to take the knowledge the we acquire in building today's systems, and apply it to tomorrow's. We need to capture our understandings so that we can extend them, not just restart each time with a new technology. Just as industrialization transformed factories, we now need it in our technologies. Software, of all the known industries is the worst here. We're polarized between ideas based around dysfunctional decades old large-scale manufacturing, that are too static and too large to work properly, and ideas based around cutesy fun game-like processes that are oriented more on being popular (to increase book and training sales) and less on actually being functional or improving the process. Old school dysfunction vs new school irresponsibility.
Still for all we need these things, they are absolutely not what people want, or our looking for. We've continually chosen the opposite, the fast food concept of knowledge, gorging steadily until we're ready to burst.
Judging from interest, programmers don't want blueprints, they don't want to be able to normalize their code, and they really don't want a methodology that works. They'd much rather go into work and wing it, making wild often incorrect guesses than spend the effort to figure out how to really make it work. Even when they have techniques like database normalization, they'd rather just whip it together on their own, basing their designs on instinct and hunches.
The state of the industry is that most projects fail because most programmers would rather that outcome than change their ways. In a couple of decades we've barely improved from a 15% success rate to a 30% success rate. That says a lot.
The web, of course, documents this. There's far more gossip and fanboy posting than there are fair and honest discussions of a technical nature. And those in the online community themselves, are only a small fraction of the currently practicing software industry. Most programmers stay far away from talking about programming. The industry wants to know what magical lines are required to fix a problem, but they don't want to know why they are required, or even whether or not the issue should be fixed.
FINAL THOUGHTS
We live in a age where every week you can read about a new scientific break-through study that supposedly changes the way we should think about something. But if you read a bit deeper you'll find that some of these studies, often it feels like more than half of them, are sitting on very dubious foundations. They make it to the news not based on their truth, but rather on their news worthiness. That is, they are entertaining enough to make it to the papers.
That might be OK if these questionable efforts where to disappear, but we're steady filling our knowledge banks with as much bad information as we are filling it with good. The world of infomercials has overflowed from our TVs and right into our research and development. The information age has promoted a kind of madness where rigor appears everywhere, and nowhere all at once. Who care what we know, if it's so padded with crap that we don't know what's true or not anymore. Proper marketing techniques are replacing proper critical thinking ones; grant money, after all, has become more important than progress.
In our future -- distance or not, that's our choice -- we'll eventually find the intellectual tools to quickly sort out the underlying truthfulness of what we know. We have to, as we are quickly being swamped by masses of questionable information. This circumstance cannot continue forever. One day people will look back on these as the dark ages, an information explosion perhaps, but one where we we flooded with propaganda and lies.
Subscribe to:
Posts (Atom)