We're building a deck, and even though the project seems relatively small to me, Arlington County has still had about 3 inspections -- and they haven't even started laying the decking yet.
The first inspection was based on the plans, the second based on the holes for the posts (or footers) and the third based on the frame of the deck.
These multiple stages of inspection make quite a bit of sense: with a minimal amount of the structure built (in the case of the plans, none of it being built), the inspector can easily tell where specific flaws might be. And the builder has got to appreciate the multiple inspections because an error corrected in one stage may be significantly easier than fixing it in the final version (moving a staircase over a few feet on paper is trivial, on the completed deck, not so much).
All this got me thinking - what if we did the same thing for software development?
Software Inspections?
What if you wrote a little code and a third party came in an inspected it. Sorry, they might report, the files are too long (just like the post holes may be too shallow) - fix it, we'll re-inspect, and if all looks good, you can continue.
The multiple inspection model also helps you avoid two common traps: (1) thinking you can describe the project completely up front in a requirements document - you can't. And (2) waiting until the project is ready to ship to do any sort of structural integrity checks, where it's too late to fix anything.
You could essentially do the same checks in software as they do for building:
- Planning stage - do you have some basic outline of a plan? Is it feasible? Or, were you just planning on meandering for months until the project just runs out of steam?
- Footers stage - Do you have version control and other best practices with which to build on? Or, were you just going to copy files all over the place and hope for the best?
- Framing stage - is the framework you've chosen to build robust enough to handle the system? Does it have egregious security issues like PHP's now-deprecated register_globals?
- Final stage - is the developed software well organized and easy to extend? Or, is it just a pile of loosely connected and randomly named files and functions?
Inspections are of course related to QA - but I wonder they wouldn't be more focused on safety and industry best practices. That is, they won't guarantee that a particular algorithm is working - just that you haven't named files in an obscure and meaningless way.
Of course there are major flaws with the inspection model. One of the main ones being, how stringent should standards be? For example, can I use a framework I've built myself to develop software on, or do I have to use some standard platform that's been 3rd party certified. Or, how much planning is enough - do I need a 50 page document, or can a stack of note cards with sketches on them represent the project well enough? One of the joys of programming is the ability to experiment with new ways of doing things - sometimes those experiments succeed, sometimes they fail. But to write off all deviations from known best practices as a bad thing, seems like a terrible mistake.
Another hurdle: egos. Would a team ever have the courage to invite a 3rd party inspector into their offices and stop work to fix issues that another (no doubt, inferior) programmer found? That seems like it would be a bitter pill to swallow.
Still, as I look outside and watch our little building project take shape I can't help but wonder what would happen to software quality if we had inspections. Why not take a lesson from an industry which has been building real things - things that can actually do bodily harm - for hundreds of years?
Inspections are what we software developers called iterative development. That way QA and stakeholders have a chance to see how the project is developing and change direction if it's not correct.
ReplyDeleteHi,
ReplyDeleteFirstly
Isn't this what Code Review is?
Secondly something you may want to look into that I personally have noticed on this topic on countless other blogs. Software construction is soooo often compared to civic construction, and somehow many are un-aware that it is just as notorious for cancelled, overdue and especially over-budget projects as software is, and it's been around much much longer.
It's not software, it's not building. It's just project management. Managing people and complexity is just... well complex.
The projects that succeed are nothing to do with the methods used (Planning, Inspections etc...) It's because the methods were applied by hardened veterans who have lots of experience (long trail of failed projects behind them) and can communicate almost telepathically.
Holy crap, I wish people would go out and read about software development processes before writing things like this.
ReplyDeleteMaybe it is a failure of industry and education for not enlightening everyone about common practice but this is common practice. Do you think people just do requirements and go off in a single-directional Waterfall model style of develop? You really think people that people never reflect on what they are doing?
Please go read a pile of books.
Software Retrospectives -- meetings after an iteration, reflecting on what happened.
Any XP book, I really don't care, just figure out what XP people do.
Some random scrum book, at least know what's in scrum.
Anything on the unified process, including the wikipedia page.
Anything on code inspection.
Anything on software development processes, agile or not.
Just read something, then you wouldn't have to write this!
Wow, I'm impressed I could hit such a nerve with this post. Apparently, I didn't make it clear enough. Let me try to explain:
ReplyDelete>> Inspections are what we software developers called iterative development
What I was suggesting was that a 3rd party does inspections and has the power to stop the development of a project if it doesn't meet some level of standard. This has nothing to do iterative development. My builder could iterate all he wants, but if the building inspector fails him on an inspection, he has to stop.
I wasn't making a comment about how software should be developed (Waterfall vs. XP vs. Scrum vs. ...) I was toying around with the idea of a 3rd party evaluating and blessing a project.
>> Isn't this what Code Review is?
If the code review was done by an outside party, yes. In all cases I've seen code reviews done, they've been done by someone on or near the team. That's the equivalent of the foreman reviewing the work of his workers. That's key. But not the same as the county inspector coming by.
>> Software construction is soooo often compared to civic construction, ...
I agree - the analogy is used way too often. On the other hand, I believe metaphors can be borrowed from any field if it helps (architecture being one that was a big hit). If we can learn something from it, then it's worth talking about.
Again - all I was noting here was the presence of a 3rd party and the role of universal standards.
>> Holy crap, I wish people would go out and read about software development processes before writing things like this.
And I wish people, when reading a post that isn't clear to them, would ask intelligent questions instead of assuming the author is a moron.
>> Maybe it is a failure of industry and education for not enlightening everyone about common practice but this is common practice
Really? What's the name of a 3rd party service that will certify my work as being "to code" - and how many companies use that service? Oh, and how would you define "to code" anyway?
>> You really think people that people never reflect on what they are doing?
What I was suggesting had nothing to do with reflection. It has to do with a 3rd party sticking their nose in your business and telling you what's what.
Look, this could be a totally crappy idea. And I'm cool if this is just written off as a crock pot scheme without any value - just thinking through it was fun. But man, you guys need to all lighten up.
This is what standards like Common Criteria (Cross government security certifications) are about. There are also ISO standards like ISO9660 which are framework enablers for this kind of work. Organizations such as LogicaCMG sell services in this space.
ReplyDeleteJust curious, but how often would this be challenged when businesses think software is the IP and not wanting outsiders seeing this? I guess this is a moot point with all the offshore development going on and NDA's in place? Or are the offshoring just building common components, such as a deck, and not a 102 story skyscrapper?
ReplyDeleteAnd speaking of such, shouldn't this also be applied to the integration of applications and their configurations that make up a solution? Example: Drupal & postgre (Intranet and Internet Biz Apps; F#$% SharePoint!) married up with Salesforce, Subversion, JDA Supply (SCM, Accounting, etc.), Infor HCM (HR), Hudson-CI, Cisco and F5? Call this the make-up of a 21st Century Supplier Business and certifying their infrastructure for the business structure they run.
>> Just curious, but how often would this be challenged when businesses think software is the IP and not wanting outsiders seeing this?
ReplyDeleteGood point. I think companies will always be resistant to opening their doors to outsiders and accepting criticism.
>>> And speaking of such, shouldn't this also be applied to the integration of applications and their configurations that make up a solution?
Yeah, I could definitely see an inspection need here, too.