Tag: Software Engineering

Sabermetrics for Coders


An very interesting book has been published recently by O’Reilly called Codermetrics.  While I don’t agree with everything the author writes, he should be applauded for his innovative new way at looking measuring developer productivity.  For too long, we’ve had Dilbert-like managers trying to measure programmers on things such as “Lines Added” or “Amount of Check-ins”.  These types of examples are insulting to professional developers and we usually try to find clever ways around it (tons of comments for instance).  Jonathan Alexander takes a different approach by using common sports stats like an “Assist” and applying them to software development.  I would get an “Assist” every time I helped a developer on my team fix some code or answer a tough question.   The other developer would have to approve that I did indeed “Assist” them.  With all the publicity of “Sabermetrics”, Billy Beane, and “Moneyball”, this book is right on time.  Check it out!

Glitches


So, I’ve been playing way too much Modern Warfare 3 (MW3) and I’ve noticed a new word that at first glance was a replacement for “bug”.  Players refer to “glitches” in the game where say a body will lie suspended in air even though they it fall to the ground.  It doesn’t stop the game, but it is not expected behavior.  Now I doubt that there was a requirement in the MW3 software development plan that stated, “All bodies, once shot, will fall to the ground.”  And they probably didn’t have a test case around it either.  But because it is a game based on reality, you notice when something deviates from reality.

In my graduate testing course, we had specific definitions for terms like faults, bugs, and errors.  But we never mentioned the word “glitch”.  The Software Engineering field needs to get ready for this term and to help that, I’ll attempt to define it.  Now the Oxford English Dictionary defines a glitch as a:

A surge of current or a spurious electrical signal (see quots.); also, in extended use, a sudden short-lived irregularity in behaviour.

Interestingly, it seems Astronauts used the term a lot.  Here is a quotation from John Glenn:

1962   J. Glenn in Into Orbit 86   Another term we adopted to describe some of our problems was ‘glitch’. Literally, a glitch is a spike or change in voltage in an electrical circuit which takes place when the circuit suddenly has a new load put on it.‥ A glitch‥is such a minute change in voltage that no fuse could protect against it.

I think these two pieces of information help define a software glitch.  One, it is short-lived and the application continues to run smoothly overall.  Second, it is very hard to reproduce and hence creating a test case for it is also inordinately difficult.  Third, because it is short-lived and doesn’t bring the system down, it is a possible siren of something more troubling going on, but it could just be a “one-time” thing.  Very similar to the movie “The Matrix” where Neo notices a “glitch in the Matrix” and it alarms the others because that usually means that the Matrix is being changed by the agents.  Although it could also just be deja vu (the glitch Neo saw).

A Historic Bug


The recent “bug” that afflicted the BATS trading system will probably be one for the ages and go along with other famous bugs like the Ariane 5 rocket and Y2K problem.  Of course BATS is calling it a “freak one-time event”, but this bug caused massive losses of money.  Fortunately there was no loss of life, but past bugs have caused this  like the Therac-25 radiation therapy bug.

I am a huge advocate for Software Engineering and the growth of this profession.  When I study the growth of similar professions, such as Civil Engineering, the government did not get involved and create certifications like the PE until there were massive loss of life due to bridges crumbling.  It is unfortunate that a similar type of software bug will cause the public to take notice of the pervasive influence of software in our society and needs to be recognized as a profession in its own right.  There have been close calls like the Toyota brakes problem which had a lot of software in it, but was ultimately the software was not found to be at fault.  Here’s to hoping that the government and public don’t wait to recognize Software Engineering as a profession.

New Software Engineering High School!!


Joel Spolsky just posted on a new high school being opened in NYC that will concentrate on creating software engineers!  What a great concept and it’s totally awesome that it will become reality!  If universities can’t change their CS curricula to keep up with the rapidly changing field of software development, then hopefully this high school will be the antidote!  A very exciting development!

Great article on distinction between Software Engineering and Software Development


Even though this article is five years old, it is just as salient and relevant today as then.  The author’s main argument is that software development is applied software engineering.  What a great way to think about the two concepts!!!  I think he’s exactly spot on, but it’s hard to get to this idea because of our experience of engineering is applied physics and physics is applied math.  I’ve never thought about applied engineering!  I always thought it should be applied computer science, but I was never comfortable with that idea.  I rarely use concepts from CS.  Maybe algorithms, but that’s about it.  This really fits!!  I encourage you to read this article if you’re interested in how our field is shaping up in this century!

http://www.ibm.com/developerworks/rational/library/dec05/pollice/index.html

 

CMMI version 1.3 and Agile


Well, the Software Engineering Institute (SEI) just published the newest version of the venerated CMMI and there are many side notes in the CMMI-DEV version that touch on using an Agile methodology with CMMI.  I’ve always thought this was possible and I’m glad to see the SEI has taken the lead.

