Fog Creek Software
Discussion Board

How not to make a mess of it

From many recent topics one could conclude that good software could be done provided we had enough money, people, time, patience, skills, you name it. But there's a possibility that we simply don't know (yet) "HOW NOT TO MAKE A MESS OF IT" (although there are partial results, valid in any methodology, like "avoid case analyses", "separate concerns", "avoid operational thinking", "do not call bug a bug, call it an error", etc.). This possibility is articulated in EWD1304, for example, from which I would like to quote in extenso:

"In academia, in industry, and in the commercial world, there is a widespread belief that Computing Science as such has been all but completed and that, consequently, computing has "matured" from a theoretical topic for the scientists to a practical issue for the engineers, the managers and the entrepreneurs (...). This widespread belief, however, is only correct if we identify the goals of Computing Science with what has been accomplished and forget those goals that we failed to reach, even if they are too important to be ignored.

"I would therefore like to posit that computing's central challenge, viz. "How not to make a mess of it", has _not_ been met. On the contrary, most of our systems are much more coplicated that can be considered healthy, and are too messy and chaotic to be used in comfort and confidence. The average customer is served so poorly that he expects his system to crash all the time, and we witness a massive world-wide distribution of bug-ridden software for which we should be deeply ashamed.

"For us scientists it is very tempting to blame the lack of education of the average engineer, the short-sightedness of the managers and the malice of the entrepreneurs for this sorry state of affairs, but it won't do. You see, while we all know that unmastered complexity is at the root of the misery, we don't know what degree of simplicity can be obtained, nor to what extent the intrinsic complexity of the whole design has to show up in the interfaces. We simply do not know yet the limits of disentanglement. We do not know yet whether intrinsic intricacy can be distinguished from accidental intricacy. We do not know yet whether trade-offs will be possible. We do not know yet whether we can invent for intricacy a meaningful concept about which we can prove theorems that help. (...)

(end of quotation)
(see also EWD1305 for further arguments)

If such is the case (as I tend to believe, otherwise we wouldn't discuss the problem twice a week since the advent of programmable computers), then the term "Software Engineering" is of premature use, and truly stands for, as one put it, "how to program if you cannot".

No amount of programming languages, tools, tips or paradigms can hide the fact that the programming itself is not mastered yet. Budget, time and brilliant people can achieve amazing results, but these do not turn into a teacheable discipline.

(EWD's are available from http:// ).

Andrzej Kocon
Tuesday, July 2, 2002

I love Dijkstra's work.  He rejects the term "software engineering" because of "testing" as a means to find bugs instead of formal proofs.

Personally, I don't believe any progress will be made towards not making a mess of it... until:

1) People, managers and developers stop worshiping complexity as a virtue, and
2) Recognize complexity for what it is - a relationship between system and observer - not as a measurable attribute or property of a system (as they wish it were).

Unfortunately, folk wisdom has too many people not dealing with either of these.  I think it has to do with pretending the observer (e.g. yourself) has nothing to do with complexity - it's easier to blame the system.

Joe AA.
Tuesday, July 2, 2002

Great points by both prior posters.  There is one ingredient that is often present when you see a quality piece of software: Continuity.  Continuity of teams, management, expertise in the problem space, etc.

When a team grows slowly, there is a natual settling of human elements.  Those that are natural followers, follow, those that have a strong vision get into a position to project that vision.  The poor programmer doesn't get assigned "mission critical" tasks.

This all takes time, sometimes quite a lot.  But, the problems solved by it are immesurable.  People have too many axis to be able to quantify their abilities without working with them for a period of time.

A "senior engineer" may be great at writing code, but lack the patience for highly detailed, error prone work.  Or, they may be technically proficient, but unable to communicate what they're doing.  They may not understand the fundamentals of what they're doing and paint themselves (and the project) into a corner.

The point is, you can't call up your friendly recruiter and order "competant engineers" like widgets.

Great software comes from people doing what they're great at and what they enjoy doing.  Without long term continuity of team, it's difficult to get to that point.


