By Bob Goodwin, an investor and medical device entrepreneur who lives in Mercer Island, Washington
Several bellwether software initiatives have gone off the rails over the last five years. I am going to focus on one, because I learned about it on Naked Capitalism, and is where I first saw the expression “Code is Law”. I hope when history is written, this example will stand out on how the anarchist nerds that we call software engineers inadvertently started to hijack public institutions. More cynically we could believe that the software engineers where just useful idiots to corruption. But conspiracy theories are not necessary for this story, and given the pace of events, I doubt there were smart enough conspirators anyways.
Before we dive into this story, we should keep perspective, as the history of early industrialization is also filled with anecdotes about the overreach of engineers and their subsequent failures. I doubt these stories were widely reported at the time, and I like how industrialization has turned out.
In this story, software engineers summarily rewrote policies that had been in place for centuries, and arbitrarily replaced historical procedures run by clerks, land offices and judges with a buggy central data-base. This is the story of the software used for mortgage securitization leading up to the credit crisis. Property ownership is fundamental to money and credit, which in turn is fundamental to capitalism, and therefore should be treated with great care. There are many examples of societies tinkering with property ownership, only to see their economy damaged in predictable sequences of setbacks involving money, credit, trade and investments.
One of the legs in the credit crisis was how title to real estate, which had served as collateral for individual real estate loans, underwent significant and perplexing changes over time through the process of using large numbers of these loans to create mortgage backed securities. It only became clear after the acute phase was over and more and more homeowners were facing foreclosure that the well established processes for recording and transferring title had become corrupted. This collapse was not due to computer science, nor was the collapse central to the larger crisis. In a normal era, this story might not have gone largely unnoticed. But even with the diligent efforts of lawyers and academics to bring attention to this issue and prevent it from becoming acceptable, official policy was to save the banks from possibly fatal liabilities, which meant papering over problems with mortgage title. Forgiveness was seen as a small price to pay to divert the attention away from the carnage. As a result, the the role of MERS and other “innovations” were never front page news.
But the point of view underlying MERS and the other ways that the traditional, slow, but extremely reliable process of recording title and transferring borrower notes is consistent with widely-held believes in the software industry. Software engineers had long ago decided that paper and humans were inefficient, despite our long history of governments tracking ownership via paper, authority and convention, such that it can be verified by a human judge conclusively later.
I should rephrase this. Software engineers did not know how to control paper, city halls or judges. So they wrote them out of the software.
The consistency of the paper process tended to be a disincentive to bad actors, as they were at risk of being exposed later. Reduction in fraud benefited the regular guy, which is nice, but not the point. Consistency was essential to the capital markets. Moving money is not very profitable per dollar, but is workable purely on the basis of scale. Moving money is also about playing the odds. Some transactions go bad. But the entire waterworks collapses if every bad transaction is contested and inconsistent outcomes occur. Only a nearly frictionless pipeline of money stays open. Twitchy financial types are quick to close pipelines when risks are not understood.
Today if you get a mortgage there is a lien on your house to secure the debt. Every lien is recorded in some government office using paper. Mortgages often change hands because the companies that are best at writing loans are not always the best at managing payments. Other mortgage companies may specialize on troubled loans, etc. Recently there has been an industry of packaging groups of similar loans together to make them marketable as securities.
History may look back on securitization and decide its primary value was to lower transparency and allow the corrupt to sell junk as gold. But at the time they were invented, I am certain there were people who saw the mathematical potential to improve efficiency by creating a secondary market for risk. And just as the mortgage markets needed inexpensive and consistent methods of managing a low margin portfolio, securitization was even lower margin, and relied even more on very high volumes.
The cost of a 19th century paper trail was inconsistent with a high speed late 20th century risk pooling market.
I try to imagine myself in those software meetings that overrode hallowed laws. Triage is a big word in software, because Pareto was taught to us on our second day of work. The 80/20 rule says you get 80% of the benefit from 20% of the work. We only wanted to do 20% of the work. Software types are most gifted and careful in our analysis into costs and benefits, lest we have to start all of our work over again later. The engineer quickly discovers that an individual mortgage has a failure rate of X. And of that X, which is low to begin with, becomes even smaller in practice because only a very few foreclosures are contested, so the requirement for a paper trail is virtually, zero. “Virtually zero” means problems need resolution, people can get on airplanes and negotiate fixes individually for each case. That cost is guaranteed to be far lower than the cost of creating a system that is a complete replacement for the 19th century paper trail. Looking back, I can see an error in the engineer’s analysis. We now know the cost was not anywhere close to zero.
Now the supreme irony is that I’ve depicted the origins of MERS as software engineers gone wild. It’s certainly plausible as history, but what actually transpired is worse. Some people at Fannie Mae, Freddie Mac, Ginnie Mae and the Mortgage Bankers Association looked at how the Depositary Trust Corporation, a system which eliminated the physical delivery of securities on Wall Street by creating a central depository, and thought it would be great to create a version for the mortgage industry. But even though real estate is governed by state law, and has important differences state by state, this group decided they could punt reviewing the state law issues. They’d just go ahead with their new system and the courts would comply. And the worst is that the courts have largely complied, even though the MERS database was built with an absence of protocols considered basic to database integrity, like audit trails and measures to insure accuracy (like dual keying and management oversight). So we got the worst of all possible worlds: management thinking like software engineers (conforming requirements to what looked most useful, rather than replicating an existing process) and whoever did the database part acting like MBAs.
And once this was in place, there was no going back. We are so dependent on software, that noncompliance with software is not an option. As we read the rest of the story, we can see how it came to be that “Code is Law”.
This story is most instructive not on how it happened, but how it was resolved. In the absence of a useful paper trail from mortgage companies, the mortgage companies were found to be retroactively creating a paper trail. Retroactive paper trail is a kind way of saying they forged documents for a court. Sometimes these forgeries were proven in a courtroom to be convenient fictions.
We would like to believe that the courts would have followed the letter of the law. But of course that is not exactly what either the courts or the laws are for, at least in America. The highest goal of property law is to keep money and products flowing in the economy, through efficient and consistent resolution of the occasional contract failure. A literal reading of the law, and a literal interpretation of the facts would have gummed up the economy by doing the exact opposite of its primary goal. Many judges saw this immediately. Rather than follow the written law, most courts effectively accepted that software was some form of common law. Even now, if the offending software were discarded, fixed, or laws are changed retroactively, we now know conclusively that software has the power to veto policy.
This is not the only story like this. We know that no customer can negotiate with anyone who accesses their company through a computer, unless they’ve been granted authority to fix certain problems, and then only in specified ways . Computers don’t negotiate. Code is law. We know that companies can create excruciating telephone experiences for customers seeking redress because code is law. But the mortgage detailed above is a really big deal uniquely because the law that was overruled by code was important and well considered, and courts unambiguously codified the primacy of software over law. In order to return the universe to its proper configuration, laws might be used to regulate software.
Over thousands of years, policies have correctly (or not) guided our use of land and water, built cities, and earned security for civilizations. Two policies in the last century have doubled our lifespans and increased our wealth astronomically. The two policies are energy (drilling, processing, roads, industry and utilities) and public health (clean water and food, work environment, health education). As great as the software industry might believe in its power, it is small in this larger context. Law and policy must always win. Law and policy of course can be inconsistent if one is moving faster than the other. But policy is delegated to men and women who are given this authority by traditions of government forged from blood.
Loss of confidence in our institutions comes at great cost, and I see the failure of the failure of Healthcare.gov, and what it means to both software and law going forward, as having the potential to reduce low levels of trust in our government even further.
Keep in mind loss in confidence in our institutions is not that rare. I am barely old enough to remember the campus riots during the Vietnam War, but plenty old enough to remember the malaise that Jimmy Carter spoke of. Three consecutive events occurred in the same decade that each spoke to the incompetence or impotence of the federal government: the war itself that ended in 1973, the oil shock, with America reduced to rationing, and inflation, which brought 19% mortgages and virtually zero improvements or repairs to any asset with a long life.
It is a stretch to impute a line from OmamaCare having problems to a great malaise. However every consequence of the 1970s flowed directly from the inability of our federal government to implement its stated policy. Failure begets failure. The 1970’s object lesson speaks to why we should all be adamant about competency of government to achieve stated policy.
The first casualty of cascading failure would be liberalism. But only temporarily. Even though I am not a liberal, the shining example of liberalism is its tradition of proactively building social institutions, from activism against slavery and before that institutes of education. In this century much of the growth in the federal government was a direct extension from a long history. It is certain that hunger to expand institutions will be diminished when a straight forward policy is achieved at great cost politically, and then cannot be implemented. But while I hope the lesson will shift liberalism toward more competent institutions and away from pure resource diversion, liberalism will likely prosper so long as it adapts. There is no activist alternative to liberalism today (although I see candidates), so the only way liberalism falls is through repeated examples of social institutions that aren’t successful, and are mostly used as organs of corporatism.
The second casualty will be confidence in the public sector, and that has been under long term attack. I fear this outcome the most. We fairly get angered at incompetence in the public sector, mostly because it is funded from taxes without recourse. We also get angered at all other incompetence, but somehow separate the anger into different compartments. And I don’t think viewing the public sector as incompetent is fair.
Public employees are passionate, hardworking and committed. I definitely trust public institutions to collect taxes and fight wars, and prefer to buy commodities from private institutions. Public and private models have different sweet spots. Public employees are my neighbors and friends. I talk to them. I hear about their challenges, struggles, and goals. They seem like passionate, hardworking and committed Americans. Education, crime, and war are managed imperfectly, but better than ever before, and amazingly well considering the obstacles and a lack of money based incentives. But public employees have also seen great improvements in both efficiency and accountability without this mechanism. When there is confidence in an institution, good intentions are transmitted.
Most institutions, public and private have exasperating and obvious failures, due to forces that work in opposition to good management. But the net of all these forces we usually end up with functional public institutions that mostly differ from their private counterparts in their slower rate of adaption, higher expectations of conformance, and greater interest in individual outcomes. Government employees did not mismanage a software project because they had poor skills. Software engineering has always been an obstacle to the top down propagation of policy. It has been hard for every industry that has used it, but government has found it hardest to adapt.
ObamaCare may fail, and it is possible that it will cause a chain of other bad outcomes. It seems more likely that any means necessary will be used to avoid that scenario. By placing this principal as first, many possible outcomes can be dismissed as unlikely. Political fix that enables the Obamacare law to achieve the minimal acceptable outcome (large reduction in uninsured, pre-existing conditions cannot prevent insurance) would ordinarily be the obvious remedy, but since this law was voted along party lines, that path may be closed.
Doctors, hospitals, and insurers will all resist disruption. Fixes to the law will impose new costs on all of them, since they’d already planned for Obamacare as first written. The Administration has gone from treating the insurers and Big Pharma as its real clients to being more willing to show some muscle as the possibility of failure looms.
The tough part is patients, or as the Administration likes to call them, consumers. Government cannot coerce the population as easily as it can institutions. ObamaCare is definitely losing ground in public perception. To oversimplify perception, all the opposition needs is for something fundamental to be going wrong that people can easily relate to. Once they have public attention, it becomes a lot easier to drive wedges such as “He lied that I could keep my coverage.” If we ever get to the point where virtually everyone knows someone who has a bad story to tell about the law, then public attention could last indefinitely, a health care version of the Iran hostage crisis, which sapped Carter’s waning credibility. There are plenty more wedges that opposition can drive, such as when a debt ceiling debate includes “He lied to us about taxpayer liabilities from Obamacare.”
My belief is that absent the public attention, Obama could have finessed all the challenges. The perception of incompetence has to be eliminated, preferably by eliminating the incompetence. The perception and the fact of incompetence is attributable to the software. It may be necessary to abandon the website completely, but this really solves nothing. Computers are still needed to determine eligibility, and insurance companies will now have to create the same services from scratch that the government has been working on for years. It seems possible that software is what is preventing the success of the law.
And this is where I get really uncomfortable, because even if we pull this one through somehow, there will be another. As public policy is increasingly dependent on information, large policy changes are becoming harder to implement. Headwinds are growing, it is only a matter of time before big policy will be unable to outrun it.
Perversely, policy is similar to software. Both have never ending dependencies, and tame chaos mostly by creating predictability, and less by creating optimal outcomes. Both are prickly professions precisely because tinkering almost always makes things worse. Both are opaque, and both harden like concrete into odd shapes. Both are managed mostly through small actions at the periphery, and are structurally changed only with vast resources and these changes made are motivated by strange alliances of interests.
What is a deeper observation about the intuition is that policy has always be information bound, even from the beginning of time. And the pressures on policy in an age of exploding information are very large. This is the really good news in this essay. Even if the transformation of our society leads us through a valley of despair, we can still expect the long term competence of government policy to accelerate like other parts of the economy. The promise of the power of government policy can be achieved once new principles of information management become part of the institutions of government policy.
Perhaps software engineering was right on this point all along. With enough complexity planning becomes impossible. Only if one distributes accountability and constructs from the bottom can there be any hope of rationalizing all the possible outcomes. Stabalizing pockets of complexity is a requirement before planning what to build on top. The problem of course is that the government contractors implemented bottom up management (they had to use the resources they could get), and then implemented a top down cargo cult for the benefit of the government.
To fix this we are going to start to need to implement policy bottom up within the government, and then demand software industries supply building codes and transparency so that the bottom up policy makers are masters of their software rather than victims. If policy really is like software, additional advantages will accrue to the builders of policy. Bottom up policy making allows experimentation, and allows connected branches of policies to adapt to experimentally discovered optimizations. The organism becomes self-correcting in a way top down systems cannot be. Some top-down features are unavoidable, but the interface between top-down and bottom-up needs to be reconsidered. We need funding, for example, and we need an understanding of how to measure success. This is a difficult management problem, but not unsolvable.
But it would represent radical change in the configuration of public and social institutions. Such changes require confidence, and so the loss of confidence at this juncture would be a particularly costly setback.
There are a few of us who have become the scientists and practitioners of the complexity that comes from massive management of information. It is messy, it is imperfect, and it is far more of an art than a science. I sit in on the side as a software engineer, and gently raise my hand and say “Policy always was software”. “Code always was Law”. We just never realized that before there was software there still was code, executed by clerks rather than machines. Let’s adapt to our brave new world, and create an even higher platform for the human experience, by building more powerful institutions and more passionate professions. The consequences if we fail to do so are costly indeed.
120 comments
Comments are closed.
We have the same issue facing us when one talks about global anything……like governance.
Global government of some sort will continue to evolve in spite of all efforts to stifle it. It does not have to be a bad state if society can evolve past fear, competition and conflict based slavery controlled by inherited global plutocrats and their government puppets and technocrats.
Great article! +1 just for “So we got the worst of all possible worlds: management thinking like software engineers (conforming requirements to what looked most useful, rather than replicating an existing process) and whoever did the database part acting like MBAs. ”
Also, I remember reading from Schelling’s game theory book that one of the best guys to increase your negotiating power is to throw away your telephone. Having to conform to a badly designed computer program is the application of this rule.
Sorry typo. “best guys” = “best ways”.
Throw away your telephone so that the other party can’t reach you?
How does this strengthen one’s negotiating position?
It’s explained in Schelling’s book.
http://www.amazon.com/The-Strategy-Conflict-Thomas-Schelling/dp/0674840313
It’s a very fundamentalist rational actor game theory view of the world. Like in Dr. Strangelove. An equivalent is playing a game of chicken and visibly throwing out the steering wheel.
Or in a game where you text someone on picking a meeting place, sending them a message that you’ll meet them at X place, and then sending them a message that you’re going out of the service area.
Having a badly designed computer program lets you tell people, oops the computer doesn’t accept it whenever you don’t like their response. You purposely handicap your own ability to respond.
Elites often hire negotiation agents precisely to make it more difficult for you to reach them. Personal assistants, gate keepers etc.
Customer service lines which put you on hold indefinitely is another application of this. As is outsourcing to Indians who don’t speak English well and don’t know your situation.
Code is perfect for this role. The worse the code the better, especially if you believe TINA.
Thank you for the link and the explanations.
I think you miss the whole issue with MERS which had nothing to do with SW engineering. Bankers saw an opportunity to get filthy rich playing hocus-pocus with fraudulent sub-prime mortgages. They needed to transfer them around at the speed of light so the rating agencies had cover to play dumb and the eventual buyers who not see what was really going on. It would have been impossible to accomplish this legally following centuries of state laws and processes so they just ignored it all and proceeded illegally, leaving the rest of us to clean up the mess. Homeowners whose title can be traced for centuries at town hall now don’t know who owners their mortgage and can’t document when they have paid it off. Bond holders are in a similar mess and the bankers are happily spending their massive bonuses not a single one in jail. Blaming the engineering is another magician’s trick to distract the gullible from what is really happening.
EXACTLY
Agree. MERS software was used to redefine property. Turning it into a commodity to be traded faster and more easily. Securitized to make it legitimate but fraudulently “secruitized” and intentionally abused. If MERS was designed to be another Depositary Trust Corporation – a place to record security transactions and ensure those transactions – then MERS failed completely to do this. Total failure. If it wasn’t intentional fraud and money laundering using a very convenient asset – property – then it was just sloppy alchemy. Changing houses into commodities and trading them in all sorts of securitized instruments just so banksters could make large fees. Nothing else mattered. Title? What’s that? Let’s not talk about anything so old fashioned as a land registry. The MERS debacle could be unwound easily. Whenever a party cannot prove their interest their claim is judged to be of no effect. Null and void. That means a universal declaration by state courts that if any mortgage has been in the MERS system it is void.
You have the history of MERS wrong and Bob’s account is accurate.
MERS was not designed by “bankers”. It was promoted by Fannie, Freddie, Ginne and endorsed by the MBA. The goal was to replicate the Depositary Trust Corporation.
This was not about “game playing” It was about streamlining processes to achieve the end goal of getting rid of 1. paper and 2. the need to go to the courthouse every time a loan was sold.
Now as we know they just steamrolled existing law. But this is EXACTLY the mentality Bob describes software engineers as having, even though they don’t like admitting that to themselves, of forcing processes to fit what is convenient from a technology perspective.
And if you look at the paper, it was about “whole loan sales”. No mention of securitization. Why? After the S&L crisis, the Resolution Trust Corp. had the assets of a ton of S&Ls on its hands that were mainly mortgages. These had been transferred to the RTC and then to new buyers. Servicers made up all sorts of procedures on the fly to deal with the paper mess. The idea was to prevent that from happening again.
And BTW Bob has spent pretty much his entire career in software, back to leaning how to write software as a kid in the 1970s and recently working in senior roles at companies like Amazon. So he’s not an outsider, he’s seen this pattern repeatedly over the years from the inside.
“But this is EXACTLY the mentality Bob describes software engineers as having, even though they don’t like admitting that to themselves, of forcing processes to fit what is convenient from a technology perspective.”
Actually software engineers very rarely have the power to “force” anything. They may at best have a *preference* for automating, for digital storage, for simplicity over complexity in design etc.. But they usually take (not give!) their orders from “the business” which is the non IT parts of the organization which yes are generally held in higher esteem in the organization than I.T. is (I.T. are big fish in small ponds, heroes in their own minds).
If the business actually bothered to say jump, the software engineers might have grumbled and thought it silly but they would have jumped as high as asked. A simple but non-negoitable requirement (just a requirement) that there be a paper or audit trail would have eliminated that.
This is why I wrote the two previous posts to show the how software types end up having large impact on outcomes not because of laziness or ideology, but because it is hard, they prioritize their work based on effort and what they think is the value, and when projects get unwieldy, everyone lives with what exists. There is lots of good software, but most software in finance has a lower reputation. There is a lot less control than anyone realizes, and engineers steer the boat as best they know how, and then it ships. So yes, managers have the power and the money, and engineers try to comply. Yet somehow things come out differently.
You have avoided stating that it is NOT the software writers who decide, it is the managers who write requirements and budgets, and who write acceptance of whatever is delivered, who decide.
Bob isn’t the only guy who has spent his life in software development. His opinions are no doubt informed, but not necessarily correct in all circumstances.
“But this is EXACTLY the mentality Bob describes software engineers as having, even though they don’t like admitting that to themselves, of forcing processes to fit what is convenient from a technology perspective.”
In a lot of cases, software engineers do NOT get to pick what is convenient – they get to pick what is POSSIBLE within the constraints imposed by management and MBAs who have no real understanding of software – or of their own business model.
No matter how you try to justify it, B-school should teach you that you can delegate authority, but you can’t delegate responsibility.
I shouldn’t have to explain the gory details of what that means.
In general, management keeps all of the authority and thinks they have delegated responsibility. And sometimes they even manage to convince those who should know better.
You can’t blame the software engineers for this. It is up to state courts to apply state property laws. Outside groups, whether they are software engineers or martians, can only impact how security interests in property are enforced if the courts will let them.
Yes possible is a better word than convenient. However there is a gradient between. I would choose the word tolerable, but any word is subject to perspective.
Doesn’t this come down to black box educated guesses without interviews of parties directly involved?
It sounds like the reality could be a number of different angles.
I spent 25 yrs. as a software engineer in development and with all due respect, what Yves is saying here is nonsense. In large part maybe that comes from looking at large IT consultant firms and calling everybody who works there ‘software engineers’. Total nonsense, and slander to the actual engineers who build the systems vs the sales guys and management sell first of all (often with a lot of lies), and are then passed on to the business analysts who derive the detailed system requirements before any actual software engineers are brought on board. Posters like Larry Barber, fritter and others above have already explained this in great detail.
[ad hom. –lambert] Also note that ‘I started coding as a kid’ is a _very_ stupid way to back up your claim to be an expert engineer. Don’t put a complex business in a black box and then repeatedly blame the wrong professionals. “software engineers” are a subset of the IT business. They build the systems but they don’t own the business requirements – very few, if any are involved in that phase of the project. [ad hom –lambert]
I am a sw engineer and i followed the MERS scandal very close and shorted housing and mortgages since 2005. i also agree. I don’t understand what this is all about. The engineers are responsible for the housing bubble??? No way. Bob is over complicating and his post is all over the place. Management is responsible at fannie freddie wall street etc. Management is responsible. When an investor analyzes a stock they analyze management as part of it. Have you evr seen an investment thesis that included an analysis of the engineers who work there ??? Come on…
“The highest goal of property law is to keep money and products flowing in the economy, through efficient and consistent resolution of the occasional contract failure.”
This sentence encapsulates the whole theory behind the “law and economics” movement and how it has perverted our view of the law.
The highest goal of property law is to determine who owns the property any particular item of property, who can use it, and how it can be used. The pieces of paper (or lines of code or whatever) are mere evidence.
At least as far as real property is concerned, ownership rights are established by registering it with the government: filing real pieces of paper with a registrar. Those pieces of paper are conclusive evidence of ownership. Period. That has been the law for centuries.
By all means, let’s make the system more efficient. But don’t lose sight of the basic purpose of the law.
Law and Economics is about efficiency and common sense. Like everything else, it has been coopted. Efficiency can obviously be used to further bad goals and not just good ones.
This series might be the best item that NC has put up this year.
And that’s saying a lot.
+1
I have read this series of posts avidly often nodding my head to the points made, however I found myself in a little disagreement with one or two points in this post.Generally speaking software engineers do not decide that paper and humans are inefficient, rather it is business or government who request the software who decide. Software engineers view software as a means to free up workers time from mundane repetative tasks so that they can use their time to perform tasks which give greater flexibility and service to a product. It is management or policy makers that decide how to deploy workers in conjunction with software (often wrongly in my opinion).
Any business process or transactional software should have input from people with expertise in that particular field, whether it is initiated by a software provider or by a business or governmental department. MERS seems like either the expertise was not consulted or ignored.
Where I think the article is right is in architectural design of software. Quite often software is seen as an extra cost, rather than a competative advantage or a means to improve service. This means the architecture will be as lost cost as possible to meet the stated objectives. When the objectives in terms of availability, volumes of usage, supportability are always vague then inappropriate architecture tends to get used.
One area perhaps not covered in this post is the concepts around modularisation and ease of build. This can lead to decisions and actions being coded as modular descreet steps. The software user can then get frustrated in the multitude of steps, when they just want the software to go away and do it all in one step (ObamaCare). A software engineer will want to think of modularisation at three different levels, the presentation layer, the business or transaction layer and the data store layer, but because cost reductions can be made by aligning modularisation through all three levels, software is becomming ever more throw away and obsolete very quickly.
Changing software so that policy makers are masters of their software rather than victims is a double edged sword. It is possible for software to be compromised due to that one little piece of functionality or performance that the policy maker fails to mention early enough which changes the software architecture you would select. More often that not you will end up with a fudged solution to meet a deadline.
For me one of the biggest reasons for software failure is that information about a process has been lost over time and policy makers dont understand the detail. More specifically the interactions between specialists or departments. Its all the little decisions that make the difference between good and unusable software. For instance a simple requirement like a zip code should be validated on entry, requires thought about whether the software could be used globally, where do you source the list of valid zip codes from etc.
Code should not be law, but to facilitate that a revolution is required in the way we think about decision making and processes. Policy makers need to think about not just the individual processes, but how they combine, who owns which data, what is the service level, usage and the flow. If you leave a software engineer to assume he might well assume wrongly or make a low cost solution. Today its almost impossible to really gets to grip with how a department interacts with others or what data from other functions it depends on, such that software is increasingly becoming the glue between functions.
Perhaps bad software is a canary in the mine, highlighting short termism in business, incomplete understanding by policy makers, a fetish with low cost, everything compartmentalised so nobody has a complete view to tell software engineers how it should all fit together and that big undetailed decisions whether right or wrong are worth more than the millions of smaller ones always done right such that software engineers never get the detail they need.I am not necessarily disagreeing, just that the constraints surrounding software engineering can make success all the more difficult.
‘… .Generally speaking software engineers do not decide that paper and humans are inefficient, rather it is business or government who request the software who decide. …’
Yes, definitely. And computers, mechanization in general, paper, and humans (doing prescribed bureaucratic routines) are various phases of industrialization, just like standardization and mass production. In bureaucratic procedures, a mature manual system may have developed a large number of rather Byzantine details which cannot easily be abstracted and mechanized, yet the owners and managers of the system demand that it run much faster and more ‘efficiently’. The ‘software engineers’ solve the problem by eliminating them from the new system, which then can be expected to exhibit the defects which the Byzantine details filtered out or mitigated. Many, many war stories available on request. There is a crisis, and then the enterprise stumbles forward anew.
The idea that anarchistic ‘software engineers’ are playing at revolution and rewriting laws and regulations for the hell of it can be entertained only by people out of contact with the facts of situation. Most ‘software engineers’ are people receiving a wage or fee for doing what they’re told to do.
This sort of thing doesn’t seem to be studied much in academia, but it’s an important part of the industrial history of the last sixty years or so, at least.
I think you missed the point of the series. I was definitely poking fun at engineers, because I am one, and everyone takes themselves too seriously, but I hope if you had read the previous pieces you would detect that I hold my fellow engineers in a higher regard than any other. It is an art to manage the level of entropy that is being thrown at technology. Lets hope we are up to the coming challenges, because it is getting harder. The other tone I tried to use breathlessly through-out was blamelessness. Everything can be understood because the industry is adolescent and because everyone just responded to situations the only way they knew how. Failure does not require corruption, and incompetence does not require stupidity. The tricky part of the argument was summarizing ‘where we are’ and ‘what to do about it’, and without Yves this piece would not have worked.
So the mortgage crisis was caused by a cabal of software engineers? Really? Engineers only build what they’re requested to build by their managers. This entire overly-verbose series of chest pounding and pontification really misses the point if the blame is being placed on the spear carriers. I notice that its not written by someone who is an actual software engineer but an “investor and medical device entreprenuer” – just the type that is really responsible for commissioning projects like MERS and HealthCare.gov.
I don’t give the engineers who willingly participated in building MERS and didn’t blow the whistle a complete free pass but I would point out that most of them were probably only doing what they needed to do to earn a living and our society and institutions are not kind to those who try to expose the truth about socially damaging activities that benefit those in power – ask Edward Snowden.
Precisely. This whole series has been bizarre and misinformed, but the latest entry is insane.
Why not blame the entire financial crisis on programmers also, after all they wrote the code.
It’s pretty easy to read up on the real story.
Lew Raneri – Father of securitization (background is mail clerk at Soloman Bros)
http://en.wikipedia.org/wiki/Lewis_Ranieri
Then on to MERS (The Tool – Designed and constructed by Evil Toolmakers)
http://en.wikipedia.org/wiki/Mortgage_Electronic_Registration_Systems
“So, the financial industry, eager to trade in mortgage-backed securities, needed to find a way around these recordation requirements, and this is how MERS was born to replace public recordation with a private one.”
“MERS began as a project in October 1993 when Fannie Mae, Freddie Mac, and Ginnie Mae produced a White Paper (with assistance from law firm Covington & Burling) about the need for an electronic mortgage registration system. The MERS acronym was coined soon thereafter. The Mortgage Bankers Association got involved and MERS was incorporated in October 1995. MERS awarded a contract to Electronic Data Systems (EDS) to develop and service the technology systems, and MERS was officially launched in April 1997.[10]”
See my comment above:
http://www.nakedcapitalism.com/2013/11/bob-goodwin-why-code-is-law.html#comment-1652762
There is nothing inaccurate about Bub’s account. And I am highly confident I’ve read far more about MERS (scholarly papers, Congressional testimony, court decisions, multiple depositions of MERS executives that include details about both the history and how the database was created and works) than anyone commenting on this thread.
Bob wrote this:
I should rephrase this. Software engineers did not know how to control paper, city halls or judges. So they wrote them out of the software.
This paragraph seems to claim that MERS was a project of Software Engineers, and apparently initiated by them, because they didn’t know how to ‘control paper, city halls or judges’.
If he’s not saying this (and TBH it’s hard to know what he’s saying in any of these pieces), then what is the claim?
It is hard to believe that you missed the tone of the article which was never saying that the software engineers wanted to or had the power to implement the policies that emerged. I am saying that I have sat in hundreds of meetings where we break a problem into a hundred pieces, make back of the envelope assessments of what is important, because we had no other information, and ended up seeing those priorities be a dominant factor in outcome. It is such a common ritual, that we try really hard to decide what is important. I can also tell you that we are always asked to leave a “paper trail”, and it almost always turns out to be useless because it is given low priority in an undoable list of deliverables .
So please don’t say I am placing blame on engineers, I am saying the relationship between the process of software engineering and the rest of the world has a long way to go, and that software engineering broadly should play a big part in that process, because if they try to improve the process top down, it will get worse.
Actually Bob, you were all over the place on whether the key characteristics of MERS were engineering decisions or were the basic business requirements – first you described them as decided by the engineers then not. IMO your fundamental thesis is quite unclear and the comments here reflect that confusion. For the MERS example, are you saying the engineers should have rejected the system because they should have known it was illegal? But you describe it as though it was all an engineering decision to begin with. This totally confuses me as to what it is you were trying to say.
“I should rephrase this. Software engineers did not know how to control paper, city halls or judges. So they wrote them out of the software”. [it was all an Engineering decision]
“I hope when history is written, this example will stand out on how the anarchist nerds that we call software engineers inadvertently started to hijack public institutions”.
[Engineers decided to hijack the mortgage recording system]
“The engineer quickly discovers that an individual mortgage has a failure rate of X… Looking back, I can see an error in the engineer’s analysis. We now know the cost was not anywhere close to zero”. [ engineering decision to do away with local recording]
“Now the supreme irony is that I’ve depicted the origins of MERS as software engineers gone wild. It’s certainly plausible as history, but what actually transpired is… Some people at Fannie Mae, Freddie Mac, Ginnie Mae and the Mortgage Bankers Association looked at how the Depositary Trust Corporation, a system which eliminated the physical delivery of securities on Wall Street by creating a central depository, and thought it would be great to create a version for the mortgage industry”.
[Oh, no it was not an engineering decision at all, after all. Then what the heck was all the previous stuff about?]
“I am sorry if I implied that engineers summarily rewrote history on purpose. In the context of prior posts I was trying to be blameless, although it is hard to excuse lawyers who should damn well have stopped it before it was too late. I had originally tried to write that part of the post as speculation on how it could have happened, but out of the context of the previous two posts, I do agree it looks more sinister than intended. The point I wanted mostly to amplify was that bad software had been codified by courts”.
[What part of the system was “bad software”? Did or did it not do what it was supposed to do? Now the miscreants probably point to it and say, see it’s just the software, we had no control and those engineers wrote the law out of the system. You seem to be validating that judgement but then denying it. Or was you thesis actually something else? If engineering decisions were actually a large part of why that travesty occurred, then please, please, explain that, because as far as I can tell the system was designed from the start to do exactly what it does – this was a key business requirement. Is that true or not? I can’t make any sense out of this piece. I don’t think you are at all clear about what the software engineering actually had to do with the MERS fiasco, what you would prefer that the engineers would have done.]
continuity of legal opinions from inception at Covington & Burling exist.
To suggest that programmers didn’t have legal opinions given the multiplicity of state laws that are different is ridiculous. Insurance, credit cards and car loans all have different rules in different states and the banks and auto companies comply in programming for example – Louisiana property law is completely different than elsewhere
it is not by chance that Lanny Bruer and Holder at the DOJ were both from Covington & Burling and the smoking guns are in their files
Well, I am more than willing to take Yves’ word for it. The citation in the MERS Wikipedia article you reference is from an article in the journal Probate and Property, 1997. Here it is, in part:
Can we agree that everybody might be a little right (but that Yves’ is, unsurprisingly, the most right)?
I still don’t read anywhere that attributes the legal opinions to software engineers.
I have nothing to say about that. Personally, I think folks (yes, FOLKS) might be talking past each other on this thread a bit.
It seems everything to do with whom is responsible for what, and crappy delegation of responsibility.
If a CEO or “business consortium” runs afoul of the law, and then in court tells the judge/jury that they did it because the secretary told them to, you would expect them to be laughed right out of court.(into jail – but that’s a peripheral story)
I would hope or the same reaction if you substitute “software engineer” for “secretary”.
“I would hope for”
damn wireless keyboard. batteries low again.
Well when confronted the FC mill lawyer said EXACTLY that – that his secretary made a typo – 4 sentences long – when he pled that his client had made a recording in the public registry that never happened…the judge laughed in his face — but no sanction whatsoever.
All righty…here’s a link to the White Paper, and a possibly relevant quote:
So…everything OK then, boss?
Straw man. Go reread the post. Goodwin did not say that, and nor did I.
I said the MERS folks conceptualized the system around what was convenient and lower costs from a systems perspective.
I’m afraid the premise of this article is laughable. I will only add a little to the previous comments.
Some times a figment of your imagination, is just that, pure imagination. Where is your condemnation for the civil engineers who built the Huey P Long bridge to disrupt trade on the Mississippi? The chemical, menchanical, and civil engineers who plotted to pollute the gulf of mexico. How about the engineers responsible for invading Iraq and Afghanistan? Think of the thousands of lives taken every year by automotive engineers who plot to have drunken customers get behind the wheel. Why stop at MERS with your Ludite fantasies?
Medical device manufacturers, oh they never do anything wrong. See the Therac 25, one of the first cautionary tales learned in, you guessed it, software engineering.
Also too because Nazis.
Please tell me what your experience in software is.
Bob has been in the industry since he stared coding as a kid in the 1970s. He’s held senior positions in major firms, including most recently, at Amazon.
Yves,
It really shouldn’t matter, but ChE originally. After about 15 years in the industry, I’m changing over to software. MS in CS. It is helpful to have a different background because I can see the differences between software engineering and other forms of engineering. Engineers are very technical in their field, as you would expect, but that doesn’t carry over to other fields. On those projects where you have to work together with other disiplines (almost all of substance) you have to defer to the customer or other experts about what is generally termed domain knowledge. This is the case for all engineers, but not to the same degree as for software.
Software engineers don’t normally develope for other software engineers, they develop for someone elses domain. This is why gathering requirements early in the process is such a big deal. We don’t understand the domain, if we did we would be accountants, architects, doctors, etc. Also, I don’t go into this assuming that software guys set out to make a faulty system. Assuming rational actors.. there is no benefit to them. The pay isn’t that great, it takes a lot of effort, and the future is fairly bleak, so (aside from the 90s) the people that are in it, aren’t out just to make a quick buck for the most part. I don’t know any Engineers that are, the slimy ones tend to go into management as fast as they can.
I’ve worked my whole life to develop enough knowledge to be able to build a complicated system and you think I’m going to chuck all that cause its easier for me not to trace your mortgage? No way, I love the hard stuff. There is a phenomina known as “feature creep” that comes from software designers wanting to add more bells and whistles to the project and causing schedule delays.
I can’t tell you what actually happened in those MERS discussions. When a client has come to me though, I give them a list of options, the costs, and the consequences. I have no control over the levels of management above me and as I’ve stated before, where I see failure, that’s where it occured. Those aren’t software engineers, they may have been at one time, or from numerous other professions. You could quibble about the lable, but would you blame nurses for hospitols patient care..?
been doing since the late 70s. in mostly large organization. have yet to see time when an IT organization tells the user departments what the software is to do. almost 100% of the time, the user community does that (or management). but i think the root of the real problem, is that as organizations get bigger, and management gets further from the front line workers. they loose all that happens in the manual process. and why it was done. the only time IT would have more say in the matter, depends on who set the budget for the project. a lot of what the budget is, will tell you what environment choices can be made. and who decides on what audit trails are needed? hm, can you say management. since they only want that if they need it. say because regulations require it (which there seems to be none), or they are worried they were going to have to go to court. which doesnt seem like some thing they thought would ever happen here.
These two comments are absolutely on point and correct. I worked for 16 years as an Information Technology Director for a school system and supervised several software creation projects. The software engineers create what they are told to create with the features they are directed to incorporate to the best of their capabilities. There is always feature creep and always at the last minute, with never enough time for testing and bug fixes.
Moreover, there is no organization I am aware of where software engineers or coders direct the project or specify what is to be the final product. There are occasions when the desired product is not possible with the particular coding system and alternative strategies are required, but these are almost never done without the knowledge and approval of senior administrators and the approval of those needing the program.
It is patently absurd to blame software engineers in large organizations for the design of the programs which they produce. They may design the code structure, but the program design (what they want it to do) comes from above.
One added point. When accepting articles such as this for publication on this blog, it would surely be helpful if they are proofed by someone before being posted. This was almost unreadable.
“These two points…” reflect a narrow frame of reference, an ideal toward which conscientious coders should strive. However, in my two decades of IT support, I had to listen to, and deal with, the complaints of the end users in Operations who were forced not only to learn new ways of doing their daily jobs, but also who had to learn new ways of thinking about jobs they had been doing for many years.
The lead coders did analyze operations, and they also had to replicate the Big Iron functions in the Windows environment. But the authors of the new code apparently felt no obligation to follow the dictates of Operations. Our coders were intent on building a brave new world, a better world, and it was too bad so sad if Operations didn’t like it at first. IT was king, despite being a cost center, and Operations had to take what they were given, despite being the revenue generators.
I am sorry that you found it unreadable, and missed the point on the role of software engineers, because the post was split into thirds it seemed out of context. But I was never saying that software engineers were in control. I was always saying that the result differed from ideal because of complexity, priorities and trade-offs. Perhaps my use of the anarchist engineer as a metaphor for chaotic outcomes did not work, but I think that working on closed ended IT projects gave you a more optimistic view of outcomes than are typically seen in large government/finance projects.
Whatever you said or tried saying came out really bad and it’s all over the place. Honestly as a long time reader and sw engineer i think that all this proves that whatever the heck your thesis is, this was definitely not one of the more useful posts is NC history. I’m being a bit mean here. But you should never have posted this. A good thesis is usually concise. You post is all over the place and your replies also, while adding only a very small element to the analysis of what went wrong. 50 years from now people will remember goldman and fannie and their crimes. No one will remember anything about sw engineers.
Of course law is code (codified) – just depends on which comes first…the horse or the cart.
Criminal code / civil code…anyone heard of that?
Silly is the thought that occurs to me when people don’t think the ACA is a tax. It is a tax, it is taxation. Just a different name. It is another tax upon wealth creators (wealth building requires, without exception, labor in it’s creation.)
Taxes are used to deter an activity so, by deduction, wealth creation is being hampered by this tax.
MERS was designed and implemented to avoid recording fees and other deterents to fraud – those fees and recordation were a public good and represent a tax…. a public good tax that MERS specifically avoided…IE; the recordation of land in court houses required a tax to pay for that public good – a good use of taxes…by extrapolation, MERS avoided the tax and thus it’s intent was against the public good defacto.
A little more 1920’s artical from TAX FACTS.
“In the United States, people are wont to talk feverishly and vindictively about the “non-taxpayer”, for it is here that our brother from Mexico, our cousin from over the Canadian Border, our friends from India and the Middle East come to escape the rigors of their respective locations
They proceed to use our highways and our libraries, our water systems and our police protection. If they have children old enough and stay long enough, they use our public schools etc., whereupon there is a great cry about non-taxpayers taking advantage of our benefits of government. Because these visitors and temporary residents don’t own property and are not listed with the tax man, the general supposition is that they pay no taxes.
A itemized account of the money spent by these “guests” over a period of time would yield some surprises. Naturally, the itemization includes practically everything permanent residents would buy, food, clothing, housing, luxuries and the usual necessities.
A little thought will show clearly that while the guest owned no property here, the hotel proprietor, the restaurateur, the merchant, the grocer, the druggist, everyone in fact, from whom he made purchases did own property, and that property was subject to taxation. The tax on the buildings and merchandize was simply added to the other overhead expenses in the bill of the proprietor and merchant.
The property owner acted as a collector and ultimate consumer, whether a native son or a wandering guest, paid the tax. The guest who owned no property himself in the United States paid a tax whenever he slept with a roof over his head, paid taxes every time he bought a cigar or steak. A man could no more pass through the United States and purchase a meal or a night’s lodging without paying taxes than he could buy a gallon of gasoline for his car without paying the gasoline tax.
The “non-taxpayer”? He belongs to the class of griffins and unicorns and other fabulous animals. There is no such creature.”
Blaming software engineers for this is like blaming brick layers for building an ugly building. Blame the person that specified the system, not the people that built it.
Software engineers are the modern version of Gogol’s clerk. This post couldn’t more wrong even if it tried extremely hard.
How much experience do you have with big IT projects? If you don’t have any you don’t have any basis for your comment.
In any other discipline I can think of, if a client comes to a vendor, and says ” I have XYZ circumstance and this is what I want done” one of two things generaly will happen:
1. After a series of conversations, the vendor will be able to provide some sort of bid on the project (time and budget) or will tell the client he can’t provide what he wants done OR
2. The vendor will say, “You need to do a lot more investigation and preliminary work before anyone can bid this out.” For instance, in the outsourcing business, there are specialized consultants that help the client develop the Request for Proposal so places like EDS and IBM Consulting can bid. No joke, the process typically takes 18 months. The consultant has to really understand the client’s operations AND he interfaces with the main logical suspect vendors, so the terms are significantly pre-negotiated before they are bid out.
IT project sound like they desperately need a process more like 2. Clients should not have to know the business of specialist vendors to get services from them. I don’t know the law or medicine yet I use lawyers and doctors.
What none of the software people on this thread who are bitching about Bob seem wiling or able to acknowledge is that their complaints about “Oh, it’s bad management” or “oh, it’s the stupid client” are not acknowledging is that software developers effectively require clients to know more about their process than is realistic or reasonable. If the software industry has not figures out how to work effectively with clients and deliver more reliable outcomes, it IS their fault.
IT project sound like they desperately need a process more like 2. Clients should not have to know the business of specialist vendors to get services from them. I don’t know the law or medicine yet I use lawyers and doctors.
What would you expect if you went for the lowest bid, or chose a lawyer who did as you asked (rather than asked you questions, and gave you advice)? Because plenty of clients pick their IT vendor that way.
Similarly, what would you expect if you told the lawyer your legal strategy in advance, and told him just to do it? Because again, this is how many (perhaps most) companies/government approach IT projects.
If you want a successful IT project you need to do the following:
1) Go through a process of identifying requirements /before/ you define project scope and cost. Most clients don’t want to do this. It means spending money in advance of a commitment to a build, with no guarantee about what you’ll get. It’s the right way to build software, but…
2) Spend a lot of time before building anything getting requirements right, designing interfaces, etc. Again, this is not something that most clients want to pay for.
So yeah, if you don’t want to pay for those things, you will find hundreds of contractors happy to build software the wrong way, including many big names (e.g. allegedly this would include Accenture, EDS, CSC Corp). On the other hand if you want to commit to spending more (albeit with a budget which is less likely to fluctuate over the course of your project), you can get software which will work and meet your needs.
Sorry, but I have to agree with everybody else here, this guy is pretty clueless. Before you ask, I wrote my first computer program in 1973, and I have experience with large projects in aerospace, telecom and government, in development and operations.
To start with, he doesn’t know what the genealogy of “code is law” is, and why that makes its application to MERS inappropriate. The phrase originated with, or at least was popularized by, Lawrence Lessig, he was talking about the attempts by traditional law to control and/or suppress the Internet, usually by using methods that simply would not work on the Internet, most commonly by using laws and techniques that were developed for circuit-switch telephony networks. In this case “code is law” is the same as saying “mechanical design is law” in the face of attempts by lawmakers to legislate that, say, a Boeing 747 has to be capable of supersonic flight. Not gonna happen, but this doesn’t really apply to MERS, which should have been written to conform to existing law.
It is not reasonable to think that the software developers who designed and wrote MERS should be experts on mortgage law in all 50 states. You hire software developers because of their expertise in developing software, not because of their expertise in legal matters. The developers merely created what they were asked to create, maybe imperfectly, but software defects aren’t really the issue with MERS. The developers have no way of knowing legal matters were missing. They are pretty much at the mercy of their customer here.
There is a phrase used to describe companies that say things like “You need to do a lot more investigation and preliminary work before anyone can bid this out”, that phrase is “out of business” or “broke”. For better or worse, there are plenty of companies that will bid on bad or incomplete specifications, as long as the contract has provisions for them getting paid for any requested changes (and there will be changes). Another example of the free market creating less than ideal outcomes.
Not to mention that it is widely acknowledged that except in rare instances, attempting to completely specify a product up front just doesn’t work. Large software projects are just too complicated and human language is too imprecise. You get large, complex systems to work by incrementally expanding a small, simple system that works. This requires close, long term cooperation between the customer and the software developers, cooperation that the customer often doesn’t want to bother with. Or in the case of government just can’t be done for legal reasons.
I think I agree with everything you wrote, and your conclusion validates my point. I don’t think you are arguing that software met its highest aspirations every time. So there is a gap. Who influences what this gap is made of? It is always what is left after what work is completed. And who controls how work is prioritized? Engineers, for better or worse, work with the information they have. I think when you read the last post without the first two you are left with the impression that this was the weakness of software engineering. I did not mean that, I believe the weakness of software engineering is that we have not figured out how to give the controls to the people with the knowledge. That was the point.
What none of the software people on this thread who are bitching about Bob seem wiling or able to acknowledge is that their complaints about “Oh, it’s bad management” or “oh, it’s the stupid client” are not acknowledging is that software developers effectively require clients to know more about their process than is realistic or reasonable. If the software industry has not figures out how to work effectively with clients and deliver more reliable outcomes, it IS their fault.
— Yves
I’m sorry but you are wrong. Fundamentally. You have unrealistic expectations, I’m not sure why, perhaps you have had dealings with snippy software developers..
Lets say you go to the doctor and tell them your chest hurts. You don’t expect them to listen to your heart and then tell you to go home and take some antacid. You expect them to schedule multiple follow up, send you to the emergency room and to talk to an expert. Its your call to do all that. If you don’t want to pay for it, its at your risk. If you decide to use a doc that runs a pill mill thats also your choice. You don’t have to know anything about your body to know that it might be a good idea to ask around when choosing a health specialists. And you dont expect a single doctor to know everything there is to know about your body or what you might require.
You can’t expect someone else to know more about your business than you do. Thats your problem, period. If you can’t break your processes down well, first of all it sounds like you don’t even want to know about your business which is a shame. No one else is going to be more motived one would think. Someone can try to work with you to do that, but you can’t expect that to be free, fast, or easy. Does your mechanic diagnose your car without getting paid? Mine doesn’t.
That has nothing to do with SE, that’s you not understanding your companies processes. Don’t blame others because you don’t care enough. If you can’t tell me that form XY needs to go from department A to B after event Q, what am I supposed to do, take some vacation to hang out at your office and hope Q happens so I can record it? There is a solution for this type of issue. Time and material, you’ll get all the “consultants” you could ever want. You can actually get good work done, learn alot about your process (which you clearly need) too if you pick good people. Its not OOP fault if you pick someone whose only interests is fleecing you.
There isn’t any standard or regulation that you could devise that wouldn’t be used to screw you by certain players. That’s just what they do, its their business model. At least for now, software is still a craft. Its in your best interests if it stays that way. You can actually find people who care about the quality of their work inspite of articles like this one. Maybe you should blame the software industry for the software industry, software engineers really have nothing to do with it as odd as that sounds.
No, I am sorry.
It sounds as if you don’t understand basic professionalism.
If you can’t do what your prospect expects, you turn down the job.
If you’ve gotten involved with a client that is unrealistic, or you’ve failed to qualify adequately. that is YOUR FAULT.
It is no different than someone calling on a broker and saying, “I have $50,000 in cash, I make $120,000 a year, I have a FICO of 690. I want to buy a $5 million house in Mailbu.” If you take that client around, you are the one who is remiss, not the client.
If you can’t do what your prospect expects, you turn down the job. –Yves
I totally agree with you there. I think the issue that I and several people have had with this discussion is that label Engineer being thrown around. I’ve never done any of the things that you mention precicely because I am an Engineer. I actually took an oath when joining a professional society and I meant it. The people that see an opportunity to siphon money off of clueless clients are not Engineers by definition. Engineers apply technology to help people, to build a better world. That’s the reason for so many comments here.
I don’t think you would make the same assumptions for a different profession. If say a patient was denied adequate medical care you wouldn’t call out nurses even if some of them had climbed the hosptital hierachy and made decisions that led to the denial.
Engineering has been in somewhat of a decline along with manufactoring. Companies want drones instead of real thinkers. They want cookie cutter bots that do what they are told. My advice to young people today is to stay away from the field unless you don’t think you could/will be happy doing anything else. I’ve found myself in a situation where I have to refuse to do something that will put lives in danger because its easier for the client, or management. It gets to be an old arguement and a tough one to have especially after the entire profession gets thrown in with the bottom feeders.
I have been involved as an officer and stockholder of two software development and operation companies
One of these companies managed different systems for Lotteries, tracks and slots in the USA and overseas.
without equivocation – the enabling laws of each state lottery was different and required special work to comply with all aspects to insure compliance. These contracts came with performance bonds up to $50 million in the case of NY and Florida which we operated in the late 80’s and early 90’s – mistakes were calculated in minutes down for the system and the fines were huge
there were lawyers everywhere in the process at the state and private level – our outside counsel was Fried Frank – programmers do not run amok – they are directed….by management
MERS was designed around rules regulations and laws – to deliberately NOT be in compliance – Fraud was the objective and avoidance of property taxes
Eyes wide shut!
I agree that if the entire process centered around legal compliance you well get compliance. I do not agree that you would get compliance of it was in the spec but never prioritized, and never tested.
Sorry Yves, but you’re being snowed.
It’s extremely painful for me to say this, but you haven’t got a grip on this story, and this poster is obfuscating the reality that lies at the bottom of this mess.
Suffice to say that the first thing that happens when a new software system is developed, is that a team of analysts representing the developer meets with the customer’s team to find out two things;
1. What EXACTLY is it that the new system must do?
2. How EXACTLY are you doing that job now?
In both cases these Business/Systems Analysts work very hard to produce iron-clad answers to these two questions.
It is not until these questions are answered in a very complete and formal manner that any coding starts.
It is not until these questions are answered that any software engineers even touch the project.
The ultimate nature of the MERS system has everything to do with its owner’s intent, and virtually nothing to do with SW engineers behavior.
It was the people who specified and paid for the development of the MERS system who must answer for its impact, not the people who programmed it.
The banks wanted a system that enabled them to forgo the trouble of interfacing with the legacy system of title registration, and they built one, most likely ignoring a lot of interesting questions along the way.
I’d be willing to bet that many, if not most of the answers to those hard questions asked by the vendor’s analysts, went something like this;
“Don’t worry about that, we’ve got that under control…”
A reputable developer walks away from jobs where too many questions are answered like that.
If the SW developer wrote anybody out of the process, it was at the explicit request of the customer.
Bingo, the best and simplest explanation yet and in software simpler is almost always better, or perhaps I should say elegant.
So you prefer the position that software always does what the masters say it should, and that they always get it right up front, and nothing changes afterward?
I always see a process filled with difficult decisions, and limited communication between those with knowledge of the use case, and those in a position to implement. Sure software can meet a spec. I do not have the document, but would bet good money there was a vast difference between the MERS spec and the result, and a lot of that difference was due to the gap between expectation and reality. I would also bet that reality was measured by what engineers delivered, which I would bet was driven by what they thought was best, which I would bet was not always the best.
No, untrue. Coding is often an iterative process. There are developers (highly respected boutiques who do a lot of work on Wall Street) who use Extreme Programming, which is not at all the paradigm you describe.
The very fact that you so confidently assert that there is only one way to do it suggests you don’t know what you don’t know.
my impression of government contracts is that they are nothing like that. They tend to stick with the Waterfall process the OP describes.
XP has a lot of varieties, but the general idea is to save money by getting rid of the formal processess that are normally used. This means getting paid T & M, more or less, I don’t see this being applied to a government project.
You’re comparing apples and oranges Yves.
I’ve worn virtually every hat in the profession being discussed, and know that the ’boutique’ developers you mention are in a class that puts them outside the story.
Those developers are on the other side of the universe we’re discussing.
I never said there is only one way of doing a project like MERS, what I said is where and how it begins.
While it is true that there are folks the like Haim Bodek, whose story was recently featured on your blog, who can and do code from a clean-slate so to speak, it must be remembered that;
1. He is working from a base of understanding that is virtually complete, that is he already knows what he wants to, and he understands how others are attacking similar problems.
2. He is often his own customer, that is, it is he who will lose or gain by the success of his engineering skill.
3. And this point is very important to understand; guys with the skill to create HFT systems out of whole-cloth are using systems that while ostensibly not illegal, are at heart un-ethical, the fact that their moral compass is damaged or missing altogether not withstanding.
http://www.nakedcapitalism.com/2013/11/the-wall-street-code-hft-whisteblower-haim-bodek-on-algorithmic-trading.html
I stand by my point, that MERS does what it does because of the intent of the banks who own it, and not because some arrogant software engineers played fast and loose in the process.
This whole series of posts has had the effect of clouding the issue of responsibility surrounding the MERS system and the wider issues of fraud in mortgage securitization, and the damage done to our legacy property registration systems.
This is a perfect example of how the people, trying as they might to find and understand reality, are stymied by the PTB who are busy creating their own reality, and if we ever get close to finding out what is really going on, they simply shift into overdrive and disappear over the horizon in a cloud of self-serving myth.
The fact that you’ve not only been taken in by the false narrative, but hosted it, and continue to defend it’s veracity is truly lamentable.
Doing extreme program or Agile in a regulation HEAVY environment (and yes that would be finance) is probably asking for problems right there. I think you’ve found your problem.
fwiw by finance here I didn’t mean HFT, I meant banking and everything related to it.
I liked this post. I thought it was a good diagnosis of the problem. When Goodwin says “Policy always was software” and “Code always was law” he is saying (imo) that these things are very complex – policy and law – and in order to properly digitize them a great deal of definition must occur. It must occur from the most simplified and intricate context – from the bottom up. No alchemy will work just because you want to short circuit something. No fake simplicity; no fake elegance. Just long, hard definitional work for everything and every process that must be communicated. From the bottom up. And then an equally complex “interface” between top down (management) and bottom up (participant). This implies the software engineer can only be as efficient as the content provider. Who gave these engineers their information? The bank lobby?
I’m just musing on this: Policy is sausage but law really is code. Software engineers need to always have a lawyer specializing in pertinent law advising them because the statutes and the elements satisfying the definitions of the law are very deceptive. Deceptively simple but if you screw with them even a tiny bit it creates some pretty illogical situations. The thing about law and why it is so complex is that it is a practice. Over the centuries it has become refined to prevent misinterpretation. And software might not understand those mysteries. Also because Policy really isn’t a practice. It gets reversed all the time depending on whatever special interest is involved. Maybe it should be a practice. Get a little continuity going.
Code is law because the system is not flexible. There’s no recourse against the computer, because people assume the computer is always right.
If it was easy to get recourse against the computer, then the code wouldn’t be so constraining.
If an area is not a programmer’s specialty (e.g. legal intricacies of conveyancing), then they might not recognize the need to ask questions, or know what needs to be asked.
It’s a common problem–without broad experience we often don’t recognize our ignorance, or the implications of our actions / inactions taken in ignorance.
That’s not to give programmers or managers a free pass–someone should have had their eye on the ball in relation to the legal implications.
The entire MERS debacle could well be a convenient way to guarantee a tangled legal mess that would never be pinned on a specific person or department. The setup created a guaranteed circular firing squad, guaranteeing that no person or institution will be held accountable.
Thanks Susan!
I think next time I will just post your comment, and skip all the rest. It is really hard to capture how crazy all the moving parts are in these software projects. And once delivered, these projects aren’t helpful because the people who need the control (the experts in the various policies) now have less.
It is frustrating that commenters think I am placing blame in these posts. I am really only blaming software engineering in a very broad sense for their failure to deliver control. In no way am I blaming any individual software engineer for stealing control.
Agree with author and other bright posters here.
This post-mortem process-level study of the manufactured decline of public space is valuable. I appreciate it even more as I believe that the MERS story is vastly undertold and often disconnected from many conversations of fraud, the financial crisis, and monopoly power of banks.
The problem has not been the software engineers. The problem has be the fact that the software engineers have been hired to automate an entire process by a customer who in fact seeks to control how that process runs, even if that process has not run that way in the past. And that control has systematically, and some say deliberately, shut out other stakeholders in the process. MERS was a systematic, if not deliberate, attempt to capture the part of the process being handled by elected registers of deeds even as developers and bankers were resistant to automating the processes in the registers of deeds so that all land records were both stored as images online and properly indexed.
Business control of customers, vendors, employees, and government agencies are often the larger strategy behind some very arcane software requirements.
I think it’s useful to pin down a little what software tech is supposed to do.
If you want to buy an operating system in a box there is Windows.
If you want to buy an accounting system/enterprise resource management system in a box, customizable to your biz requirements, there is JD Edwards (now part of Oracle) and SAP. These are “software products” that have evolved over decades by software companies working with customer companies to refine the product and is supported by a legion of software engineers trained in the product whom will tailor them to a corporations’ specific needs.
Then there are also other biz process customizable packages. A couple fer instances, Peoplesoft for HR processes or Filenet for document workflow processes – where “document” means a electronic facsimile of hard copy paper documents – and is/was popular at the S&Ls for processing/storing/retrieving mortgage docs electronically – back when S&Ls used to do mortgages and hold them on their books instead of sell them all off to a securitizer.
Then large software consulting firms have industry experience “re-engineering” more specific, and lower volume types of biz processes. Smaller firms also have niche markets here. ‘Course corporations usually put in the contract that they “own” all the code and on-site software engineers can’t take code off the site. ‘Cause they don’t like the idea of paying for development that ends up at a competitor someday. There goes the concept of “stable, re-usable code”.
Now when someone comes along and says I want to buy a brand new electronic analog of my industry, complete with legal system, policies, executive decisions, and a market for my new electronic industry – and software engineers are the place to get it all, that should certainly raise some eyebrows.
BTW: Didja ever notice how getting all those dumb pieces of silicon to do something useful seems to be at least a full time job in itself?
It is only because I have great respect for this blog that I make the following request: Can a way be found to edit ALL articles so that errors of meaning and typography can be corrected?
For example,”this story might not have gone largely unnoticed” in this piece is obviously an error. It is ambiguous and the reader can tease out the meaning but it would be much nicer to read if it were edited before publication.
Oh yeah, and you’re just scraping the surface with that one. I have to restrain myself from making copyediting notes in the comments section of every post…though sometimes I can’t help it.
But I’m guessing Yves’ would need to pay someone to proofread every post to really reign this “problem” in, so this is probably a matter of pay-up-or-shut-up…but I feel ya bro’, I really do. I just try to be zen about it and see the beauty in the imperfection…
Um, “reign” should be “rein” so I question your copyediting calls.
If you want copyediting, the Tip Jar is in the upper left. Demands with no donations are churlish. I bust ass and do not appreciate this sort of thing. I am chronically exhausted and on the verge of burnout.
So, if I understand correctly, a bunch of sofware engineers came together and decided: “We’re gonna write MERS and we’re gonna impose that on Fanny Mae, Freddie Mac and the whole mortgage industry.”
This is outrageous! Those sofware engineers should be in orange jumpsuits doing the perpwalk!
Without the context of the 3 posts, I can see where you might have read it that way, however the intent was not to blame engineers for rewriting law, it was to say that it is common to under-invest is low value features, and that it was easy for an engineer to make an incorrect value judgment. Of course it was the business and legal folks who let this through. I would venture, though, that the decision to allow something this illegal was more likely complicity after the fact, rather than intentional. But I don’t know how to read intent.
to allow something this illegal was more likely complicity after the fact -Bob Goodwin
I think you have presented several conceptual difficulties in your series, such as anarchistic nerds to get over before being able to grasp your thesis. If you had described it this way initially, you would have had more success.
Are you saying that software engineers are complicit like gun makers, or drone makers, or bomb makers, or lethal chemical makers, in the way their software is used only software makers are more so, since software is used in everything whereas guns are specifically for violence?
I have to say that invoking Bob’s authority as a software engineer to suggest that others without his credentials or experience cannot comment (or have their comments considered on the merits) is a classic case of fallacy of authority.
And I am surprised bu Yves’ willingness to, basically, give a pass to the financial engineers who set this thing in motion. I’m sure there’s plenty of blame to go around, but surely the finanical geniuses had some inkling of the centuries-old tradition of land registry, just as the criminals implemeting digital voting systems knew damn well they were trashing the paper trail in voting systems, leaving a hole wide enough for Bush II and others to drive a truck full of stolen elections through.
MERS was built to streamline securitization of mortgages, and if a few corners were cut in the process, well they just didn’t give a shit. Once they realized (planned?) it had hijacked the entire mortgage registry system, destroying title for millions, they pushed forward into the land of blaming the victims and “deal with it, suckers.” Judges, mostly, fell into line.
At least Obama is pretending to “fix” his software disaster. Not these bastards.
Cripes,
I think fallacy of authority more strictly applies to someone that is an expert in another field purporting expertise in an unaffiliated field of endeavor. EG: an expert programmer offered as expert on brain surgery.
On the subject at hand Bob’s probably has plenty to draw on. that said, I think it’s common sense the dysfunction goes deeper than programming and I think “Once they realized (planned?)” is a reasonable line of debate. Things usually render to Cui Bono, no?
And this is the opinion of a expert Fortran IV programmer who was responsible for many boxes of errantly punched cards that “timed out” programs on the UofI IBM 360/370. HAHHAHA!
By fallacy of authory i understand, and intended, that to mean disregarding the merit of an argument by saying someone is more qualified than you are to venture an opinion on it. So you get remarks like “what are your qualifications.” Instead of facing the argument. BTW, even as projecr manager for small nonprofit datasystems, i soon learned managment/cusromer ruled and even modest push by developers to suggest data and process integrity was oftem met with imperious prouncements from dolts who should have known better. They were more interested in looking good than doing it right. MERS, meet marketplace exchange software.
There is the (considerable) possibility they built exactly what they wanted, and so, did get it right.
It also seems basic that even financial managers, dim as they are, can probably read a process flow chart that is missing huge chunks of process. Like maybe proof of title. Don’t nees to write code to know that. And surely they “realized” they were evading county registry fees?
Honestly, even financial managers, dim as they are, can read process flow charts that are missing little things like proof of title and fees for county registrars. They don’t need mad coding skillz.
Fun read Mr. Goodwin. Tough to capture the full breadth of systemic failure in one essay, so yeah many knives killed this victim and certainly programmers had their role. With any complex system the less you know about it the simpler it is, often the challenge for anyone that has the typical “consultant” dumped in there lap from above (file under: http://en.wikipedia.org/wiki/ISO_9000).
Personally, I cut some slack for the programmers. Presumably they were charged with automating a large enterprise system, not resolving the hierarchy of importance of the outputs from “nice to have” to “mission critical” and “absolutely needs an archival and redundant paper or otherwise copy that fulfills a chain of custody standard”?
So what is the division of labor and responsibility? Aren’t the programmers responsible for the efficient execution of the software, leaving out that which slows down the processing cycle time? The mortgage industry professionals and regulators being responsible for the fidelity of the (not so) expert system’s intellectual content? Its seems to me industry professionals role should have included pushing back on the programmers to include the missing important bits, and the regulators role to ensure that occurs.
The tradesman metaphor applied to the programmer is apt. It was the industry “customers” and the regulators due diligence responsibility to evaluate the automation project progress, and ultimately sign off on the integrity of the product.
When it comes down to the programmers, the industry professionals and the regulators, I’m guess’in the later two should have spent less time on the golf course.
BTW, on a more cynical note, I think its’ fair to speculate on how much is a result of industry/regulator shortsightedness and incompetence, and how much can be attributed to a cabal premeditatedly “dragging the willow branch behind them” to obscure any kind of legal forensics on the industry excesses?
What better patsies to point at then the guys w/ greasy hair drinking Red Bull that were perhaps not fully equipped w/ the actual requirements/time/budget?
always wonder why those who use a system/application always complain how it works. when they (or their bosses) decided how it was to work. the software engineers do not set the requirements for what an application is to do, that set by others. and requirements are those things like what its to do (say storing mortgage documements electronically) or not passing that on to those who are the ones by law who are to be the repositories of those documents. while maybe F&F were involved in starting this ball rolling, you can bet wall street took it over from them. because they saw a new way to make money, faster, easier. just maybe not legally. but that hasn’t seemed to ever stop them before has it?
I don’t know anything about software, so forgive me for butting in. The But is that I have now new respect for “The Wizard of Oz” – at least the movie version. The Wizard is going to grant Dorothy’s wish, to go back home, by (of all things) taking her there in a hot air balloon. (Think about it). At the last minute her little dog Toto sees a cat belonging to one of the Emerald City dwellers (aha, a cat, sound familiar?) and leaps out of the ascending balloon, followed by Dorothy (or should we call her Yves?)
The Wizard calls back to Dorothy, “I can’t come back; I don’t know how it works!”
Is that the promise of software increasingly complicated, that inevitably down the line nobody can come back once it gets underway?
In which case, should we all wave bye-bye to the wizard and instead invest in a pair of ruby slippers?
…Oh well, it is a children’s story after all.
Baum was not–repeat NOT–writing a children’s story!
While I have problems with what he thinks, I like the way this gentleman writes about complex issues.
In terms of responsibility, imo, the law cart (human writing responsibility) always comes before the inhuman code horse. Bad law guarantees bad code.
No matter how well law justifying/ordering launch codes for nuclear weapons works… the law, the intent, ultimately the code promises horrific results. Yes sometimes the devil is in the details, but usually it’s pretty obvious the purpose of the bomb. No code, unless intentionally designed to make the launch fail could possibly be good code.
Too many “coders” are looking for another version of I was just following orders excuse.
I was more than a little surprised the author does not consider himself a liberal particularly after reading his thoughts on Obama not care. Once again, the law is shit, designed to be outrageously expensive while leaving tens of millions without care, many millions more bankrupted by trying to follow the code.
Exposing my politics would have undermined the post. It is very unreal for me to be seeming to defend a bad law, but I am very passionate about our institutions, even with their very serious faults. This is a law credibly passed, that appears to be failing because they couldn’t, and not because they shouldn’t. That is a very bad thing for all Americans, not just liberals.
I am not sure many posters would agree with me, but I think Americans are in a lot more agreement on how we would like things to turn out (i.e. we would like all sick people to get better, and more tangibly don’t want people to die or go bankrupt because they can’t afford health Insurance.) Most of the debate involves the means to the end, despite accusations of bad intent. Just as democracy produced this bill, it also produced other things I don’t like, for example lying selfish congressmen, and accusations of bad intent. But I still want our system to succeed regardless of the party in control. I think that better software might help create good outcomes, and then all the political blogs will be filled with fights over nothing, like the naming of a holiday, or whether to fire someone in the government for poor word choices. What we fight over speaks to how we are doing. Failing government speaks to our future.
I had thought about writing a longer post, based upon my admittedly limited experience. So I’ll just sketch it out and do not plan to spend the time to defend it. Sorry.
Why Code is Tyranny
When I learned to program computers, one of the first things I learned was that the bulk of code deals with exceptions, with things that are not usual or normal, things that go wrong. Anticipating exceptions is part of what makes writing software difficult. Therefore I found the claim about only doing 20% of the work shocking. Programming is about doing the 80%.
Shocking, but not surprising. Here’s why. There is an attitude among programmers that users are input devices for the programs. In addition, programmers are not trained to deal with all of the strange things that people do. We should hardly expect them to do so. Ideally, they should work with people who are trained to deal with people. When that does not happen, people may be ill served, at the very least. Instead of having software that serves the user or consumer or borrower and lender, the users, consumers, borrowers and lenders may end up serving the software.
There is another field where most of the work is concerned with things that go wrong, the law. The law deals with the strange things that people do. When software that is supposed to conform to the law or assist it, but ignores it instead, then you have an ignorant program dictating to the humans who use the software or whose lives are affected by it. Deus ex machina, omnipotent but ignorant. Coding is tyranny.
The comparison with human clerks and bureaucrats is inapt. Humans know how to deal with human problems, but that knowledge is left out of the software. Furthermore, clerks and bureaucrats are sometimes held responsible for their actions. Computer programs are not. This lack of responsibility is a major problem with computerization. Coding is tyranny.
“Code is law” is the darker mirror of “work to rule”. “Work to rule” highlights the important, undocumented interchanges in day-to-day work. As a rule these don’t make it into code. No wonder computerized systems are so blind to what it actually takes to get work done.
Goodwin highlights an important issue — the revocation of power away from employees and onto code. But this is one of the biggest goals of corporate IT projects. To systematically de-skill every possible job, to replace experienced and educated workers with minimum wage drones.
Goodwin places a lot of responsibility on the software developers when they do not write and have little power to alter project requirements. Coders can successfully intimidate managers through strategically inflating time and cost estimates, but that is probably the limit of their influence. The incentive to shortchange development resources is all on the management side. This is just another failure of the shark squad — execs who pursue their own short-term interests at the expense of society and their corporations.
Personally I would depose the sales dept, in its procedings, wrt system requirements.
skippy… for the last 15 years at least (in this cycle), the trend has been to fill out any dept with young clever kids, but, clueless in life skills – industry experience (what is fruad???). Leaving them to be controlled by some journeyman of middling ethics and all over seen by the grandmaster sort, see slimin dimond.
‘”Policy always was software”. “Code always was Law”. We just never realized that before there was software there still was code, executed by clerks rather than machines.’
This is muddlethink to me. Democratic institutions and human agency are not the “Chinese Room” of an automated judiciary. Code was not always law, and still is not. The muddle goes all the way to the agency here – MERS wasn’t a convenient hack by “software engineers”, it was conceived by people with incentives and objectives, and software is not even the essential ingredient here – nor has software anything to do with the lawlessness of instituting MERS, and the lack of judiciary response from the democratic institutions so challenged.
Do you know that my local library recently got an automatic circulation system that is soooo screwy that if you don’t follow the check out procedure exactly, the person who follows you gets your books on their account.
Now, they told me this the first time I checked out on the new system, so I make sure I do it– but the person who went before me didn’t.
I now have their “The Problem Child” and “Fairy Tale Detectives” on my account. (That sounds a little like my last job, come to think of it).
It’s so screwy that it’s not even like you can see their books going on your account when you approve your own transaction. It’s just sitting in there somehow.
The old automated system worked fine. When you took your card out, it quite naturally assumed you were done. I liked the old system, I thought it freed the librarians up to do what librarians are supposed to do.
But they’re not going to be doing what they’re supposed to do now. Now they’re going to be fixing my problem.
On my knees, hands extended over my head, bowing up and down and chanting “I’m not worthy I’m not worthy”.
I wish I had written this.
Thank you for the explanation and the link to the book.
That reply was meant for Jonas, re: his explanation further above about “throwing out the telephone” to create a negotiating advantage.
Something is askew:
When Mr. Goodwin says software is law (“some form of common law”), he means that shutting down the software implementing MERS, would have thrown a monkey wrench into the profit making system – bankers would loose money. But of course it’s obvious that the impetus for not shutting down the software is bankers’ greed and their control over the courts and the law,not that software is law. Mr. Goodwin says it best, “The highest goal of property law is to keep money and products flowing in the economy.” So this high goal of property law, not software, is what drives the urgency and necessity. There is no logical way to take that goal – bankers want to make money – and use it to imbue software with the power to veto policy as a result. If anyone vetoes policy, it is bankers who insist on the continuation of illegal practices and who have corrupted the courts to go along with it. The robo-signing and fake documents are NOT part of the MERS software. Mr. Goodwin has it backwards. And it is an imaginative anthropomorphic stretch from there, to attribute the banking fiasco and the most ruthless greed ever seen in business suits to an inadvertent byproduct of software written by nerdy anarchists. Huh?
Speaking of that, is that what we all are? Anarchists? And here I was thinking there are as many different types of developers as there are different types of alcoholics. That is, each and every one of them.
I am but an analog refugee lost in this digital world. I find it impossible to believe that software engineers would have been given a totally free hand to design MERS howsoever they wanted. I deeply suspect that the MERS masters knew exactly what kind of fraud engine/money laundry
they wanted and gave the enineers just enough instructions to guarantee that a fraud engine is what they built.
I am confident that the coders had no idea they were building a fraud engine. They strike me as being a form of
Lenin’s “useful idiot”.
I have read elsewhere that many coding engineers are vicious snobs who design software and computer stuff on purpose to be as mystifying and user-hostile as possible to
us analog peasants. I can’t remember where I read that. Such engineering of a digital-aparthied world on the part of SOME engineers would not surprise me in the least.
Yes probably “useful idiots”, I mean fine if they had known it was illegal, maybe they should have resigned. But despite all references to “only following orders”, it’s just as likely they had no idea because coding is their speciality not mortgage law.
Yes, that’s what I was trying to say. The MERS builders had precisely zero conception of the mass crimewave intentions and goals of the people who wanted MERS built. Analog peasant that I am, I think Mr. Goodwin gives softward designers entirely too much credit when he says their best intentions resulted in a bad outcome. There best intentions resulted in a PERfect outcome for the people who paid to have MERS built. They didn’t and don’t know enough anything at all about the laws MERS was designed to nullify and subvert. And the people who requested MERS be built were very careful to tell the coders as near to zero as possible about any of those laws and procedures. And the coders overestimated their broader intelligence enough to fail to imagine that there was a whole mass of law which the MERS masters hired the codewriters to nullify and subvert.
I read all the comments up to this point, and then re-read the essay. I have also worked in the software industry on and off, mostly on, since 1972 as a student punching fortran onto IBM index cards and then watching them gum up an IBM Series 360H, to a SatCom Digital tech in the military, to a cnc machine tool engineer, a software developer, large Systems Administrator and policy planner/developer – the last two items specifically within a section of our federal government.
With that said, I agree wholeheartedly with the concluding last 4 paragraphs of this essay.
But there is no way I would ever agree with the one sentence which seems to be the premise of the entire essay and which really bugs me and (obviously) bugs every experienced software engineer that has posted here is “In this story, software engineers summarily rewrote policies that had been in place for centuries, and arbitrarily replaced historical procedures run by clerks, land offices and judges with a buggy central data-base.”
They did rewrite policy, that seems to be clear based on the majority results in our Court Systems, but in no way did they do it “summarily” (def: in a summary manner; without the customary formalities) or “arbitrarily”.
But they did it because they were hired guns; they wrote it the way they did because that is what they were paid to do and the resulting software is what they were paid to deliver.
Period.
They may not have known “how to control (legal) paper, city halls or judges” but any good software engineer would take on the project as a challange of their abilities to simulate the real thing. I sincerely doubt that, although strongly inferred here, “they wrote them out of the software” intentionally. They did it because they were either not made aware of all the varied legal rules in the first place, or if they were made aware somehow, they were told not to do it.
From what I have read here on NC primarily as well as elsewhere, it seems to me that MERS was classic piss-poor planning, unintentional (doubtful) or otherwise, by the management of the groups that determined the specifications of the software and contracted that project out to the engineers who then wrote it to the designed specifications.
As Mr. Goodwin states, early industrialized history is filled with anecdotes concerning the overreach of engineers, but today’s software is specified for certain and specific results mostly by those in the financial departments and top-level management, not by software engineers. Blaming the laborers for the end result (think the original french ditch diggers on the Panama Canal or sandhogs building the Brooklyn Bridge) does not make for a very good argument.
(here I go again, replying to my own post – wish I could edit the original)
I am not decrying the overall post by Mr. Goodwin,
“does not make for a very good argument”
should read:
“is a bad premise for an interesting essay with overall good points regarding software engineering and its place in today’s world”
I am sorry if I implied that engineers summarily rewrote history on purpose. In the context of prior posts I was trying to be blameless, although it is hard to excuse lawyers who should damn well have stopped it before it was too late. I had originally tried to write that part of the post as speculation on how it could have happened, but out of the context of the previous two posts, I do agree it looks more sinister than intended. The point I wanted mostly to amplify was that bad software had been codified by courts.
I was trying to reach an ambitious argument that software engineering was struggling with exponential complexity, but we somehow need to figure out how to give control of our institutions back to the people that know how to use them, because currently by omission control is being removed from those who might use it for good.
Bob, you didn’t ‘imply’ that software engineers summarily rewrote policies that had been in place for centuries, you stated it explicitly.
“In this story, software engineers summarily rewrote policies that had been in place for centuries, and arbitrarily replaced historical procedures run by clerks, land offices and judges with a buggy central data-base.” – Bob Goodwin
Any fair examination of the MERS system development project would certainly prove that assertion to be non-sense.
The historical procedures run by clerks, land offices and judges was not summarily replaced by the actions of anarchist nerds, it was replaced due to the willful intent of the MERS shareholders at the time of the project’s inception.
To expect those of us who work in the industry, and have decades of experience in the process of SW development to accept your assertion that that long list of MERS owners, most, if not all of whom are banks, didn’t get what they wanted, and are in any way victims of some sort of creeping anarchy is the height of hubris.
I see nothing in your resume, or in this series of posts that would justify Yves’faith in your analysis, and with every equivocation that impression is magnified.
I completely disagree with the author.
Clearly the author misses the mark and has absolutely no clue as to the software engineering discipline. He gives way way too much ‘credit’ to the software programmers. Software programmers, while highly paid and intelligent, do not invent the code in a vacumn or on their own. There is a painstaking process which is gone through whereby ‘requirements’ are hashed out and some of the key folks in the process are ‘subject matter experts’. These ‘SMEs’ typically have extensive business knowledge in their respective domains, such as healthcare, credit card processing, telecommunications, finance, law etc.
The requirements development phase can take many months.
The requirements must include compliance with laws!
The result of the requirements phase is a document, approved by the powers that be in a company, which is a blueprint for the software programmers. They to do their coding conforming to the blueprint.
There are many more steps in the software development life cycle.
Being a Director of teams of software engineers and database administrators and data modelers and software architects, I can reassure you all that the ‘Code is NOT the Law’ and the author ought not to place blame or give negative credit to the programmers. The programmers are sophisticated ‘translators’ when they code. They turn business requirements, using programming languages, into code a computer uses to process the instructions to accomplish work.
As to MERS, I admit I have no first hand knowledge of how it’s requirements were done or as to who was the MERS ‘SMEs’. From all that I have read about MERS, it’s process could have exactly met its requirements exactly! Perhaps the SMEs did not look beyond their own limited domain to determine any requirements to comply with state property recording laws.
If I were engineering a MERS, I would have included county recorders as a SME and some real estate attorneys from various states and possibly others.
One other big factor in this is the outward pressure of the project funding.
The outward pressure keeps the project on track and sticking very close to the requirements! Programmers cannot run amuck and do whatever they desire.
I wholeheartedly disagree with the author.
The Code is Not The Law. I highly regard the skills of programmers (software engineers) but they follow instructions; the requirements in documentation format; the blueprint.
Those requirements should include the laws.
There are entire departments in Fortune 500s which deal with compliance to the laws!
From Reuters, Jan 20 2012;
“(Reuters) – U.S. Attorney General Eric Holder and Lanny Breuer, head of the Justice Department’s criminal division, were partners for years at a Washington law firm that represented a Who’s Who of big banks and other companies at the center of alleged foreclosure fraud, a Reuters inquiry shows.
The firm, Covington & Burling, is one of Washington’s biggest white shoe law firms. Law professors and other federal ethics experts said that federal conflict of interest rules required Holder and Breuer to recuse themselves from any Justice Department decisions relating to law firm clients they personally had done work for.”
http://www.reuters.com/article/2012/01/20/us-usa-holder-mortgage-idUSTRE80J0PH20120120
“Court records show that Covington, in the late 1990s, provided legal opinion letters needed to create MERS on behalf of Fannie Mae, Freddie Mac, Bank of America, JP Morgan Chase and several other large banks. It was meant to speed up registration and transfers of mortgages. By 2010, MERS claimed to own about half of all mortgages in the U.S. — roughly 60 million loans.
But evidence in numerous state and federal court cases around the country has shown that MERS authorized thousands of bank employees to sign their names as MERS officials. The banks allegedly drew up fake mortgage assignments, making it appear falsely that they had standing to file foreclosures, and then had their own employees sign the documents as MERS “vice presidents” or “assistant secretaries.”
Covington in 2004 also wrote a crucial opinion letter commissioned by MERS, providing legal justification for its electronic registry. MERS spokeswoman Karmela Lejarde declined to comment on Covington legal work done for MERS.”
W4B;
Bob Goodwin is in good company when it comes to providing cover for the travesty that is the MERS system, created from the top down as support structure for one of, if not the biggest heist in history.
I get the sense that Bob has been a ‘go-along-to-get-along guy’ his whole career, and that his experience with software development was mostly as a witness, ‘along-for-the-ride’ so to speak.
He probably thinks he hasn’t done any harm buy ‘helping us understand’ this ‘complicated’ situation.
Yves, on the other hand should know better.
The point I wanted mostly to amplify was that bad software had been codified by courts. — Bob Goodwin
A good point, if lost in the narrative. There are a lot of societal problems that arising from good –much less bad– Engineering that aren’t addressed by Engineering. That is left to the policy makers. How many jobs have been lost because of automation? As an Engineer, I would say thats the point, to reduce the human effort, to make future utopia scenarios possible. Its up to society to make sure that those people are cared for (and they should be). If our traditional institutions don’t keep up, then maybe we need to rework them as well.
“how the anarchist nerds that we call software engineers inadvertently started to hijack public institutions. More cynically we could believe that the software engineers where [sic] just useful idiots to corruption. But conspiracy theories are not necessary for this story, and given the pace of events, I doubt there were smart enough conspirators anyways.”
First, full disclaimer, this attack by Goodwin is personal, I was a software engineer so I take exception to his characterization of software engineers – not his “inadvertently started to hijack”, nerds are often weak in their social skills, but in his shifting the blame of the problem to the builders (software engineers).
Now, software engineers are not blameless. To use Goodwin’s favorite analogy (a wrong one in my opinion – a medical one would be better), if a building falls down or fails to make its users happy, the carpenders and plumbers may be at fault. You could argue, since carpenders and plumbers are professionals and do know their trade, that they have responsibility to ensure a safe and usefull building. I agree, up to the point of assigning more responsibility and blame to that group of professionals than they had for building said building.
But Goodwin’s argument is wrong, simply because there are other major players involved in building a building. Not to do an in-depth analysis here, but Goodwin singles out only one major group, dismissing or ignoring the other groups, and assigns all the blame on that one group.
Why do this? I submit it is to shift the blame away from Goodwin’s group or friends. It is the supervisors and directors who ignored or broke the law that the software engineers were instructed or allowed to do.
So the purpose of this posting, seems to me, to be the age-old technique of blaming a small, relatively powerless, group so to allow the harm done by the more powerfull and more responsible to continue unabated.
Hi Yves,
One of your best pieces ever.
Thanks.