For example, here is the “Agile note” in the configuration management section:

In Agile environments, configuration management (CM) is important because of the need to support frequent change, frequent builds (typically daily), multiple baselines, and multiple CM supported workspaces (e.g., for individuals, teams, and even for pair-programming). Agile teams may get bogged down if the organization doesn’t: 1) automate CM (e.g., build scripts, status accounting, integrity checking) and 2) implement CM as a single set of standard services. At its start, an Agile team should identify the individual who will be responsible to ensure CM is implemented correctly. At the start of each iteration, CM support needs are re-confirmed. CM is carefully integrated into the rhythms of each team with a focus on minimizing team distraction to get the job done.

I especially like this one from the Requirements Development section:

In Agile environments, customer needs and ideas are iteratively elicited, elaborated, analyzed, and validated. Requirements are documented in forms such as user stories, scenarios, use cases, product backlogs, and the results of iterations (working code in the case of software). Which requirements will be addressed in a given iteration is driven by an assessment of risk and by the priorities associated with what is left on the product backlog. What details of requirements (and other artifacts) to document is driven by the need for coordination (among team members, teams, and later iterations) and the risk of losing what was learned. When the customer is on the team, there can still be a need for separate customer and product documentation to allow multiple solutions to be explored. As the solution emerges, responsibilities for derived requirements are allocated to the appropriate teams. (See ―Interpreting CMMI When Using Agile Approaches‖ in Part I.)

Download the latest CMMI-DEV and enjoy!

Software Engineering isn’t dead yet, BUT….


Tom DeMarco wrote an article a couple of years ago proclaiming that Software Engineering was dead that caused a real stir in the software field.  I opposed his view then; but sadly I’m beginning to think he had seen a glimpse of the future.

Today I did my last search for SWEBOK (the Software Engineering Book of Knowledge) in hopes of actually finding something coming out of this incredibly slow and opaque group.  My expectations were met, as they once again neglected to tell anyone where exactly they are in their unpublished process.  If any democratic process was run like this, we’d see Wisconsin style protests.  But alas, this is a dying beast that is finding its way to the bottom of irrelevance.

I think it started with the Agile Manifesto.  Almost none of the signatories came from Academia and it has shown.  They don’t publish in IEEE Software.  They don’t need to.  They get things done.  Which, of course, is what many academics in Software Engineering can’t do (see Exihibit A – SWEBOK).  I don’t want to paint too wide of a stroke.  There are of course exceptions like Mary Shaw and Tao Xie.  But many academics published articles are much like science fiction, somewhat entertaining, but not really useful.

This stems from the fact that most are tenured and have never worked a day in their life as a REAL software developer.  Its like writing about sex while still a virgin.  Exciting for the writer, but woefully invaluable for anyone else.  Let us look at the present month’s edition of IEEE Software, their leading journal. Oh wait, that will be $20 an article (because we all know they are just that valuable).  A requirements article, that looks potentially useful.  Oh it’s about GORE and SORE.  You don’t know about GORE and SORE !?! Oh you better get in the know; because that’s the new rage in software development.  Yeah, Dr. Seuss invented the terms.  Wait, an article on Architecture, now that should be promising.  “Unusable Software is…”  wait for it….. “Useless”.  Woah!!!  What a find!  20 years from now we will definitely be talking about this one.  And wait, you get more,  it’s only Part I!!!!

We don’t even use the term Software Engineering any more in the field where we actually create software.  We call it software development.  We can’t even agree on the same term!  IEEE Software went downhill after Steve McConnell (someone who HAS written real software) left and it may have been an omen that Software Engineering is going down too.

 

Code Reviews


Code reviews are a best practice developed back in the early 1970’s by Michael Fagan.  He was a computer hardware engineer by training and knew from experience that reviews in his previous field found quite a few defects before a hardware spec was sent to the factory to be burned onto silicon.  It was expensive to undo defects once the spec had been sent to the factory and reviews were a great tool in catching defects early.  His original paper describes the “Fagan Inspection”.

As time has gone on, more papers and books have been published on the subject; most notably Handbook of Walkthroughs, Inspections, and Technical Reviews by Daniel Freedman and Gerald Weinberg in 1990.  The best current source for how to do reviews is the IEEE Standard 1028 for Software Reviews and Audits.  Regrettably, the IEEE does not make their standards free to access, which I think diminishes their use and ultimately their importance.  In it they describe four types of reviews: a Management Review, Technical Review, Inspection, and Walkthrough.  I have taken these four descriptions and amalgamated them into a review procedure that, I think, brings the four procedures together nicely.  I post it here for your edification and use.

Code Review Policy & Procedure