Bill Carlson
Tuesday, July 2, 2002

I think perhaps that software engineering has been mastered on the micro and not the macro scale. What I mean by this is that any given application developed by a set of brilliant engineers can often excel at a given task. You don't see many people, for instance, complaining about the software that is winamp and how much of an engineering failure it is. On the other hand, we've got large projects, put together by teams of dozens of developers, that require both a large monetary and temporal investment. It is in these projects, whose engineering equivalent would be bridge building, where we see the flaws of the team come through. It is in these macro scale efforts that the previously insignificant errors of the individual grow into the significant and nearly insurmountable errors of the group. Something as simple as a memo misplaced or an email deleted can result in insecure and intolerant end user software. When you are dealing with systems as complex as today's large software project, where actual development moves at the behest of larger socio-political structures, is it apparent that flaws are both inevitable and in many ways impossible to resolve?

This problem becomes even more pronounced when you move into the basic toolset of usability on a system: the OS. Most major applications depend in many ways upon the OS ' backend implementation for most of their functionality. There are two types of OS: the corporate pet and the public playpen. Both of these are subject to built in flaws due to the size of the projects. The very idea of an OS may be flawed due to a lack of fundamental modularity which can cause any flaw in a groups design to permeate through the whole system, thus corrupting the end users experience. But the answer cannot lie in modularity, for another of the flaws lies in the splintering of the end user experience. Each application developer has a different paradigm for what is and is not usable and this creates a system that (as someone in a previous post mentioned) has too many options and differences for a single user. Is there not an inherent paradox here, then, between modularity and consistency?

Modern day engineering systems, such as bridge building and common building construction, rely on a consistent and unchanging base of laws provided by physics. Thus the comparison between software development and engineering may not be an apt one, as the people designing bridges don't have to deal with an inconsistent and unstable base [an OS, for instance]. Nor do people who build bridges have to deal with the issues of modularity, as almost everyone will agree on the design goals and usability concerns of a bridge. I think a more apt corollary to the software industry would be a society as whole: A common group trying to agree on a system for dealing with disagreements born of adverse and often unreconcialable views. In the same way that the nature of society dictates that it shall never be a stable entity, the nature of software engineering as a amulgam of personal goals and priorities prevents us from achieving perfection. Software is and may always be an art rather than a science.

Dustin Alexander
Tuesday, July 2, 2002

Thank you for the link to the EWDs!  I'm right now going through all of them; I've only read a few before.

I notice the earlier point about team continuity.  That reminds me of Peopleware, which mentioned the same thing.  What I remember is that Peopleware also mentions that the best organizations are preoccupied with being the best.  They talk about it in hallways.  And right now I'm in an organization that just wants to be mediocre.  I envy those organizations so much.

Oh, for the obligatory Microsoft put-down, from EWD1283, when MS offered fellowships in return for making NT a core part of CS:  "Since I do not want MS to sue me, I won't tell you how much I appreciate their offer."

Tuesday, July 2, 2002

Dustin makes some excellent points.  A medium sized app with 15 developers might be handled by the "demi-god" approach; one project manager with deep knowledge of the problem,  knowledge of the technology, knowledge of software development management, and knowledge of the market.  That combination is exceedingly rare, but the ability to imprint one vision can be powerful.  This person, with 3 or 4 managers for sub-projects, could "get it done".

The point is well taken, though, that we don't really have an answer for the true 500 person project (not the ten person project disguised as a 500 person ordeal).

Perhaps additional attention needs to be given early in the architectural stages to allow for modularity.  Database driven apps have a great advantage here, since modules often "talk" to each other through the database, reducing "breakable" interfaces.

My team is pretty small (10), so I'm not really fit to comment on huge projects...but I will make a few "FWIW" large-team suggestions anyway:

- Team consistentcy over time (see earlier post)

- No tolerance of "rogue code".  There's always the developer that feels the need to prove themselves by using some technique they read about in Dr. Dobbs.  Occasionally this is harmless, but if odd APIs are used that wouldn't normally be, you could be in for trouble.  At my company, we've wrestled with this issue a great deal.  It's gotten to the point that we've had to remove someone from a project because their code was consistently "weird".

