Repercussions

If I were in government right now, I would be leery of starting another big software project. I’d also know that big software projects are going to be necessary as our civilization gets more and more complex. So, if I were in government right now, I’d be thinking about laws to regulate the Software Industry. I’d be thinking about what languages and processes we should force them to use, what auditing should be done, what schooling is necessary, etc. etc. I’d be thinking about passing laws to get this unruly and chaotic industry under some kind of control.

If I were the President right now, I might even be thinking about creating a new Czar or Cabinet position: The Secretary of Software Quality. Someone who could regulate this misbehaving industry upon which so much of our future depends.

Maybe that thought hasn’t occurred to them yet. Maybe. But how many more healthcare.gov debacles will it take before it does?

~ Bob Martin, from Healthcare.gov

Most people I’ve talked to, (who write software or do systems and network administration,) are in the “I have work to do” camp. They’ve no time to think about professionalization, or standardization, of their field. To which I say:

That’s cool; I understand. No worries! The government will eventually get around to ramming standardization and licensing down your throat. I’m sure that will work out well for us.

If you work in these fields, you should be paying attention. If you wok in network and systems administration, you should be paying attention to LOPSA and Usenix/LISA.

Update:

Feb 2014: Senate Steps Into the Data Breach Controversy

Why is estimating so hard?

It turns out that we don’t know the procedure. We haven’t got any clue to just how difficult the procedure is. We aren’t computers. We don’t follow procedures. And so comparing the complexity of the manual task, to the complexity of the procedure is invalid.

~ Uncle Bob Martin, from Why is Estimating so Hard?

It is use cases all the way down

The center of your application is not the database. Nor is it one or more of the frameworks you may be using. The center of your application are the use cases of your application.

~ “Uncle Bob”, from NO DB

It is done fast enough when it is done well.

(Part 3 of 69 in ~ My Journey)

http://blog.8thlight.com/uncle-bob/2013/03/11/TheFrenziedPanicOfRushing.html

Getting done right does not mean getting done slow. Getting done right means getting done fast. You will go faster if you do things right. You will go faster if you come down off the “high” generated by the illusion that effort is speed. You will go faster if you calm down, follow your disciplines, and refuse to rush.

~ Bob Martin

While he’s talking about software development in general, and test-driven development specifically, this is true for – I think – everything. My experience is that this is true for software development, and other technical work. But it is also true of martial arts practice, parkour, games, building model airplanes… you name it.

The pervasive admonishment should be “do it well,” rather than, “slow down.” Do it well and you’ve – by definition – done it as fast as possible. What’s the point of doing it poorly? What’s the point of rushing to completion; If you didn’t do it well, then it’s not done.

ɕ