Certification? Bring It On!
Not too far in the distant past, I was persuaded to give my résumé to a recruiter. He was trying to place a development manager for a growing company, and they wanted heavy Agile experience, deep management experience, and someone with some technical chops. Well, I figured that twenty-plus year of experience, with something like eight years of legitimate Agile, leading a team of twenty-plus, producing a product that won several Jolt awards and a JDJ Editor’s Choice award… I thought I was a lock for an interview.
But an email came right back:
The client is wondering where you got your degree. Twenty years of experience, and they want to know how I spent my time in the mid-eighties.
This got me thinking about certification. It’s another long-running debate. And something funny has happened to me.
I’ve switched sides. I’m actually in favour of certifying software developers. Yes, I am in favour of disqualifying intelligent programmers from professional employment if they do not possess a little piece of paper from a certifying agency.
Deep breath. Wait for the room to stop spinning. Or is my head spinning around on my shoulders (
heh)?
the catchLike everyone else in favour of certification, I have my own ides about what skills and knowledge you need to demonstrate to get your certification. Unlike everyone else, I think I would fail my own certification if I didn’t do a whole lot of studying. That’s because I think our industry is undemanding, very undemanding. I know a few people who would pass my certification without studying. But only a few.
Before I tell you what’s on the final examination, let’s talk about what
isn’t:
- Object oriented programming: not on the exam. Use OO on a project, don’t use OO on a project, I don’t care. Throw in dependency injection, MVC, everything to do with industry standard architecture. I still don’t care, you can get certified without it.
- Functional programming, metaprogramming, macros: not on the exam. Be an academic, be a language weenie. Or not. I don’t care.
- Static typing, type inference, annotations, category theory: not on the exam. Save it for your blog post, I don’t care.
- Knowing who Alan Kay, John McCarthy, or Ted Nelson are: not on the exam. I think it’s great to know the history of our industry, but I don’t care.
- Design Patterns: See OO above. I really don’t care. Write spaghetti code. Be Mel. I don’t care.
- Agile Development, Waterfall, GTD, or anything else to do with Getting Things Done: I really don’t care. I will certify you whether you can execute or not.
- Deep knowledge of programming language syntax or semantics: I’ll certify PHP programmers. I’ll certify Java programmers that don’t understand generics. I don’t care if you know what a closure is. I don’t care if you believe that recursion is retrograde.
By now, you are thinking, “Raganwald, this certification is worthless. You are excluding just about everything we know about writing great software. What’s the point?”
Let me explain. My certification does not say you are any good at coding software. Let me repeat.
My certification does not say that you are any good at coding software. I’ll let the marketplace decide. I am not telling businesses, “Hire certified programmers, they are great coders.”
Why should I? Business is perfectly happy to hire programmers with Comp. Sci. degrees, and there seems to be little or no evidence that a Comp. Sci. degree says anything about your ability do deliver working software. So why should my certification raise that bar?
what’s on the examNow let’s talk about what
is on the exam. Just one subject, but the exam goes into excruciating detail about that subject. If you don’t know this subject cold, I am
not going to certify you. Period. No debate, no negotiation, no “equivalent experience.”
The one subject?
Testing and Quality Control. That’s right. All I care about is that if you are asked to make bulletproof software, you know how. I’m going to ask you about:
- Continuous integration.
- Black box testing.
- White box testing.
- Design for testing.
- Probabilistic testing.
- Testing tools.
- Testing metrics.
- Testing methodologies.
And more:
- Security concepts.
- Preventing vulnerabilities.
- Privacy and data management concepts.
- Encryption and verification concepts.
And a whole lot more on top of that. There is room for debate about whether to have separate testers or whether programmers should test themselves. You are not getting certified with me unless you know how to do it both ways, and can write a comprehensible essay describing the relative advantages and disadvantages of both. I am not going to require you to know the latest programming frameworks, but you are not getting certified unless you demonstrate up-to-date knowledge of the latest continuous integration tools.
Test Driven Development: By Example is THE book that ignited a revolution in software development practices. Whether you are developing in an Agile environment or working from a telephone book specification in a Waterfall project, Test-Driven Development will show you how to write automated tests that work to actually shorten your development time and clarify your code.
And best of all, this book uses actual projects as an example. This is not an exercise in theory, this is a practical tome full of practical advice. You’re already familiar with the concepts, reading this book will dive into the details that will make your coding more effective.
I don’t care if you know how to write a great architecture document. But I will fail you if you can’t write a good code review. The same goes for everything else. I will not demand that you do it a specific way, but you will prove that you have state-of-the art knowledge of how to ensure that software is solid and does what you expect it to do, no more, no less.
And you know what? After you get your piece of paper, you’ll need to work for at least a year under the supervision of a certified leader to get your upgraded “practitioner” certification. I want you to practise continuous education.
Does this mean that I am going to certify all of the QA Analysts in the industry while barring the programmers from work? Well, let me ask you: do most, a few, or any of the QA Analysts you know have a deep knowledge of software quality and methodologies? Can they write an essay describing the cost of bug fixing comparing early vs. late detection? Can they talk about various unit testing tools? Can they measure code coverage? Can they look at a piece of code with 93% coverage and tell whether the missing 7% has one or more crucial cases missing?
If so, I want to certify them. If not, they need to hit the books with me.
where did I get this crazy idea?In our industry we have wasted millions of person-years debating the relationship between software development and architecture/engineering. Last weekend I went to see Pixar’s Ratatouille with my son. And it struck me: we should be like chefs.
Do I demand that the chef in a restaurant use a certain kind of stove? Cook a certain kind of food? Manage her kitchen a certain way?
Non! The marketplace decides all these things. And the marketplace works for this. What do we demand? What do we
require of restaurants?
Safety. We demand that if they serve the public, that they have certain fire safety standards. That they have certain food cleanliness standards. That they know enough about food not to poison us by accident. Of course, a cook learns to cook when getting their designation. But the thing we really
demand of them is that they keep us safe!
If we order Chicken, we do not want the Fish to come out and put us into Anaphylactic Shock. Cooks know that mixing up Chicken and Fish is fatal, while mixing up Basil and Oregano is not. So they have a different protocol for handing the two kinds of food. They keep us safe.
And if I am placed in charge of certification one day, that’s what I will demand.
Keep us safe. Don’t leave
back doors and XSS vulnerabilities in your code. Don’t store our passwords in the database. Don’t deliver code that is full of undiscovered bugs.
If someone can be relied upon to write software that is safe, I will not dictate how they do it, or how long it takes to do it. The marketplace can decide whether they are employable, much as a restaurant can decide whether to hire someone whose food is bland and unappetizing.
I am not telling businesses that they can’t ship software full of bugs. You have Product Managers, they can decide whether it is more important to build new features or fix the old ones. Microsoft, do your thing! But business can’t make those decisions unless they have an accurate view of what the software actually does, of which parts are solid and which are brittle.
And I am not telling managers how to run projects. But I do expect that a certified manager understands the trade-offs when she chooses BDUF over Agile,
Theory D over Theory P. She can do as she please, provided her eyes are wide open to the consequences.
Well, that’s my thought about certification. I’m all for it, don’t let anyone say otherwise. And like everyone else, I want it to reflect what my experience tells me is important about software development in the commercial environment, namely safety and a clear view of what works and what doesn’t.
This is obviously a pipe dream, the product of Dark Horse Café’s “Ruby’s Pride” French Press coffee. But what do
you think? Would such a certification be useful?
Labels: popular