- Have your best developers work on code early in the process.  Less experienced developers should have something good to copy from.  A code base takes on a "culture", and it's essential to have a good start.

- If possible, keep developers working on a module through the first or second release cycle (and beyond if possible).  Senior developers writing code they don't have to live with and maintain is a bit of a negative feedback loop.  People should need to live with the consequences of their decisions.

- Hire good communicators.  You will pay more for this skill.

- Hire well-rounded people.  My personal experience is that development is about balancing tradeoffs.  Someone who knows how to do this with their personal finances and relationships has a better chance of success in a large project.  This person may not want to work a 60 hour week.  (touchy subject. opinions welcome.)

- Allow long "ramp up" time.  This is hard to do.  The idea is that you let someone know what project they'll be working on 3 months before they start.  A good developer will start "the wheels turning" and have ideas, have spotted pitfalls, etc. before they start coding.  I find this extremely helpful personally.

- Have "gurus".  Sometimes there's no subsitute for someone telling you "that's a bad idea" before you spend 2 weeks on something.  Or help resolve a spat between two junior programmers.  Or casually let QA know that someone's module will require "extra care".  Or has the "weight" to question managements insistence on a new feature.  You get the idea.  It's not possible to fit these things on a line-item, but they do help oil the machinery.

Bill Carlson
Tuesday, July 2, 2002

I also hate buggy software and would like a way to create bug free code, but I wonder why IT/programming is the only part of a business where we expect perfection.  Do we expect marketing to sell to everyone that sees the ad? Does the sales department close every deal and make each quota? Is there a science that will allow a CEO to always make the right choice? 

We can sure do better but maybe we should look how the rest of the world operates, for example, in a lot of cases being able to quickly correct a problem or make an adjustment works as well as being perfect. 

Sometimes you cannot tolerate errors such as with air craft. There both the human systems and software systems are handled differently. I don't the exact details but commercial pilots have more training that 16 year olds who get their drivers license. Similarly, software for airplane control must be reliable.

MS Word has bugs and is not perfect but I can produce better quality work with it than I could with a typewriter or a pen an paper, so I use it.

I maintain a critical system that is easy to change so problems are handled sometimes in minutes. No one likes errors but they know it can be fixed so they don't panic. 

My advice is to design the code so that change and problems can be handled easily.

John McQuilling
Wednesday, July 3, 2002

