Good Sentences, Bad Sentences

1. From Edward Conard:

The key to accelerating the recovery is not to generate unsustainable consumption, as Mian and Sufi propose. Rather, we must find sustainable uses for risk-averse savings

Mian and Sufi make a big deal over the fact that consumer spending fell in places where housing prices fell. Conard suggests that this is because consumers in those areas were spending at an unsustainable rate, based on capital gains in housing that disappeared.

2. From Alex Ellefson:

Laplante said he expects all 50 states to require software engineering licenses within the next decade, and possibly much sooner.

Not surprisingly, most software engineers endorse this. [UPDATE: from the article “The licensing effort was supported by nearly two-thirds of software engineers surveyed in a 2008 poll.” Commenters on this blog dispute that most software engineers endorse licensing. They may be correct.] But it is really, really, not a good idea. Bad software may be created by coders. But its cause is bad management. The typical problems are needlessly complex requirements, poor communication in the project team between business and technical people, and inadequate testing.

I would favor licensing for journalists if I thought that it would keep incompetent stories like this one from appearing. But I don’t think that would work at all.

The pointers to both of these are from Tyler Cowen.

This entry was posted in business economics, Financial Crisis of 2008, Tyler Cowen is my Favorite Blogger. Bookmark the permalink.

17 Responses to Good Sentences, Bad Sentences

  1. Effem says:

    Is it just me, or does the opinion of businessmen like Conard, always seem way more consistent with reality than that of economists?

  2. Massimo says:

    Most software developers endorse licensing requirements? Source? Anecdotally, I am a software developer, and the general sentiment I see is overwhelmingly not in favor of government licensing. Some people are in favor or more Coursera style certificates, but that is different.

    • Gary Steinmetz says:

      I’m also a software engineer and don’t want licensing, but widely accepted certifications for things like security would be useful once the industry matures more (it seems like everything changes too rapidly now). For all the challenges of this profession, I take pride in knowing that my compensation is less derived from rent seeking like my non-programming peers. Licensing – just say no!

    • Matt says:

      I’d also be curious to see a source for the claim that most software developers would endorse government licensing requirements. It wouldn’t match my experience either.

  3. Duane Moore says:

    I also would like to know if there’s a source regarding the software engineering licensing point. I am also a software engineer and my experience is the exact opposite.

  4. Andrew' says:

    Would it be theoretically possible to code a thingy that records coding time / re-coding time?

    That seems like the ultimate coder evaluator.

  5. Kevin L says:

    I don’t see how licensing software engineers will improve software if the rules are similar to other engineering disciplines. For example, as an electrical engineer, if I’m working for a large company, I don’t need a license. An engineering firm will typically have a few senior licensed engineers and lots of junior engineers doing the actual work. That’s the way software development works on large projects anyway, and those senior engineers already have incentives to be responsible. Would licensing just make them liable to criminal proceedings if the software they are responsible for fails?

  6. MichaelG says:

    We could license managers, if only someone could figure out what they do.

  7. Luke says:

    I sincerely doubt that most software developers favor licensing. At least, I sincerely hope that.

  8. Handle says:

    See the chart for “Mortgage Equity Withdrawal as a percentage of Disposable Personal Income”.

    As you can see, from the peak in early 2006 to the trough nearly five years later, consumption flowing out of home equity were as high as 9% of all disposable income, and fell as low as -8%, for a total change of 17% of disposable income.

    So when things looked brightest, a lot of spending was fueled by people using their homes like ATM’s because they felt they had received a wealth windfall. But this was only on paper as phantom ‘unrealized gains’ which later evaporated during the correction. Now people are allocating a historically large fraction of their disposable incomes to paying off their mortgages, instead of cashing out.

    A 17% change in the flows that go into consumer spending seems a completely adequate way to fully account for the financial crisis. It is an under-examined narrative.

    • Andrew' says:

      Is this “homes” per se, or is it “whatever credit vehicle hadn’t been burned lately”?

  9. roystgnr says:

    The anti-free-software trial balloons are starting to blot out the sun, aren’t they? I guess if “ban software whose developers aren’t officially certified” doesn’t fly, they can always try to reinflate “software needs to have a mandatory supported warranty” or “giving an open-source programmer a day job violates overtime laws” again.

  10. Jeff R. says:

    If there were licensing exams you could take to get certified as being qualified to code in certain languages, that might be kind of useful in allowing people to escape the tyranny of the BA/BS, no? Especially because coding is the kind of thing it seems isn’t terribly difficult to teach one’s self.

  11. Daublin says:

    I believe you have misread what software engineers at large want. The people that like licenses are the ones that already have the license in question, because the license becomes a form of security. For people without the license, the addition of licensing requirements is a threat. Especially in software engineering, with the highly varied backgrounds of the people practicing it, you just never know what random requirements are going to show up at the other end of the polittical process.

    That aside, there are some particulars of software engineering that are worth noting.

    One is that the best practices are changing rapidly; for example, continuous building was unusual 20 years ago, but now is the norm. Except for C, programming languages are coming and going at about a decade or two each. These changes may feel slow for a practicing engineer, but they are too fast for a regulatory agency.

    As well, there’s already a robust and effective system of private-sector certification. Microsoft and Oracle, to name two of the big kahunas, have certification programs for people that are good with their technology. On the hiring side, you can decide if a particular role merits the premium you will have to pay for a Certified Oracle Professional; maybe a Certified Oracle Associate would be good enough, or maybe you know the candidate well enough to not require the certification. On the engineer’s side, you can weigh the costs of extra certification versus the job opportunities it will open up. It’s libertopia, and it seems to be working.

  12. JKB says:

    I just clicked over here from reading a post on the burgeoning trade in services post at Conversable Economist. The rise of international trade in services, and coding is really something that can be zipped around the world, seems like it would moot any attempt to require licensing for software engineers. Maybe if the R&D was in a state but then coders could be anywhere. And coders in the state could be coding for a client that doesn’t do business in the state or country where licensing is required. Or even coding software for a product that will ever be used in the state or country.

    What will jumble things up at least for US workers is the export laws. Just because you can code it doesn’t mean you can send it across the border or supply it to a foreign national.

  13. Etienne Noel says:

    In my opinion, the problem with the inability to complete successfully software projects lays somewhere else. We are trying to to build system that would work for everybody in all the different circumstances. For example, the electronic health records system in Britain is a perfect example. The time it takes to collect all the information and requirements of the software, the time it takes to conceive the software, you now find yourself many years later in a completely different environment where the technology and the tools have evolved by an amazing growth factor. At this point, you should rethink your conception since the software would be deprecated shortly. Therefore, since we don’t have the technology yet to manage huge projects like those, we should maybe decentralize projects. Still in the electronic health records system, an idea may be to create applications for a region of hospitals and then focus on unifying the communication protocol between the softwares of the different regions. Maybe this is not the perfect idea, but I’m feeling the problem here is that bigger projects should be decentralized.

Comments are closed.