The Black Liszt

  • Software Productivity: the ABP Factor

    There is one central, screamingly obvious factor that impacts programmer productivity. It is unknown, ignored and/or undiscussed. But it matters more than most other factors. It's the ABP factor, "Anything But Programming." When a programmer isn't programming, that programmer isn't, well, writing code. I don't care what that programmer is doing! If it's ABP, that person is not — repeat not — writing code!

    The ABP Factor

    If your job is reading, any time you don't spending reading is time you're not doing your job. Call it anything you like: getting ready, preparing, taking a break, recovering, digesting, blah, blah, blah. Whatever you call it, if you're not reading, you're … (get ready now) … not reading! You're doing something else.

    If your job is cleaning the house, any time you spend not cleaning the house is time you're spending not doing your job.

    I hope you get the idea by now.


    2012 07 10 YoYi meeting
    (Above: typical programmer/manager meeting in Beijing. Photo by me.)

    Understanding the Status of ABP

    Non-technical people, people who don't program, people who used to program but don't any more and people who still think they're programmers but have regressed to a lower form of life (like managers) often value what they can do (which is clearly ABP) highly. Makes sense. If you do it, it must be a good thing. If you can't, don't or won't do it, it must not be the kind of thing really valuable people like you do. This applies to programming in spades. ABP is highly valued. Programmers quickly get the idea that the way to increase your status is to spend increasing amounts of your time indulging in that valuable thing, ABP.

    Is ABP Worth Something?

    Putting my cynicism aside for the moment, the answer is a clear, resounding yes. A certain amount of planning, coordination and other stuff is necessary. Not doing it well leads to really bad things. It's even OK for some people to spend most of their time in such non-programming activities!

    But let's make it even clearer. Think about manufacturing or customer service. Either you're directly contributing to the production of goods or services, or you're not. If you are, we can start talking about how effective and efficient you are. If you're not … either your personal productivity is lower than it could be or, much worse, you're overhead!!

    Conclusion

    Are you writing code? Good. Then we can have a grounded discussion about your productivity — at least you're trying; at least your shoulder is at the wheel and you're pushing. Are you doing ABP? You're probably self-important overhead; stop wasting my time and yours.

    Maybe you really are doing something that makes productivity better in some mysterious way. I'm open to the possibility! But the burden is on you to prove it.

    Personal note: I spent most of every day writing code for a couple decades. I know all about programming overhead. I was acutely conscious of my personal overhead, and contributing to other peoples'. Now I don't write code. I feel guilty wasting the time of programmers. The only way I can justify it is if, as a result of our interaction, their productivity goes up, so that the time spent not programming ended up being a net productivity increase. I always think: minimize the time, maximize the value.

  • Software Productivity Divisors: Doubling the Work

    Software productivity is incredibly important, but hard to measure and hard to achieve. Nonetheless, good people seek ways to make their software productivity better. They seek out productivity multipliers.

    All too often, widely hailed advances in method and technique not only fail as productivity multipliers, they are actually productivity divisors!

    There is a whole family of software productivity divisors whose obvious impact is to double (or more!) the labor for any given body of code. They don't double the pleasure or double the fun — they double the work.
    Doublemint 2
    And yet, these methods are taken seriously by all too many people in the field.

    What are software productivity divisors?

    The field of software is awash with a plethora of tools and techniques, each of which claims amazing benefits, usually boiling down to producing better code with less effort. They are, in effect, promoted as productivity multipliers.

    Some of the techniques are simply useless. But a surprisingly large number of supposed software improvements actively make things worse. They aren't productivity multipliers — they are productivity divisors.

    Doubling the Work

    One large class of fancy new software methods essentially involve doubling the work. There are two main methods for doing this.

    One favorite method of work doubling is very simple. Instead of using one programmer to do a job, use two.

    Another widespread method of work doubling is to write the code twice, in different forms. Usually, one form of the code is the code that you actually want to write. The second form of the code is normally a mirror of the original code, whose nominal purpose is to test the original code.

    Each of these methods is completely brain-dead. They normally double the labor of everything that is done, while not improving the value of the results at all. Costs more … later completion … no greater value … Hmmmmmmmm … what's wrong with this picture??

    Pair Programming, the Hot New Productivity Divisor

    Programming is, by definition, a task that requires great mental concentration. Kind of the opposite of what you do in social situations. Two people working on the same task relate to each other socially. In fact they are supposed to interact. If one person codes and the other one sits there, you've doubled the labor with no gain at all. To the extent that the second person interrupts (as he/she is supposed to), you've made things even worse.

    I know, I know, the whole idea is that the whole is greater than the sum of the parts. The second person catches mistakes the first person missed. The second person comes up with a much better way of doing something than the first person got part way done doing. Etc. It's all a bunch of Bologna. I'm relieved that silly parodies of this silly idea are beginning to appear.  

    Unit Testing, the Classic Productivity Divisor

    There are many variations of unit testing for code, from test-driven development on. People get into arguments about whether you should write the test before or after you write the code, whether the person who writes the code should also write the test, and endlessly on and on. They all amount to arguing which is worse: dirty stinking rotten, or slimey awful junk. Who cares?? It's all bad!!!

    No one claims it's easy to write good code. Code that's accurate, fast, does the job, does only the job, has no side-effects and doesn't crash. Still, there may be bugs. The idea with test code is that someone, in some order, writes test code that assures that the original code is accurate, fast, does the job, does only the job, has no side effects and doesn't crash. If you leave out any one of these items (as is typically the case), you haven't tested everything.

    The person who writes the test code has to understand the requirements just as thoroughly as the person who writes the base code. Just as the person who writes the base code can make a mistake, so can the person who writes the test. It is just as hard to write the test as it is to write the code being tested. So you've doubled the amount of work, at minimum.

    Now think about making changes and debugging. Instead of just changing the code, you've got to change the test code, and either one can have bugs. The test code can fail to test something that is supposed to work, or declared that something works when in fact it does not, as a result of a bug in the test code. So changes are now twice as much work, with twice as many places for bugs, in addition to bugs of interaction.

    Any variation of unit testing has the certain result of at least doubling the cost of building a piece of code, usually increasing the elapsed time, with vague promises that are never proven and never measured about the improved value of the results.

    Conclusion

    In many organizations, there is a dead-simple way to improve software productivity: STOP the madness of institutionalized software productivity divisors! You don't have to be best-in-class; you just have to avoid doing things that for sure double the work while doing some enthusiastic but empty arm-waving about the future benefits.

  • What is Software Productivity?

    People
    in every field are concerned about productivity. They want to know how
    to increase their own productivity and the productivity of their group.

    Software
    is a peculiar field in which history is ignored and fashion too often
    trumps objective fact. In software, we don't even think about productivity, much less have any idea how to measure it.

    What is Productivity?

    Productivity measurement is central to our economy as a whole, to industries as a whole, and to individual companies.

    In general, the more productive you are, the more outputs you generate for a given set of inputs.

    Productivity can be measured by various means, depending on the purpose of the measurement. At the level of the firm, the most basic measurement is comparing the cost of the inputs to the value of the outputs, adding in overhead and the cost of the capital and labor required to produce the outputs.

    Increased productivity can be accomplished by greater automation, improved processes, reduced cost of inputs, labor or capital, and by more effective use of labor, labor that is higher quality, more discliplined, trained and motivated, etc.

    This is basic economics. It is applied from the national level down to mom-and-pop firms.

    What is Productivity in Software?

    Measuring
    software productivity is incredibly important. But practically no one
    actually does it! It's not even studied in any meaningful way — if it
    were, you'd find competing theories, and experiments to settle the
    issue. While there are a couple studies, their paucity and narrowness
    prove the case that software productivity is largely ignored, both in
    theory and in practice. GIven that software is increasingly the engine
    that drives our enterprises, this is amazing.

    The situation with software productivity is a bit different than in your basic widget factory.

    • The cost of the inputs is pretty much zero
    • For all the talk of software factories, the cost of "machines" is generally insignificant
    • While the quantity of output (lines of code, LOC) is tangible, it's not really correlated with value
    • Except in a few cases of commercial software products, the value of the output can be hard to measure, and even then it can be dicey.
    • The overwhelmingly important factor in cost tends to be labor!

    Software Productivity: the best case

    To
    understand software productivity, let's start with an extreme case, but
    one that does happen a small percentage of the time.

    A
    single person understands the requirements of what is to be written.
    That individual, perhaps with the assistance of one or two other people,
    writes, tests and delivers the code. The code runs in production for a
    number of years, and the few bugs that arise and the enhancements that
    are needed are quickly supplied by the original author(s).

    In a case like this, the value of the outputs can still be hard to measure. But at least the other costs are easy: it's basically the cost of the people, with overhead.

    Is
    this a fantasy or does it happen in real life? Well, all I can say is
    that it happened in my life, more than once, and I know people who have done similar things. In my first job after
    college, I wrote a commercial FORTRAN 66
    compiler and run-time system (in assembler language) for a computer
    company    . I had an assistant for part of the run-time environment. It was
    in production use for about ten years. I fixed a couple minor bugs in
    the first year, and that was it. I personally did a couple similar
    projects in different software fields.
    IMLAC

    In the case of the compiler, the cost was easy to measure. The value was typically challenging, but not too hard. The company sold the compiler. But its greater value was enabling sales of the display computer on which it ran. Potential buyers were refusing to buy because there was no high level language available at the time; my compiler enabled many sales that otherwise would have been lost.


    It's
    easy to imagine the software productivity in this simple case. You can
    pick your measure of value (pick a few — why not?), including lines of
    code, number of users, value of the code, indirect value. You pick your measures of cost
    (again, pick a few) including person-days, elapsed time, salaries, etc. And finally, you relate them into simple, calculable numbers that you can track over time.

    Software Productivity: the Reality

    In practice, software productivity is an absolute bear to measure. Cost isn't too hard. But valuing the outputs? That's the big problem. The other problem is that software just isn't like a widget factory. The items ("pieces" of software) cranked out are simply not comparable to each other, as I've discussed.

    Conclusion

    Productivity is important in general, perhaps even more in software than other fields because it is so hard to measure. Software won't get better until we increase its productivity, and that won't happen until we are hard-nosed and objective about exactly what software productivity is. All the discussions in this blog about software quality, estimating and other things are best understood in the broader context of software productivity, the great unknown frontier of computer engineering.


  • Does your Software Work Well? Look Good?

    It doesn't matter how good your software looks if it crashes. If it's broken, please take it home and don't come back. But if it does work, then the next thing you should care intensely about is how good it looks. Software winners tend to combine great design with code that, you know, works.

    I'm a fanatic about software QA. It is one of the most unappreciated aspects of software development. But it's not the only thing that matters. Just as in math, beauty is something that pervades all aspects of great software, internally and externally. The impact of great design should never be minimized.

    One of my favorite Oak companies is OneMedical. They are re-inventing the doctor's office. They use great software behind the scenes, much better and more effective by far than most doctors use. They use modern methods for patient/doctor communications; you can e-mail with your doctor — what a concept!

    On top of all that goodness, they have great design. The pictures on their website give you the basic idea.

    I just went in for an annual checkup. My doctor, Malcolm Thaler, was great. Here's a picture I took while in the "waiting room" (given how it looks, I kind of hate to call it that).
    2012 08 21 OneMedical view of office

    Here's a picture I took through the window of Dr. Thaler's office.
    2012 08 21 OneMedical view from office

    Even if you don't have access to the software behind the scenes like I do (I mean in general — no, I can't and wouldn't want access to patient records), the great design of their offices gives you the visceral impression that good things are happening at OneMedical. As indeed they are.

    The lesson is a general one. Once you've gotten good, be sure you look good, so that people will think the right thing at first glance.

  • Coupling in Software: Loose or Tight?

    Some of the biggest mistakes in software architecture do not involve making the wrong choice; they involve failing to consider an important choice altogether, by assuming (without consideration) the approach to take. A great example of this is whether software components should be "loosely coupled" or "tightly coupled."

    What is Coupling?

    "Coupling" is closely related to layering in software, which I've discussed elsewhere. Given that two bodies of software are going to "talk" with each other, how "tight" is the communication layer?

    There is a spectrum of how tight the coupling is.

    At one end of the spectrum is "tight" coupling, which is like when two people are physically together and talk with each other. 1980 07 15 wedding C1-080
    Just a little in from that end is like when two people are not physically together, but still communicate in real time, like a phone conversation.

    At the far loose end of the spectrum is when the people are separated by space, time and perhaps other factors. A newspaper is an example of loose coupling in this way, particularly when you throw in letters to the editor. (Credit.) 1letter
    The more you stretch the time and how personal the communications are, the looser it is. Notice that when you stretch time, normally there isn't just a communications medium involved, but also a storage medium of some kind, like the newspaper.

    Tight Coupling in Software

    When two computer modules are tightly coupled, they communicate with each other in real time. If they're in the "same room," the communication is simply via an interface of some kind. If they're not, they use some kind of API involving networking; RESTful API's are a typical current example of this. In any case, the communication is pretty much real time, like a phone call.

    Loose Coupling in Software

    Loose coupling is everywhere in software. Everyone experiences a common form of it with e-mail. You send your e-mail and it sits around until the recipient grabs it from the mail server and reads it. Queuing systems are a bit tighter, but still pretty loose. Databases and document repositories are also a form of loose coupling.

    Which is the best Coupling: Tight or Loose?

    You know the answer: it depends on the application. If you're standing at an ATM waiting for money, you demand tight coupling, and so does the bank that holds your money. But e-mail wouldn't be e-mail unless it was loosely coupled. The whole point is that the other guy doesn't need to be sitting around anxiously awaiting your e-mail.

    If the application itself doesn't determine the answer, there are other factors that can tip the scale. Tightly coupled systems are generally harder to upgrade and test, because both sides need to be upgraded and tested together, in real time. So when you can get away with loose coupling, it makes the communicating components more independent of each other and makes life easier all around.

    Loose and Tight Coupling in the Literature

    Warning: the computer literature defines tight and loose coupling in different ways than I have here. I'm talking about a rather different concept, one that IMHO deserves more attention than it gets.

    Conclusion

    While you're thinking about layering, you would benefit from thinking about coupling at the same time. A clever, appropriate coupling strategy, using loose and tight to greatest advantage, can help unleash software efforts and make everything go faster.


  • What Can Software Learn from Steamboats and Antiseptic Surgery?

    Software is among the most advanced, rapidly changing fields of technology. Only the "kids" who grew up with the latest techniques seem to be able to master them. At the same time, really bad ideas spread through software groups like the plague; they take hold and resist cure, in spite of producing terrible results. How can we make sense out of a field that advances rapidly and resists change at the same time?

    History

    As I've pointed out, software people are strongly averse to learning about computer history. In some fields (e.g. physics), the very terms used are named after historical figures; in others, history is treated with reverence (e.g., Santayana: "Those who cannot remember the past are condemned to repeat it."); in software, by contrast, we use the phrase "that's history" to dismiss anything that happened in the past as obviously irrelevant to the present.

    I think studying history is the only way to understand the present, software included. I think we can understand the strange software phenomenon of rapid change combined with resistance to change by taking two examples from history: one in which new methods in technology were rapidly accepted by all concerned parties, and the other in which clearly superior new methods were resisted for many long years by the leading people in the field.

    Steamboats

    It would be great if software advances were adopted quickly, like the way steam technology rapidly overcame wind as a method for moving boats.

    The displacement of wind by steam is clearly laid out in T.J. Stile's excellent biography of one of the major figures in the transformation, Cornelius Vanderbilt. 449px-Cornelius_Vanderbilt_Daguerrotype2

    Vanderbilt started in business by running a sailing-boat "taxi" service from Staten Island to Manhattan. He transitioned into the rapidly emerging steam boat transportion business, not only as a captain and owner, but (surprisingly to me) as an engineer.

    The public took to the new steamboats quickly. The reason is clear: speed. There was, at the time, no quicker way to get from point A to point B if there were a water route between them. The speed of the boat was immediately obvious to the simple observer, and easy to verify by noting departure and arrival times. To prove whose boat was the fastest, there were races. 800px-Cornelius_Vanderbilt_(steamboat)

    Vanderbilt's steamboats were judged by a clear standard: whose was the fastest? The criteria were easy to measure.

    Antiseptic Surgery

    The benefits of antiseptic surgery, as introduced by Joseph Lister, were clear: instead of a large number of patients dying of infection after surgery, they would live. Ego clearly played a role in resisting the adoption of the new method. But, to be fair, there is another important factor.

    What made surgery different from steamboats? They were both major technical advances. They both involved major changes in what you did and how you did it — more so with boats than with surgery! So why did steam catch on quickly, even though they required whole new boats of radically different design and operation, while the antiseptic method was resisted for decades, even though it was subsidiary to the surgery itself, which was left largely unchanged?

    Boats and Surgery

    The fact that steamboats were faster than sailboats was easy and unambiguous to measure, while the surgery outcomes were difficult and ambiguous to measure.

    The time of each boat trip is easy to measure. It's just a time duration. When you watch two boats, anyone can see which one moves more quickly. By contrast, every surgery is different. The patient is different, the trouble being fixed is different, and the ultimate outcome may not be determined for weeks. Many surgery patients continued to die with antiseptic methods because it wasn't the only factor influencing the outcome. Furthermore, excellent surgeons who were dirty could save patients that would have been killed by crappy surgeons who happened to use antiseptic methods, since after all not every patient got infected.

    In retrospect, it's completely maddening that surgeons failed to be swayed by the arguments and evidence in favor of Lister's carbolic acid methods, and ego certainly played a role. But the case of the rapid acceptance of the more radical change to steam in boats makes it clear that something more than ego is at work here. Simply put, it is how comparable and measurable are the outcomes of the new technology? With steamboats, you can tell the difference in seconds with the naked eye, and verify it with a stopwatch. No arguments. With surgery, the cases are not clearly and unambiguously comparable, statistics are needed, and there is major variability. There is room for arguments.

    Software, steamboats and antiseptic surgery

    Is any given advance in software like moving from sailboats to steamboats, or is it more like adding antiseptic methods to surgery?

    That's easy: unlike straightforward competitions like races, every software project is different. In a race, the competitors take off from a starting line at the same time, and whichever crosses the finish line first is the winner. Simple! But in the real world of software, every project is different; you can always point to differences in requirements, conditions, deployment, or other things to explain why this project took more time and resources than that project. It sounds like software is kind of like surgery!

    Conclusion

    It is my personal experience and judgment that ego can play a significant role in explaining why many software groups stay mired in the same old methods, getting the same lousy results, year after year. But I think that if software projects were as comparable as transportation schedules, the evidence would simply force more rapid change, like it or not, on intransigent software groups. But because of how genuinely challenging it is to compare software projects to each other, it is at least understandable how only the most enterprising and eager-to-be-the-best software groups seek out and adopt the very best methods. 

  • A Lesson from Joseph Lister: Ego, the Killer of Software Projects

    In the 1880's, American surgeons lost a large fraction of their patients to post-operative infection, including assasinated president James A. Garfield. They simply refused to adopt the antiseptic methods pioneered by Joseph Lister, although those methods were thoroughly documented and proven. In the 2010's, programmers fail to effectively complete a large fraction of their software projects, including ones that are essential to the survival of the organizations that employ them. They, and the educators who train them, simply refuse to adopt effective methods of modern software development. What is the common thread? Ego.

    Joseph Lister

    Lister was far more significant than the source of the name for the mouthwash Listerine.

    170px-Joseph_Lister2
    A surgeon at the University of Glasgow, he read the work of Louis Pasteur, who showed that rotting and fermention were due to micro-organisms. After confirming Pasteur's results with his own experiments, Lister experimented with antiseptic techniques for treating wounds.

    Lister found that carbolic acid solution swabbed on wounds remarkably reduced the incidence of gangrene. In August 1865, Lister applied a piece of lint dipped in carbolic acid solution onto the wound of an eleven year old boy at Glasgow Infirmary, who had sustained a compound fracture after a cart wheel had passed over his leg. After four days, he renewed the pad and discovered that no infection had developed, and after a total of six weeks he was amazed to discover that the boy's bones had fused back together, without the danger of suppuration.

    Chfa_03_img0510
    Lister wrote papers, a book, and did his best to spread the word of his life-saving technique.

    The Doctors' Response

    You would think that doctors would have quickly and enthusiastically adopted the antiseptic method to help improve their awful survival rates. But you know what actually happened. As described in her excellent book, Candice Millard tells the story:

    Although the results were dramatic — the death rate among Lister's surgical patients immediately plummeted — antisepsis had provoked reactions of deep skepticism, even fury. In England, Lister had been forced repeatedly to defend his theory against attacks from enraged doctors. "The whole theory of antisepsis is not only absurd," one surgeon seethed, "it is a positive injury." Another charged that Lister's "methods would be a return to the darkest days of ancient surgery."

    Things got better in Europe. But not in the US.

    By 1876, Lister's steady and astonishing success had silenced nearly all of this detractors at home and in Europe. The United States, however, remained inexplicably resistant. Most American doctors simply shrugged off Lister's findings, uninterested and unimpressed. Even Dr. Samuel Gross, the president of the Medical Congress and arguably the most famous surgeon in the country, regarded antisepsis as useless, even dangerous. "Little, if any faith, is placed by any enlightened or experienced surgeon on this side of the Atlantic in the so-called carbolic acid treatment of Professor Lister," Gross wrote imperiously.

    James A. Garfield

    Garfield was one of the most extraordinary men ever elected president. He was shot in the back four months after being inaugurated in 1881, which is the event that brings us to Lister.

    800px-Garfield_assassination_engraving_cropped
    In short, had he been under the care of English or European doctors, he would almost certainly have survived the attack.

    The Medical Treatment of Garfield

    This site provides a summary of what happened:

    The first doctor on the scene administered brandy and spirits of ammonia, causing the president to promptly vomit. Then D. W. Bliss, a leading Washington doctor, appeared and inserted a metal probe into the wound, turning it slowly, searching for the bullet. The probe became stuck between the shattered fragments of Garfield's eleventh rib, and was removed only with a great deal of difficulty, causing great pain. Then Bliss inserted his finger into the wound, widening the hole in another unsuccessful probe. It was decided to move Garfield to the White House for further treatment.

    Leading doctors of the age flocked to Washington to aid in his recovery, sixteen in all. Most probed the wound with their fingers or dirty instruments. Though the president complained of numbness in the legs and feet, which implied the bullet was lodged near the spinal cord, most thought it was resting in the abdomen. The president's condition weakened … It was decided to move him by train to a cottage on the New Jersey seashore.

    Shortly after the move, Garfield's temperature began to elevate; the doctors reopened the wound and enlarged it hoping to find the bullet. They were unsuccessful. By the time Garfield died on September 19, his doctors had turned a three-inch-deep, harmless wound into a twenty-inch-long contaminated gash stretching from his ribs to his groin and oozing more pus each day. He lingered for eighty days, wasting away from his robust 210 pounds to a mere 130 pounds. The end came on the night of September 19. Clawing at his chest he moaned, "This pain, this pain," while suffering a major heart attack. The president died a few minutes later.

    A whole nation of doctors simply ignored the evidence of the effectiveness of Lister's methods. Lister himself came to America and lectured on them, and American doctors were well aware of the methods. Full of themselves and comfortable in their ways, they continued wantonly killing patients who could have lived — including President Garfield.

    Antiseptic techniques and Software

    What can possibly account for this behavior? I know one answer, because I see the equivalent in software groups all too frequently. Put simply, it's ego.

    Each group, and particularly its leader, is convinced that they're doing the best possible job that can be done, against steep obstacles. They feel starved for resources, pressed for time, but nonetheless performing at a very high level. They are educated, experienced, and feel they've made the best possible choices of tools, methods, designs and architectures.

    Somehow, the leader or someone in the group hears about something new that's supposed to be really effective for tasks like theirs. Maybe they hear about it from some know-it-all who's somehow associated with investors, or someone else they are "supposed" to listen to.

    In my experience, the reaction of the software group is nearly identical to that of the American doctors. Whatever the new thing (tool, method, technique, design, architecture), it can't possibly be as good as what they're already doing. Even when they hear stories about great results, they are deeply skeptical, and are convinced that their own methods are still better. Period. Why, to consider the possibility that someone else is doing things better than they are implies that they are not the best at what they do. Impossible!

    What explains this profound lack of interest? While other factors are sometimes involved (I'll explore them another time), it's hard to discount the impact of human ego, pure and simple.

  • Architect Bjarke Ingels on Software

    The most prestigious role you can normally have in a software group is that of "architect." Bjarke Ingels is a rapidly rising star in the realm of physical-world architecture. So naturally I was on alert when he made an off-hand comment about software.

    B.I.G.

    The Bjarke Ingels Group has built high-profile projects all over the world. For example, here

    2011_2_pyramid

    is a view of a building they're designing in Manhattan. They've made a little movie about it that gives a good perspective view as well.

    A profile about the architect and his work just appeared in the WSJ. While talking about the challenges involved in the project depicted above, he said the following:

    "I like complexity, but I like it in the real meaning of the word, as the opposite of complication," Mr. Ingels says. "In computer programming, you try to transmit the most information with the fewest lines of code. With buildings, it's the same: Complexity is a child of simplicity. You want to create as much quality with a minimum amount of effort."

    This blew my mind: "you try to transmit the most information with the fewest lines of code." It blew my mind not because it's new (to me), but because it's simple, it's elegant, it's concise, and it expresses a deep truth about programming heard all too rarely from people involved with computers.

    What usually happens when "software architects" get involved with software is that more code is written that somehow manages to get less done. They have all sorts of reasons why they think that's a good thing, except they're usually wrong.

    Here's a thought: maybe we should send our software architects to "real" architecture school. If anything like Bjarke Ingels is the result, we'll be better off.

     

  • Layers in Software: Fuss and Trouble without Benefit

    Most everyone in software seems to accept that layers are a good thing. In general, they're not. They take time and effort to build, they are a source of bugs, and make change more difficult and error-prone.

    What are layers in software?

    It's possible to get all sophisticated with this, but let's keep it simple. Imagine that your application stores data, presents some of it to users, the users change and/or add data, and the application then stores it again. Everyone thinks, OK, we've got the UI, the application and the storage. That's three layers to create, and for data to pass through and be processed. This is the classic "three-tier architecture," usually implemented with three tiers of physical machines as well.

    Everyone knows you use different tools and techniques to build each layer. You'll use something web-oriented involving HTML and javascript for the UI, some application language for the business logic, and probably a DBMS for the storage. Each has been adapted to its special requirements, and there are specialists in each layer. Everyone agrees that this kind of layering is good: each specialist can do his/her thing, and changes in each layer can be made independent of the others. We end up with solid, secure storage, a great UI and business logic that isn't dependent on the details of either.

    More layers!

    If layers are good, more layers must be better, right? It's definitely that way with cakes, after all. We know layer cakes are in general wonderful things. In some places, having 12 layers or more is what's done. ArticleLarge

    It's not unusual for application environments to have six layers or even more. Among the additional layers can be: stored procedures in the database; a rules engine; a workflow engine; a couple layers in the application itself; an object-relational mapper; web services interfaces; layers for availability and recovery; etc.

    It's hard to find anyone say this isn't a good thing. Imagine a speaker and a group of software developers. He says "Motherhood!" Everyone smiles and nods. He says "apple pie!" Everyone smiles and licks their lips. He says "layer cake!" 1960 06 22 WR 09-09
    Everyone can picture it, perhaps remembering blowing out the candles on just such a cake. 1959 06 22 WR 05-09
    You can remember as a kid opening wide and biting in to a nice big piece of birthday layer cake. He says "Software should be properly layered!" Everyone gets a look that ranges from professional to sage and nods in agreement at such a statement of the obvious.

    Layers are good, aren't they?

    Layer Cake, yes; Software Layers, uh-uh

    Take another look at the pictures above; you'll notice that cake alternates with icing, whether there are 3 layers or 15. One person makes both. There's a way to make icing, a way to make the cake. Usually one person makes both and assures that a wonderful, integral layer cake is the result.

    It's a whole different story in software. Even though the data flowing down from the top (UI) to bottom (storage) may be the same (date, name, amount, etc.), each layer has its own concerns and pays attention to different aspects of that data. Here's the real rub: when a change is made to data, far from being isolated, each component that touches the data has to be changed in different but exactly coordinated ways. The data is even organized differently — that's why ORM's exist, for example.

    One of the fundamental justifications for thinking layers are good is separation of concerns: you can change each component independently of the others (the same fraudulent justification that lies at the heart of object-orientation, BTW). But this is just wrong (except in trivial cases)! Any time you want to add, remove or non-trivially change a field, all layers are affected. Each specialist has to go to each place the data element is touched and make exactly the right change.

    But it gets worse. Because each layer has its own way of representing data, there are converters that change the data received from "above" to this layer's preferred format, and then when the data is passed "down" it is converted again. If you are further saddled with web services or some other way to standardize interfaces, you have yet another conversion, to and from the interface's preferred data representation. Each one of these conversions takes work to build and maintain, takes work to change whenever a data element is changed, and can have bugs.

    Think it can't get worse? It can and does! Each group in charge of a layer feels the need to maintain the integrity of "their" layer. Those "foreign" layers — they're so bad — they do crappy work — we better protect ourselves against the bad stuff they send us! So we'd better check each piece of data we get and make sure it's OK, and return an error if it's not. Makes sense, right? Except now you have error checking and error codes to give on each piece of data you receive, and when you send data, you have to check for errors and codes from the next layer. Multiplied by each layer. So now when you make a change, just think of all the places that are affected! And where things can go wrong!

    Here's the bottom line: every layer you add to software is another parcel of work, bugs and maintenance. With no value added! Take a simple case, like moving to zip plus 4. Even in a minimal 3 layer application, 3 specialists have to go make exactly the changes to each place the field is received, in-converted, error checked, represented locally, processed, out-converted and sent, with code to handle errors from the sending.

    In Software, the Fewer Layers the Better

    I'm hardly the first person to notice this. Why is the Ruby/RAILS framework so widely considered to be highly productive? Because it exemplifies the DRY principle, specifically because it eliminates the redundancy and conversion between the application and storage layers. What RAILS is all about is defining a field, giving it a name, and then using it for storage and application purposes! Giving one field a column name in a DBMS schema and another name in an class attribute definition adds no value. What a concept! (Although far from a new one. Several earlier generations of software had success for similar reasons, for example, Powerbuilder with its Data Window.)

    It's simple: In cakes, more layers is good. In software, more layers is not good.

  • The Nightmare of Software Estimation

    We make estimates of effort all the time. No big deal. But estimating software projects is a big problem, often a nightmare. Why should software be uniquely difficult?

    Estimating effort is a reasonable thing to want

    How long will it take you to get to the meeting? When can I have the summary report? How long will it take to crank out the press release?

    We ask for and get estimations of effort all the time. It's a reasonable thing to want. If you think something will take a day and the person tells you it will take a week, probably something is wrong, and it's helpful to expose the issue and resolve it.

    Estimating software effort seems like a  reasonable thing to want

    If estimating effort before you start is generally reasonable, it would seem to be even more a good idea when it comes to software. After all, software projects tend to be expensive and take a long time. Worse, they have a nasty habit of running over time, over budget, and then not even giving you what you expected. So it would appear that creating detailed requirements and then providing careful time and effort estimates would be even more advised in software than in other fields. At least then we can track our progress see have a chance to fix things when they go off track.

    Mainstream thinking in software management thoroughly endorses this view. The highest virtue a software effort can have, in this view, is being "in control." A software project effort is deemed to be "in control" when it is working its way up to creating estimates (i.e., gathering requirements, etc.), or logging work against estimates already made and tracking how well the estimates are being met.

    There is a body of work on this subject that is both broad and deep. You may be impressed by this, but actually it's an indication of how difficult giving good estimates is, and how rarely it's accomplished. When projects go badly, get "out of control," the blame is usually placed on the process not being taken seriously enough. Inevitably, people with experience respond to bad experiences by laying on the process deeper and thicker, and making sure the estimates are long enough to account for all sorts of unforeseen events. In other words, even more time is spent on things other than actual programming, and the estimates are padded like crazy — even more so than last time.

    This, in a nutshell, is why programming groups get larger and larger; accomplish less and less; and never do anything new. It's why startups with bright programmers, unencumbered by the ball-and-chain of estimation and process, usually are the ones that accomplish the cool new stuff that programming groups with literally hundreds more programmers cannot.

    Software Estimations are Different

    The facts on the ground are that estimate-based programming leads to no good. How can we make sense out of this? Is programming really that different? Yes, programming really is way different than all those things that are reasonable to estimate. Here are some of the ways to understand this:

    Huge variations in Productivity

    Software estimates are in terms of the work — not the person doing the work. But there are HUGE variations in the productivity of different programmers, more than 10X. So when you estimate that a given task will take ten days, is that 10 days of the 1X-er's time (the 10X-er will get it done in a day), or 10 days of the 10X-er's time (the 1X-er will take 100 days, and the 10-20% of programmers who are 0X-er's will never deliver)?

    Skeptical of this huge variability? Here's a summary of the literature. McConnell concludes, "…the body of research that supports the 10x claim is as solid as any research that’s been done in software engineering."

    Unknowns

    What kills you with any estimate are the unknowns. The newer the kind of software you're developing, the greater the unknowns tend to be. Worse of all are the things you don't know you don't know. If estimating resolved the unknowns, I would warm up to it — but in practice, estimating tends to make everyone feel better about how "in control" the project is, and delay the discovery of the unknowns until a later time, when they are even less convenient, a.k.a. "nightmares."

    How do you discover unknowns sooner? Dive in and start doing the work sooner!

    Requirements Evolution

    You can only estimate if you know what you're building. The more exact the requirements, the better the estimate — or so the theory goes. It's why everyone who's big into estimating is even bigger into requirements, and all sorts of squishy-sounding things like getting all the "stake-holders" on board.

    In the real world, requirements change. Call it "evolution" if you want, but it always happens — worse of all is when the real requirements in the real world are evolving while the project's requirements remain static — in the name of maintaining the "integrity" of the software project, real world be damned! Only in academia (or silo-ed software departments of bureaucracies) are requirements immune to outside-world changes, discoveries made during the project, etc.

    Learning by Doing

    All programming starts with thinking. Thinking about the existing code, the tools, the architectural structure, the functionality that needs to be built and where and how you'll accomplish that functionality in the code. An integral part of this process is exploration — filling in your knowledge of missing pieces as you think things through. In fact, it's hard to separate exploration from thinking; as you think, you discover holes in your knowledge, which you go off and fill, which helps flesh out and evolve your thinking. The more clear and complete your combination of thinking and exploring, the more cleanly, concisely and quickly you'll code it.

    In practice, the best people write and change code as they go through this process. Nothing like trying to actually write the code to clarify the issues with writing it. The best way to discover road-blocks? Get on the road!

    Do the people who create estimates do this? If not, what possible value is their estimate? If so, why don't they dive in and do the work, while everything is in the foreground of their mind?

    Implementation paths

    There is more than one way to peel an apple (what a stupid phrase — who wouldn't want to just eat the darn thing, apple peels are really good!), and there is more than one way to get stuff done with computers. I'm in the middle of looking at some new functionality an Oak company is trying to build. Naturally, many people at the company want to take their existing, comfortable implementation path and apply it to the new problem. It's a good deal of work, involving a DBMS, stored procedures, a couple development environments, some business logic, a rules engine, a workflow engine and some UI designing. There is no doubt in anyone's mind, including mine, that the existing tool set can get the job done.

    But there's another implementation path. The functionality is pretty simple, basically offering choices to consumers and getting them to fill in fields, with some branching and edit checking. The whole thing can be done using documents, XML and javascript, with a highly responsive UI. Taking this new approach would require a tiny fraction of the effort that using the existing implementation approach would require. Anyone involved can see it. It meets the inter-ocular test. Is it being warmly embraced by everyone at the company? Of course not!

    A kind of estimating causes me to strongly prefer the new implementation path — I'm sure it will be a lot less work, with results that will be more pleasing to consumers. A sense of estimation is indeed important, as one of the factors that helps you choose the optimal implementation path for getting a given job done.

    Moore's Law

    The software approaches and implementation paths taken by most companies for getting their work done were established many Moore's-Law-generations ago, when computers were 10, 30, or 100 times slower and/or smaller and/or more expensive than they are today. For example, most programmers continue to think in terms of databases, when Moore's Law has changed the game for databases and for storage.

    It is far more fruitful to figure out how to take advantage of changes like this than to put effort into estimating the work using what are likely to be obsolete paradigms for building the software. And the best way to accomplish this is usually to try it.

    Conclusion

    Asking how long something will take to program seems so reasonable, so innocent. Who would ever guess that it tends to start a cascade of disastrous consequences?

    The truth is that estimation does play a role in good software development, but in a completely subsidiary way, as a minor aspect of your technical and conceptual approach to building the software. It's like running a race: yes, you have in mind your past times, but if you ever get into making estimates and then padding them and then judging success by hitting your estimated time, you're going to lose the race. It's just not what winners do. Winners focus on … winning!

  • The Cloud and Virtualization

    I've long been impressed by the cancerous power technical terms have when they become fashionable. "The Cloud" and "Virtualization" appear to be setting new records for meaningless ubiquity in a crowded field.

    Setting new Records

    When terms like Cloud and Virtualization appear in Dilbert, it's like getting a "Best of Reality TV" award: they've made it to the rarified elite of complete vacuousness.

    Dilbert 5-25-2012

    Technical Fashion

    People throw around buzzwords all the time when talking about technology. It's necessary and unavoidable.

    By some process that I understand as well as I understand clothing styles, some buzzwords descend below the level of providing a convenient short-hand for some well-understood thing and enter the hell of fashion. Starting life as useful buzzwords, they morph into buzz-fashion-words, lose any meaning they had, and become obsessions for everyone who feels they need to be touch with the latest stuff.

    How the Devil Does his Work

    There is usually a marketing side of Buzz-fashion-words. Perfectly useful terms don't turn to the dark side without lots of help. I would love to be able to channel C.S. Lewis and write a Screwtape Letters for Buzz-fashion-words, exposing the process of commercial interest and personal technical insecurity that leads innocent, useful words like "Virtualization" to be the "it" thing.

    The Cloud

    I've already talked about "The Cloud," the hottest thing in corporate data centers with the possible exceptions, of course, of "virtualization" and "Big Data."

    The Cloud is an interesting case of a buzz-fashion-word that is like a magician's misdirection technique. The consumer internet has long since adopted a set of flexible, cost-effective techniques for delivering services to their customers. The people who work in corporations are also consumers, and are exposed to the ease and convenience of these techniques. They notice that consumer internet services follow different rules than the ones imposed by corporate IT, for example about the release process. They naturally wonder why they can't have the same. Over time, the wonder moves to requests which finally become demands. Corporate IT, years late, feels they have to respond. The result: "we are migrating our corporate data center to The Cloud." The Cloud, in this case, means "our name for what the consumer internet has done for years, but by giving a catchy, trendy name, we hope we'll trick you into thinking we're ahead of the curve instead of pathetically clumsy and slow." A classic case of misdirection by people who are anything but magicians.

    Virtualization

    Everyone knows what virtualization is. When I'm standing in front of you, I see the physical you. When I look at a picture of you, I see the virtual you. It may look real, but it's not. The latest in 3D movie technology makes such virtual reality more effective.

    Computers are all about virtualization; computers are layers and layers of virtualization. The machine language of a computer is itself a phantom creation; the languages we write in all use a "virtual computer." The inexpensive part of computer storage, the physical devices, have layers of virtualization on the inside, and present an interface that the upper layers that use it like to think of as being "physical." In computing, virtualization is everywhere, and always has been.

    In that context, what is this hot new trend, "Virtualization," that often appears together with "The Cloud?" I've gotten bored with torturing the people who use it by asking what they mean. Sometimes they mean a software product (for example, VMWare) or a Storage Area Network (virtualized storage) but they're trying to be fancier. Sometimes they mean "you know, that thing that everyone agrees is a good thing." You get the idea.

    Technical Fashion Words

    I've got to grow up. I've got to exercise discipline. Launching into lectures when buzz-fashion-words are slipped into conversation by innocent, otherwise intelligent people does no good. There is nothing to be gained by snarkiness.

    I've decided to focus on the word "nice," a completely vacuous word signifying a vague, positive attitude.

    From now on, when I hear a term like "the Cloud," I will translate it mentally to "nice," so that I too can smile and think positive thoughts. "We're migrating our data center to the Cloud" equals "We're making our data center nice." "We are experimenting with virtualization" equals "We're trying to be nicer and it's working well."

    What's not to like? Isn't that nice?

  • I’m Tired of Hearing about Big Data

    I've already complained about the so-called Cloud, and I thought that would get it out of my system, but I've had it — I'm up to here — with blankety-blank "big data."

    "Big Data" at the Harvard Library

    The Harvard Library system is REALLY BIG. Here's Widener Library:Widener_library_2009
    Widener has 57 miles of bookshelves with over 3 million volumes. But that's just the start. The Harvard University Library is the largest university library system in the world. There are more than 70 libraries in the system beyond Widener, holding a total of over 12 million books, maps, manuscripts, etc.

    Here's the news: Harvard is putting it on-line! Well, not the actual books; there are little details like copyrights. But the metadata, about 100 attributes per object. According to David Weinberger, co-director of Harvard's Library Lab: "This is Big Data for books." A blog post described a day-long test run during which 15 hackers worked on a subset consisting of 600,000 items and produced various results.

    Pretty amazing, huh? That's at least a couple miles of books!

    "Big Data?" Give me a Break!

    Apparently, no one does simple arithmetic anymore. Maybe it's the combined impact of reality TV shows, smartphones, global warming and Twitter. Who knows?

    How much data does Harvard have? 12 million objects each with 100 attributes is 1.2 billion attributes. When I first started thinking about this, I gave generous estimates of the size of each metadata attribute. Then I got skeptical, dug a little, and found the actual data set. As of this month, there are 12,316,822 rows in the data set, with a compressed data size of 3,399,017,905. In case that appears to be a big number to you, it's less than 4GB. 

    4GB. Your smart phone probably has more than that, and your iPad certainly does. The laptop computer I'm using right now has more than that. Yes, yes, the data is compressed. How much will it be uncompressed? I could find out, but I'm lazy, and the answer in the very worst case is going to be about the same: a very small amount of data.

    "Big Data" usually isn't

    The reason I'm really tired of hearing about Big Data is that, in the vast majority of cases, it isn't big. Not only isn't it big, it's usually kinda small. So the people who talk about it as "Big Data" are either stupid or they're liars. Either of which make me irritated.

    My acid test for whether a data set can't possibly be described as "Big Data" without embarassment or shame is whether it fits into the memory (as in the RAM-type memory, forget about disk) of a machine you can buy off the web for less than $15,000. These days, that's a machine from (for example) Dell that has about 256GB.

    This machine from Dell will fit more than 50 copies of the Harvard Library data set. Who cares how big it is when uncompressed? Loads of copies of it will still fit entirely in memory.

    Do not say "Hadoop" or "clusters." If you do, I swear I'll slap you.

    Conclusion

    The conclusion is obvious. Don't even start thinking the phrase "Big Data" unless you've first applied some common sense and performed some simple arithmetic. Definitely don't utter those words around me without first having applied the sobering tonic of arithmetic. And wake up and smell reality: "Big Data" and "Cloud" are little more than words that vendors use to trick unsuspecting victims into spending money on cool new things.

    Then, of course, maybe you really do have big data — like objectively, unusually BIG data. That's cool. It's easier to work with and get value out large data sets than ever before, and I hope you can use the latest, most productive methods for doing so. Some of the Oak companies are doing just that, and it's exciting.

  • Paul Simon, Wynton Marsalis and Music from the Realm of the Invisible

     

    I attended a concert featuring Paul Simon, Wynton Marsalis and the Jazz at Lincoln Center Orchestra, a couple days after hearing Philip Glass talk about "where" music is. Wynton made strikingly similar observations

    Just looking at him, seeing him move and listening to him, I wouldn't have believed that Paul Simon was over 70 years old.

    Paul_simon--300x300

    At the end of the concert, Wynton Marsalis (below on the right) publicly thanked Paul Simon

    Aaron_Neville__Paul_Simon__Wynton_marsalis__JALC__NYC__4-12
    (photo credit)

    for his participation and wonderful music. The musicians had had an amazing time collaborating, infusing various jazz flavors into Paul Simon's compositions.

    Among other things, Wynton said that music comes from "the realm of the invisible," a place where emotions and thoughts are — and also love. For "thoughts," I heard "thoughts like math and computer software."


  • Where does Software Come from? What is Software?

    What is software, anyway? Where does it come from? It is very reasonable to compare a computer program (i.e., software) to a music program (i.e., a musical score). The eminent composer Phillip Glass says that music is a "place," a place that once you've been there, you want to return. I'd say the same of software: it's a "place."

    Philip Glass and Music

    I attended a conversation between Chuck Close and Philip Glass at the Metropolitan Museum of Art last night. At the end of their informative and entertaining conversation (for example, I didn't know that the sculptor Richard Serra — here's one of his steel sculptures, with a person in the picture to give a sense of scale —

    2011 11 17 Richard Serra M 001
    was close to both of them, employing Glass at one point), an audience member asked Glass how he got started in music.

    Glass replied that he started "getting serious" about playing music around age 8, when he started wondering where music came from. He thought that if he played and composed a lot, he could find out.

    Decades later, he still didn't know where it came from, but started wondering what music is. He said that without thinking about it, an answer popped out of his mouth the other day: music is a place, a place like St. Louis or Chicago. It's a place that, once you've been there, you want to go back all the time.

    As a programmer and music lover, his comment resonated with me.

    Music and Software

    I'm far from alone in feeling music and software (not to mention math) to be intimately related. We write software, a time-sequenced set of instructions, that a computer later "performs." We write a score, a music program, a time-sequenced set of instructions, that musicians or a computer later perform. While music appeals more to the emotions and software to our thinking, both are abstract, mathematically precise, abstract representations that human beings can create.

    Donald Knuth, for example, is one of the deep greats of modern software, author of the multi-volume Art of Computer Programming. Here is one of the instruments in the music room of his house.

    Organ
    While Knuth "executes" many "music programs" like this (the main theme of Bach's Art of the Fugue):

    540px-Kunst_der_Fuge_subject.svg

    on his pipe organ, he reads and writes many computer programs like this

    MMIX
    in the rest of his life.

    Software is in a Place

    Software is in an abstract, conceptual space that I can't see with my eyes, but which I experience visually as a place. When thinking about Glass' comment about music, I remembered describing some software in a small group. While describing it, it was present to me in the space between us. I used my hands to indicate where a proxy server was, in front of two back ends, which I indicated, one with each hand. I reached out to show where a browser was, pulling my hand in to where I had shown the proxy to be as the request came in, and then showing how the request could be passed on to either or both back ends. I was seeing everything static (code waiting to be executed) and dynamic (data flowing through blocks of code) happening at a place in space.

    All my thinking about software is highly visual in this way.

    Conclusion

    Music and Software are intimately related. They touch a lot of the same things in us. While I can't say just where it is, I think that software, like music, is in a place — a place not too far from the place where music is. They are places I've spent a lot of time, and they feel comfortable.

  • A Simple Framework for Software Quality Assurance

    Software Quality Assurance (QA) has grown wildly complex and specialized, while at the same time becoming increasingly ineffective. It's time to question a couple key assumptions and to establish and simple, clean, unifying framework to get the results we want from SQA: "get it right" and "keep it right."

    Software QA Today

    There's a huge amount going on with software QA. For example, the American Society for Quality has a Certification for Software Quality Engineer.The test has about 160 subject areas. Here is a sample of just four of them:

    ASQ
    On one of the many websites devoted to software QA, I found links to over 100 recommended books.

    Books

    Assumptions

    If you accept the assumptions about software development that underly most modern QA, it doesn't seem completely insane. However, I challenge several of the core assumptions.

    It is a historical fact that much of modern software development theory, including QA, is based on the notion that building software is somehow like a manufacturing process. There are a couple edge cases in which this assumption is useful; but for the general case, it's just wrong and should be discarded.

    It is similarly clear that most modern software development theory, including QA, is based on the notion that the root fact of software, the fact from which everything else grows, is a set of requirements. There are important cases in which this assumption is useful (a large number of them are algorithms, think Knuth); but for most software, it causes more trouble than anything else, and should be forgotten like a bad dream.

    Finally, much software is developed with the notion of predictability as central. This is a choice organizations make. If they want predictability, let them have it; it's a valid (if mostly brain-dead) choice. But for most of the software that makes a difference, speed is more important than predictability.

    Instead of these assumptions, it is more fruitful in most cases to assume the following:

    • Software is primarily a design process
    • The requirements of the software evolve as you build it
    • Speed is more important than predictability.

    Core Software QA Function: Keep it Right

    "Keep it Right" is one of the two major categories of software QA. It has its own distinct methods. It can and should be largely automated.

    The core, transformative observation here is that your software need not (yet) be correct. When you alter the software, the main thing you want is to avoid changing its behavior (except as intended). The killer in all regression testing software is that you have to go function by function and write scripts to make sure the "right" thing happened. So your work is proportional to the size and complexity of your program.

    Once you understand the role of "Keep it Right," you see that all you need to do is compare what the software did before with what the changed version does. There are always way to accomplish this. The key observation here is that writing comparisons (think diff) is something you do just once, for the point at which the differences in the software are being compared (for example, the UI or the DBMS). So your work is independent of the size and complexity of your program.

    The key method of "keep it right" is to replace "correctness testing" with "comparison testing." This can be completely automated; it reduces programmer overhead; and it does what users do, viz., ask the question "what's different?"

    Core Software QA Function: Get it right

    "Get it Right" is one of the two major categories of software QA. It has its own distinct methods. It cannot be automated to any significant extent.

    Scripts or automation of any kind are irrelevant to "get it right." Instead of having product people write requirements that someone down the line eventually turns into test plans and test cases, the people who would normally write requirements watch the software's behavior as it grows in capability and guide its development interactively. They see whether this iteration of the software does what they expected, and they also watch their own reactions as they use it, learning from those reactions. Outside people may also play a part in this process.

    Meanwhile, of course, "keep it right" is running all the time, assuring that only forward steps are taken, and that unintended side-effects are caught so they can be corrected. Once the new round of changes have been "gotten right," they become part of the base set that is "kept right" using the comparison-based test-for-change method.

    Conclusion

    Keep it Right and Get it Right alter the organization, methods, work and results not just of QA, but of the entire software-producing organization. They change who does what and how they do it. When done reasonably well, they align quality efforts with customer expectations, which nearly always are based on the hopeful assumption that at least you will avoid breaking what used to work. At least as important, your product managers and programmers can "goal seek" their way rapidly to an effective solution with minimal overhead.

  • How Effective are Software Factories?

    Software factories are truly excellent. They are highly reliable, with an error rate near zero. But here's the catch: software factories may be something different than what you think they are.

    What Are Factories?

    We all know what factories are.

    745px-Airacobra_P39_Assembly_LOC_02902u
    A factory is one of those big plants where parts and assemblies go in one end, and through a series of steps, get turned into finished goods.

    Factories have played a major role in creating the modern world, by magnifying the effort of humans with machines and power.

    What are Factories Conceptually?

    The purpose of a factory is to produce identical copies of a thing you already have and know how to build. Henry Ford's factory didn't produce the very first Model T — his design engineers did that.

    692px-1919_Ford_Model_T_Highboy_Coupe
    Then they created a factory to churn out lots of copies of the original Model T. Everyone credits the Ford factory with producing cars at low cost. All factories accomplish their core function of producing copies at low cost by replacing labor with machines, and by reducing the amount and the skill of the remaining labor.

    In addition, huge amounts of effort have been poured into factory cost-effectiveness and quality. Supply-chain optimization (how to most effectively get the inputs to a factory) is well-understood at this point. Similarly, both the theory and practice of factory output optimization is highly advanced. Methods for assuring consistent high quality have also been developed, starting for example with statistical process control.

    The Dream of the Software Factory

    We all know that software departments aren't very good at churning out great software. Wouldn't it be great if we could build a factory for software — a factory that spits out great, high-quality software, on time and on budget, just like all the other factories?

    No need to dream — it's been done! There are big companies behind these factories, there are lots of books about how to build them, scary books about how it's being done better in Japan, everything you'd want.

    Of course, when you look more closely, it's all hype. Most software isn't built in that kind of software factory; if it were, they'd have long since taken over software development, and no such thing has taken place.

    The Reality of the Software Factory

    Fortunately, there really is a software factory. It's effective, efficient, and it's quality is so near to 100% that it's not worth measuring. Furthermore, software factories are widely used — they're so much a part of programming life, that no one thinks much about them.

    One of the most widely used software factories is the cp utility. This amazing utility does exactly what a factory is supposed to do — it makes you an exact copy of the thing you want to have. Amazing! This factory is also high adaptable. If you change what it is you want to churn out, it can still make a copy of it.

    I wish the cp utility worked for cars. If it did, I could point it at my car and it would give me an identical copy. I could then make changes to my car, sic ol' cp on it again, and shazaam — a copy of the modified car! Cool! Sadly, cp doesn't work on cars (yet) — it only works on software — though let's not forget it also works on data, which isn't too shabby…

    Factories and Software

    I can only hope that people keep coming back to comparing the process of building software to a factory because computer software is so consistently bad. The motivation must be great indeed for so many people to fall for such an obviously flawed metaphor.

    After all, factories are for building copies of things that are fully known and understood — like Model T cars — things that have already gone through an extensive design and prototyping process. Ooohh — I like that — let's make lots of them! Kind of like the iPhone, right? Foxcon didn't get a call from Steve Jobs asking them to start cranking out iPhones until the Apple design engineers had already designed and built them. That widely-reported last-minute switch of the glass surface of the phone happened after Steve played with the prototype and didn't like it — before the factory started doing its thing.

    So repeat after me: designing is what you do to create the first copy of something; if you like it, a factory is used to crank out copies.

    If you like a piece of software, cp (or the relevant copy utility) is all you need to make a copy of it! The only reason software engineers get involved is if you want something different. For which a "software factory" as properly understood is simply not relevant.

    Conclusion

    There's good news: Software factories exist! They are universally used in the software community! They work: they work consistently; they work quickly; they work flawlessly. Be happy.

  • Field-Tested Software

    When you're at war, your software needs to work — not in the lab, but in reality. In the field! You don't have time to test your software in the lab, and you don't care whether it works in the lab. You need field-tested software. Software that works — in the field — where you need it to work.

    Normal Software QA

    Normal software QA pays lots of attention to the process of defining, building and deploying software. You hear phrases like "Do it once and do it right;" "quality by design;" "we don't just test, quality is part of our process." There are lots of them. They all, one way or another, promote the illusion that mistakes can somehow be avoided, and that we can — finally — have a software release that works, and works the way it's supposed to. This time we're going to take the time, spend the money, and do it right!

    How did that work out for you? Most often, it's like predictions of the end of the world. The date comes, the world is still here, and people try to avoid talking about it. Similarly with that great this-time-we're-doing-it-right release, the release comes, there are roughly the usual problems, and people try to avoid talking about it. Or there were fewer problems, but the expense and time were astronomical. Or there were fewer problems, but not much got released. Whatever.

    Here are some favorite phrases: "It worked in the lab!" "How could we have anticipated that case?" "The test database just wasn't realistic enough." "Joey So-and-So really let us down on test coverage." "We had the budget to do it right, but not enough time." "We didn't have enough [tools] [training] [experienced people] [cooperation from X] [lab equipment]…" Excuses, every one. Perhaps there's a fundamental reason why we always fail?

    This is a subject your CTO and your chief architect should stop ignoring and pay serious attention to. It isn't the only subject, but it sure should be #1 on the list.

    QA Should be Field-Based

    Who cares how the software operates anywhere except in production?? The lab environment is always different from the production environment. And the most embarassing problems are the ones where it worked in the lab but failed when deployed. The number of potential causes is endless; different machines; different loads; different network delays; different database contents; different user behavior; different practically-anything!

    Given this, why wouldn't you test your software on the actual machines it will run on when it's put into production? Of course, you don't load-balance normal user traffic to the test build as though everything were hunky-dory. That's just asking for trouble. But it's not hard to send a copy of the traffic to the test machine. That alone tells you huge amounts. Did it crap out with a normal load? Now there's a real smoke test. And there's lots more you can do as well.

    Conclusion

    Your customers don't care how your software worked in the lab. They only care how it works for them. Yes, that's awfully self-centered, but that's just how they are, and no one is likely to talk them out of it. So live with it, and shift from pointless lab testing and back-office quality methods to actual field-testing of your software. Yes, it's messy, dirty and uncontrolled — but it's real life! It's where your software has to run! Better it should get used to it sooner rather than later.

     

  • The Dirty Secret of Peace-time Software Development

    We use a large number of intimidating words and abstruse concepts to make our software development methods sound like they're highly evolved and refined. But all too often they take way too long to produce software that doesn't work and isn't what we need.

    The Propaganda

    The normal, "peace-time" process of software development sounds pretty deep. There are requirements.

    Req

    There are designs.

    Design

    There is all sorts of testing to assure quality.

    Test

    That's just for a start — there's loads more.

    And on top of it all, there are levels and levels of analysis to assure you've got a repeatable process that is documented, measured, and continuously improved.

    CMM

    The Reality

    When we try to create software in this way, we resemble Dr. Frankenstein in his laboratory,

    Lab
    with his carefully crafted plans to bring something into being that has never before existed.

    And when you've done all that impressive-sounding stuff, what do you have???

    This…

    Monster
    is what you have.

    He's late.

    He cost way too much.

    He doesn't work.

    And worst of all…

    …he's not what you wanted in the first place!

    Conclusion

    The reality is all those software methods we argue about amount to pretty much the same thing. They are all "peace-time" software methods. They promise to be careful and deliberate. They promise to deliver safety and predictability. But they can't! Which explains why, in the vast majority of cases, they don't! That's the dirty secret of all those high-minded concepts and abstruse words — they put a high-minded gloss on incompetence and ineptitude.

  • Let’s Criminalize our Regulations

    Our regulations are a problem, mostly not because of what they're trying to do, but because they tell us how to do things instead of telling us what to accomplish (or avoid). A better model to follow would be criminal law, which clearly spells out what to avoid doing. By "criminalizing" our regulations, everyone (except the regulators) would win: the regulations would be relatively easy to write and understand, and wouldn't need updating very often; they would be short; by concentrating on "what" instead of "how," the regulations would create a climate enabling innovation, instead of today's innovation-crushing impact.

    Here's an example:

    New Jersey Statutes – Title 2C The New Jersey Code of Criminal Justice – 2C:11-2 Criminal homicide

    a. A person is guilty of criminal homicide if he purposely, knowingly, recklessly or, under the circumstances set forth in section 2C:11-5, causes the death of another human being.

    b. Criminal homicide is murder, manslaughter or death by auto.

    L.1978, c. 95, s. 2C:11-2, eff. Sept. 1, 1979. Amended by L.1979, c. 178, s. 20, eff. Sept. 1, 1979.

    Here is the reference.

    The definition of murder leaves little to question. It doesn't need to be updated very often. The statute does not tell you how to avoid murdering someone — it just tells you what murdering is, and leaves it to you to avoid doing it.

    Think about it: with murder defined in this way, we don't need loads of regulators or regulations that somehow always seem to let the truly guilty walk away. Of course, we do need a criminal justice system to track murderers down, catch them and put them to trial.

    Short and sweet! … uhhh, well, anyway it's short for sure.

     

  • Nerds and Autism: Deficiency or Advantage?

    Some of the very best nerds, the Top Nerds, the ones who are superb programmers, share important traits that are identified with that rapidly spreading "disease," autism.

    Recent studies are starting to measure the differences between those with autistic traits and the majority who are mentally weaker.

    …most people regard autism as a disease, a straightforward example of an impaired mind. But there's compelling evidence that autism is not merely a list of deficits. Rather, it represents an alternate way of making sense of the world, a cognitive difference that, in many instances, comes with unexpected benefits.

    That's the lesson, at least, of a new study from the lab of Nilli Lavie at University College London. A few dozen adults, both with and without autism, were given a difficult perceptual task, in which they had to keep track of letters quickly flashed on a computer screen. At the same time, they also had to watch out for a small gray shape that occasionally appeared on the edge of the monitor.

    When only a few letters appeared on the screen, both autistic and normal subjects could handle the task. However, when the number of letters was increased, subjects without autism—so-called neurotypicals—could no longer keep up. They were overwhelmed by the surplus of information.

    Those adults with autism didn't have this problem. Even when the task became maddeningly difficult, their performance never flagged.

    What explains this result? According to the scientists, autism confers a perceptual edge, allowing people with the disorder to process more information in a short amount of time. While scientists have long assumed that autistics are more vulnerable to distraction—an errant sound or conversation can steal their attention—that's not the case. As Prof. Lavie notes, "Our research suggests autism does not involve a distractibility deficit but rather an information-processing advantage."

    It is well-known that history is written by the victors. It is also true that what is considered "normal" is determined by the majority, who simply describe themselves and call it "normal." People not like them are, by their definition, ab-normal or disabled.

    The medical and intellectual establishments have firmly established their views: people who don't interact socially like they do are lacking something important, and must be labeled in a way that indicates the deficiency. There is a simple way to describe people who think this way: they are fools.

Links

Recent Posts

Categories