The first posters mentioned complexity and I think this might be a key to our problems:
Complexity in other engineering disciplines is normally limited by the physical world and their constraints. It is not in our world of purely virtual systems. Complexity in the software world is only limited by what we can handle with our methods and minds.
And so it could very well be that we will forever (while Moore's law lasts, that is) play catch-up by developing better methods to solve Problems of ever increasing complexity.
Scaring though, isn't it?

Claus Christensen
Wednesday, July 3, 2002

Claus... let me take the liberty of revising some of your statements - to help me clarify my post on complexity:

The first:  *Creation* in other engineering disciplines is normally limited by the physical world and their constraints. It is not in our world of purely virtual systems.

Now I can agree.  Physical laws, or the laws of nature, sometimes called "first principles" cannot be broken.  Attempts to do so can result in death.

The second: Complexity in the software world is only limited by what we can *create* with our methods and minds.

Many of our software developments have outstripped the minds of the project individuals.  But this has been the result of those project individuals... not the cause but the effect. 

Both of these together is why I believe the world of art has much more to offer than we give it credit for.  Many of our developments, should such an abstraction be presented, would resemble the work of M.C. Escher like "the Waterfall" (a picture I love BTW) - but which no engineer would undertake to physically construct because of the violation of first principles.

The third, I cannot rewrite, so I quote it:  "And so it could very well be that we will forever (while Moore's law lasts, that is) play catch-up by developing better methods to solve Problems of ever increasing complexity."

The implication here, is that a "complex" problem (as it is perceived) deserves or requires or mandates an equally "complex" solution.

Complexity is never a "given".  It is always a choice and it is always an irrational choice.  A rational person does not seek complexity, he "tames" it.

Look to your own experience.  What is rewarded?  Is it not the "complex" problem with the "complex" solution?  Is it not the person that creates the most messy kludge the one that receives the greatest rewards for his... dedication, technical or managerial skills, long and hard hours, countless numbers of bug fixes and defect counts.  This is the one that gets the praise - for "attempting the impossible against all odds".

If you have it in your experience... look at something that you consider "elegant".  What reward did the person receive that developed it?  Most likely little to nothing.

Elegant is also "the lack of complexity".  It is elegant because when it is perceived it triggers that "AH HA!" response in your brain - you can see it clearly, how nice and neatly it controls "the problem", how nothing about it seems wasted or without purpose.  You admire it... wanting to be capable of producing something so wonderful yourself.

But for most, the feeling in that last sentence only lasts a moment or so.

Why?  Because now it seems so simple.  You reason or delude yourself into believing that, because it is simple, then the problem must not have been as "complex" as originally believed.  Because it is simple, you make the erroneous conclusion that *anyone* could have done it.

Then you slip back into your normal routine of complexity worship. 

Those individuals out there that have created "elegant" solutions, know something else... They know that "somehow it just came to them".  They know that it wasn't a function of the length of time they were allowed - and in most cases, the time was much shorter than others felt the problem deserved... to be "solved correctly".  They know it wasn't the volume, weight, or details in the volume of documents that may have proceeded it's creation.  They know it wasn't a result of following the practices and routine of "software engineering" with rigor... and they also know if they had taken that approach it there would be a high probability it would never have existed.

I think it was Bill Carson that mentioned "the true 500 person project" somewhere above. 

There is no such thing... this is what happens, but it will take an awful brave manager type to admit it.

When faced with perceived complexity, the mind shuts down and we go into kneejerk response mode.  With the mind shut off, we demonstrate and use complexity as the justification of our inability to handle it.  This justification gives us dollars to bring on loads of people to throw at the problem in hopes of somehow solving it.  We then adhere more or less strictly to some "mythology" to guide us through the complexity nightmare further providing us an excuse of keeping our minds shut down.

We then organize the herd into compartments.  The compartments may be groups of a functional or technical nature, it really doesn't matter... but with our "organization" under control, we proceed to document "the solution" guided only by faith... safe in the knowledge that any cross compartment communication about the problem has been effectively prevented.  There is no way to validate "the solution" because we know nothing about "the problem". 

We fix the bugs, the defects, implement a kludge, receive our rewards for our magnificent achievement, update our resume with all the new buzzwords... then move on to the next failure to be conducted in exactly the same way.

"The Universal Scenario"... always playing at a location near you. 

No, we have nothing to do with it... "complexity" is the real problem.  It is not our fault, after all, we followed the ABC mythology highly recommended by the XYZ institute of Software Engineering!!!  We even received a purdy award for our level 5 performance.

When nothing really "new" has to be achieved, then work can be formulated into a blind process.  That is why, and only why, the NASA software performance is so good.

But when something "new" needs to be created, it can only be created by the intellect.  Forcing a blind process onto the intellect guarantees it will not be used.

Switch on, switch off.  The mind in innovation is binary.

Joe AA.
Wednesday, July 3, 2002

Quote from JoeAA

Why? Because now it seems so simple. You reason or delude yourself into believing that, because it is simple, then the problem must not have been as "complex" as originally believed. Because it is simple, you make the erroneous conclusion that *anyone* could have done it.

This seems to go hand in hand with the expression that says: A Pro makes the difficult look easy.

This also gives rise to frustration of having achieved something and trying to impart to others only to lead them to the water's edge but not being able to get them to drink!

Greg Kellerman
Wednesday, July 3, 2002

You can lead a horse to water... but have you ever smelled a wet horse!!

Joe AA.
Wednesday, July 3, 2002

"When nothing really "new" has to be achieved, then work can be formulated into a blind process. That is why, and only why, the NASA software performance is so good."

I work in the Space Shuttle Flight Software devlopment organization.  If you don't count the tools people, we are actually only 250 strong.

The reason why our performance is so good is because we work with an intelligent customer who understands their own requirements.

We work within a framework that rewards superstars but does not depend upon them.  The process is not blind, the process is repeatable and transferrable to new employess (probably limited to about 20% attrition).

We are given reasonable schedules and spend very little time actually writing code (that's the easy part).  By the time the change request gets to the coder's desk for implementation, there is really not much left to do.

Wednesday, July 3, 2002

cheeto - 20% attrition?  That's 50 people a year.  I've worked in sweat shops with less attrition than that!  Is it possible your attrition rate is due to boredom?

I really don't mean to sound so sarcastic. 

The reason your process is repeatable and transferrable to the newbies is because nothing really changes, nothing of any real significance happens.

Your process is dedicated to your product - not much different than a factory assembly line may be dedicated to producing a certain style of vehicle.  But without a lot of retooling, that same assembly line cannot be used to make airplanes.

If I only had one software product and it was already created, then I could have widgets making additional copies for me.  It wouldn't take a rocket scientist (sorry, couldn't help it) to put on a new style hubcap if I needed it.

If you had to start all over, on a brand new product... say a CRM application (an example from someone else), then your current process would make just as much a mess of it as we are able to do.

Joe AA.
Wednesday, July 3, 2002

I knew that phrase about the attrition wouldn't come out clear.  I meant that you could probably lose about 20% without noticing much effect in the end product.  After that, there wouldn't be enough of the experienced people to adequately train the new guys.

I agree that our process is dedicated to our product.

I disagree that we don't do anything significant.  Outfitting the software so that shuttles can use GPS was major, modifying our control algorithms to boost the ISS without tearing it apart was major, stretching the abort capabilities so the crew spends fewer and fewer seconds in the "black" zones is major.

I am trying to defend what we accomplish without sounding defensive, I hope I can pull it off ...

As far as new development goes, we are chin deep in yogurt trying to develop the new display system for the orbiters.  New computers, new OS, new language.  Much of this process was borrowed from the FSW side and they actually aren't doing too bad.  But we haven't got into the verification phase yet...

What it basically comes down to is some products and customers cannot afford our process (time/money), but we can't afford not to use it.

Wednesday, July 3, 2002

Our actual attrition is probably around 2%.  I'm in a dept. of 16 and have seen maybe 5 people come and go in 6 years.

Wednesday, July 3, 2002

cheeto - you never had to defend what you accomplish, and don't think I was degrading them.  I admire your accomplishments.

Thanks for clearing up the attrition figures! (whew!)

Joe AA.
Wednesday, July 3, 2002

Joe, thanks for this intelligent discussion! Isn’t this what we came for to Joel’s site in the first place?
Yes, I agree with what you said about the worship of complexity and I remember so many times when I showed others an elegant solution and earned only blank stares and a “so what?”. Fortunately, I usually work on small projects with good developers and the time saved by an elegant solution is enough motivation for me.

I guess you are right – much if not most of the perceived complexity in large software projects is only that - *perceived* complexity that is waiting for someone to perceive the simple underlying problem and thus find the elegant simple solution.

But I still think there are many problems thrown at us programmers today with rising inherent complexity because we don’t (and can’t have) total control about every aspect of the problem *formulation*.
Example: Why are large accounting packages so complicated? Accounting is super-simple, just add the numbers! It just gets horrible complicated because the structure of multi-national companies and the taxation laws. Tax is immensely complex with all it’s exceptions and exceptions from exceptions and the software just has to follow this complexity to be of any use to an accountant. The software developer cannot find the simple elegant solution in this class of problems alone. There just isn’t any pattern to taxation laws that could be discovered (IMHO). The solution would be to create a simpler company structure, simpler taxation laws and hey, let’s change the world financial market structure to something simple and elegant while we are at it.

See the pattern? Some complexities are not in the problem, but only in the shape of our tiny (software-) part of the problem formulation. And that is what counts – the problems that are actually thrown at us, not the larger (and probably simpler to solve) underlying problems that are never shown to us.

I just stay away from excessively large projects as long as I manage to make enough money otherwise. In smaller projects you do tend to have more control even over the environment of your part of the solution. But they are smaller projects and I can understand why someone would want to be a smaller part of for example the space shuttle flight control software team. Cool project, cheeto! But I already hate all that paperwork that I am doing for a small aircraft engine control software and I dread imagining what kind of paper trail developing for critical space applications requires.

Claus Christensen
Thursday, July 4, 2002

    Joe, your second post is mainly on "worship(p)ing complexity", but I still don't get your other point:

> Recognize complexity for what it is - a relationship between system and observer - not as a measurable attribute or property of a system (as they wish it were). (...) I think it has to do with pretending the observer (e.g. yourself) has nothing to do with complexity - it's easier to blame the system.

    Granted, one can't blame a theory or a system for being too complex for him to understand it, but only in the case this complexity is "inherent" (inevitable), and not "accidental" (i.e., unnecessary). Otherwise you may defend any mess by blaming dumb readers or users. A paper's title, "Higher Order Functions Considered Unnecessary for Higher Order Programming", serves as an example, and the "unnecessary" here meant also "more complex".

> Complexity is never a "given". It is always a choice and it is always an irrational choice. A rational person does not seek complexity, he "tames" it.

    Tames how? By an irrational choice? Like in chosing between Arabic and Roman numerals? Avoiding certain programming constructs on the ground that they make reasoning about programs more difficult is irrational? Avoiding case analysis where a single argument would suffice is subjective?


Andrzej Kocon
Thursday, July 4, 2002

Thanks for the responses, but...

    Let's separate things for a while, putting the commercial software development, team management, schedules etc. aside. The point is that even in "laboratory" conditions, where the business aspects do not interfere, "the computing's central challenge (...) has not been met". So those other aspects are at best about how not to worse the situation.

    As for the art analogy, the art (like engineering) implies mastering the underlying matter and techniques, and since we are far from it (even in laboratory conditions), alchemy would be a better term, unless you consider filling hundred buckets and naming it "By the water" an art (authentic). On the other hand, "mastering" does not imply that the process becomes "blind" or automatic. What is the eldest paper evoking the art analogy? Certainly not the Knuth's Turing Award Lecture, "Computer Programming as an Art", 1974, CACM 17(12).

    Pureanonymous, I hope an occasional anti-MS remark (MS being only an example) won't result in missing the critiques of OUR daily practice (as in EWD1305, for example)...

    BTW, what about EWD1209, "Why American Computing Science seems incurable"?

Andrzej Kocon
Thursday, July 4, 2002

Well, the EWDs preach to my choir.  Like in EWD 648.  Before I code a line, I like to lie in bed, thinking of how to understand the problemspace and express it in its own syntax.  I rarely write bugs, mainly because my code follows my design.

I see that functional languages are making a big comeback.  It's everywhere on the web.  I wish the formalists did the same, leveraging the web to make up with spotty CS departments.  Until that happens, what is there to say?  Berate people for not being more formal, but not how to do it?

The market's bad, and people are looking to differentiate themselves by getting deeper skills.  A good time as any to introduce the old ideas that failed to catch on before.

Thursday, July 4, 2002

Andrzej Kocon - You can classify complexity any way that you want.  You can pretend some of it is "inherent" and you can pretend some of it is "accidental". 

Both are strategies that assist in ignoring the observer's role - it denies the relationship by placing complexity of any flavor as a "system attribute".  It is still "Out There!", somehow existing in that thing that is deemed to possess complexity.

But it doesn't exist... relationships are not entities - they have no weight, no form and no measure available to them in physical reality. 

Change the relationship by changing the observer and "complexity" will appear to change.  If complexity is really in "that thing", then how can it appear to be more or less based on the observer?

It seems that you got my remark about taming complexity backwards - irrationality cannot tame it.

Irrationality runs through our business and software engineering. 

"Problem solving"... as taught in school, as it is used in software engineering has an assumption that is enforced through practice, but through practice has proven itself time and again not to be true:  The presentation of a well formed problem statement.  Problem solving is then assumed to be nothing more than a "multiple guess" type of test, matching up an appropriate solution "answer" to the question presented by the problem.  And with all tests, each and every problem has one and only one correct answer.

Structure... meaning the mental overlay that you place on a problem is the method to taming complexity.  There is no standard overlay, it varies with the problem.  Until you know absolutely everything there is to know about the problem, the overlay you place on it will probably cause more harm than good.  Study the work of Ashby.

Even if you call that overlay "software engineering".  Software engineering is nothing more than following a process in hopes that the process will work.  That a miracle will occur by going through the motions.

And if you look at the stories of significant *new* engineering efforts, they are not achieved by following the same old stagnant process that creates the normal run of the mill engineered result. 

Study the history of the Empire State Building - erected in record time, shorter than the "unreasonable" timeframe given to the project, with less deaths than predicted - and No, it wasn't all planned out to the nth degree.  Hoover Dam is another example - the number of untried, untested "techniques" used during it's construction is simply amazing.  The building of the first atom bomb - only achieved through a "skunkworks" with lots of trial and error... and regardless of the end result, the achievement itself was significant.

There are ways not to make a mess of it, but none of them involve following a "checklist" approach to development.  The great lure... the ultimate bait of software engineering, is that any idiot can be trained to follow the process. 

It simply costs less to use idiots if the same result can be achieved - and that my friends is what causes the mess.  Not the lack of time, not the lack of resources, not the lack of private offices, not the lack of certification, and not the presence of H1B.

Mastering techniques is not the same as mastering an art nor an engineering discipline.  The "naked chef" ain't good because he knows how to slice and dice better than anyone else... 

Joe AA.
Friday, July 5, 2002

"Software is and may always be an art rather than a science."

I think software is both an art and a science, according to the real meaning of the words.
"Art" refers to things made by humans, as opposed to nature. "Science" refers to a method of discovering and learning about the world.

Software is something completely different from what people think it is. It is much more than a way to build a business application. It is a way of thinking, creating and discovering, different and in a sense better than any we've had before.

Please don't expect software development ever to be like architecture -- the smart people draw up the blueprints and then hand them to the less smart construction workers.

Software development is inherently complex, inherently creative. Yes the process needs to be well-organized and standardized or you wind up with a big mess. But it won't ever become the mindless activity you are hoping for. Maybe some aspects of it will, but I and I'm sure many others will stay as far away as possible from those areas.

Technology and society keep evolving and becoming more complex and, like it or not, we are all part of that evolution. People who can't stand boring jobs will always find a way to be involved with complexity and uncertainty, wherever that may be.

Long live complexity.

Saturday, July 6, 2002

    So, Joe, not only beauty, but also complexity is in the eye of the beholder? Now I understand, we simply use the term complexity with different things in mind.

    In our field we have already grasped the computational complexity it terms of time or space or energy the execution of a program will take. This specific complexity is independent on the observer (except he has quantum computers), and lower bounds deserve the "inherent" adjective. Also, these are not arbitrary measures, as they lead to meaningful and useful results. Certainly it does not cover the whole idea of complexity in our discipline. But is it the only meaning of complexity we can grasp in this way? How to compare two programs of equal computational complexity? Is it that it only seems to that one is less complex in a way than another? Should we give up and declare that there are no coherent and useful measures we could invent in this case? We do not want to mathematically define all the meanings one could associate with the term in question, but to cover another technical aspect of it for our purposes. There are attempts that deal with the order of mathematical concepts necessary for correctness or derivation proofs, or with the length of such proofs.

    I'm well aware of the fact that practice seldom waits for a theory to be accomplished, even if that would cost lives, as it was with the atom bomb tests on own unprotected soldiers (btw., the possibility of the bomb was theoretical first). I know the examples of architectural achievements done without complete knowledge of the projects. These are not *new* approaches, as the dispute between "schools" lasts centuries (one school would not build anything if it could not be "computed", the other quite so). But these arguments are irrelevant here. I didn't exhort to refrain from programming until we knew everything about it.

    The point was that theoretical deficiences may also have something to do with the general lack of software quality, point.

    I didn't say that mastering techniques was "the same" as mastering an art (please verify). Art school graduates are not artist, but are prepared to try. I didn't say programming would ever become mechanical ("checklist" driven) thanks to a theory. Applying well known mathematical results and techniques is not a thing "any idiot could do". Certainly, to make a mess "it costs less to use idiots". But it costs tremendous amount of resources and effort to make decent software even by the most skilled (and for "well formed problem statements"). Does it have to be so? Is it that we don't expect any help from computing science?

    Regrettably enough, I'll left remaining remarks without comments (problem solving, "mental overlays", H1B's, etc.). Interesting topics as they might be, they are out of the scope of this thread.


Andrzej Kocon
Sunday, July 7, 2002

So you are calling the measurable... performance? of a program "computational complexity"?  I see... you never got that riddle about the number of legs a dog has by calling his tail a leg.

"But it costs tremendous amount of resources and effort to make decent software even by the most skilled (and for "well formed problem statements"). Does it have to be so? Is it that we don't expect any help from computing science?"

I'm not sure what you meant by this.  Sure, we throw resources and effort in an attempt to make decent software, but because that is what we do... it does not imply that it is necessary to do so. 

And, just like engineering projects that have been done without the flavor of the day checklist approach (*new* at the time, some considered impossible, but then everything seems consistent with 20/20 hindsight) - well below the best "state-of-the-art" effort, cost, and even death rate estimates - great software has been developed in our history by people "foolish" enough not to deem it impossible because of "complexity" and "stupid" enough not to know it is a requirement to throw away resources to develop it.  Visicalc is one example that springs to mind.

PC... your comment: "Please don't expect software development ever to be like architecture -- the smart people draw up the blueprints and then hand them to the less smart construction workers." is "unfair".  It is clearly documented in the field of architecture that the lowest cost and highest quality comes from architect/builders - NOT from the ones that operate an "assembly line" process.

Joe AA.
Sunday, July 7, 2002

In fact, computational complexity is more about "performance" of ANY program for a given problem, so it characterizes how "hard" (or "inherently complex"? - in a sense) the problem is. This is established name of a discipline, and I don't think the term is completely misused here. But it doesn't matter: I've explained at least what I had in mind. We know we can't expect significantly faster programs for certain problems (not with conventional or parallel computers anyway). We may not know the exact algorithm, but it is good to know what could be achieved by any approach. There are other "complexity" issues we would like to grasp in this way.

Decent software does exist, but more as an exception than a rule. As to the cost of developing good software by the most skilled and for well formed specifications (this very thread provides some examples), a fraction of it may be attributed to our still insufficient understanding of the problems that "bare" programming poses. The "flawless" Mars Pathfinder story illustrates this. It was not a misspelled identifier this time, but insufficient understanding of the priority inversion on real time systems that caused system resets and loses of data (some may call it "unmastered complexity"). Of course developers were humble enough to anticipate errors (i.e., bugs), and they provided a recovery strategy (watchdog timers, debug code, upload facilities). Attempts to replicate the failure conditions took "hours and hours". Thanks to an ingenious engineering approach Pathfinder came to existence, but it should be clear what is the real problem.

Let me repeat: theoretical deficiences may also have something to do with the general (prevailing) lack of software quality. Peopleware-like recipes are important, but they seldom mention the fact, as if we had not expect anything anymore from computing science. (Besides, it's easier to dispute things like working hours, see the length of the respective threads...).

(For the Mars Pathfinder Story see: ).


Andrzej Kocon
Tuesday, July 9, 2002

Andrzej... the thought for the week seems appropriate enough!!

Joe AA.
Tuesday, July 9, 2002

*  Recent Topics

*  Fog Creek Home