Courtesy of Confreaks. Good stuff. Currently watching the presentation on Treetop, a DSL-based parser framework for Ruby.
Joel Spolsky’s recent talk at Yale has some interesting bits on software quality.
He claims that über-geeks tend to focus on defining quality strictly as conforming to requirements (à la Crosby), and thus try to write automated specs for the whole program. Now, trying to write complete specs becomes the “software engineering equivalent of a perpetual motion machine”, since if your specs are complete, they describe the whole program accurately, and could be thus used to generate the actual program somehow – after all, your specs will end up being as detailed as the program itself. (btw, I love any blog entry with the terms “perpetual motion machine” and “crackpot” in it)
Naturally, the concept of “complete specs” is unrealistic and is there just for the argument’s sake (let’s just strive for “enough specs” instead.) Also, any sane definition of software quality goes beyond “literally adhering to specs.” Different stakeholders have different perspectives on quality. General product quality concepts that originate from the manufacturing industry tend to view specifications as the producer’s “path to victory.” Adhering to them should be enough to produce a high-quality product – from the manufacturer’s point of view. The value perceived by customer can be different, and consists of different attributes such as price, performance and reliability. The ultimate validation of quality is always customer satisfaction.
Although all generic product quality concepts don’t necessarily translate to software quality, there are recurrent themes on both sides: customer is king!
Stephan Schmidt has a blog entry on how explicit static type declarations are for the benefit of the developer, and not the compiler. That is, when you have something like this:
Person person = mysteriousCall()
you know at a glance that the object reference person is in fact of type Person. To a compiler, this might be obvious through type inference – in this case, by looking at the return type of the mysteriousCall function.
In Java, you always declare the member types explicitly, but for a statically typed language that does rely on type inference (I’m thinking Scala), the type declaration Person is clearly redundant. And if there’s one thing any programmer hates, it’s redundancy. So, one could just go with
val person = mysteriousCall()
and be done with it: the compiler will infer the type. Now, Schmidt makes a good point in that now the type of person is not immediately obvious to the naked eye, since there’s no explicit declaration in sight. This gave me an idea, which I posted as a comment to the blog entry:
What if a smart IDE could consult the compiler and decorate / annotate the above code line visually by showing the type of the person field? Now, the type would be explicitly shown to the user, but information that’s available through type inference wouldn’t have to be duplicated in the actual code.
Something like
val person : Person = mysteriousCall()
where : Person is the visual aid shown by the IDE, in standard Scala type declaration notation. Now, the type of the value is clearly visible, but there are no redundant type declarations in the code.
I wonder if anyone’s thought of this before (likely), and whether some tool already implements this for some language with type inference (less likely)?
I changed the visual theme of this blog (feed reader users ahoy) and “officially” discontinued my old blog, the contents of which will be migrated here at some point. Also, the RSS feed for this blog is now available via FeedBurner.
So, things got a bit busy a while back, and my blogging activity took on a steep decline. The thesis is progressing just fine, I’ve been delving deep into a bunch of interesting history behind the theory and practice of the concept of continuous quality. Craig Larman’s talk on Lean Thinking and the Toyota Production System at the recent Agile Finland conference got me interested in how some of the quality control measures Toyota engineers implemented some 50 years ago have influenced the QA activities we see in (agile) software projects today. Fascinating stuff.
Two books worth recommending: The Toyota Way outlines and explains the principles and practices behind the Toyota Production System, and lessons Toyota learned from prior work by the renown US quality consultant W. Edwards Deming. The Poppendiecks’ book on Lean Software Development ties the Lean principles all together with software development.
Having done the necessary paperwork earlier this week, my thesis is now officially underway. I’m currently sketching the table of contents to get a feel of how to organize things. Apart from a brief 2-page introduction, I haven’t done any actual writing yet, but I’m hoping to put in a couple of pages on general software QA theory and practice during this week — yeah, the easy stuff first. Also, I have a preliminary schedule in the works. The deadline I thought of at first seems a little unrealistic at the moment, but I’m trying to keep things agile and re-evaluate my progress as often as possible.
InfoQ has a piece on how the Adium (a kick-ass IM application for OS X) team does code reviews by going through SVN commit mails and looking for anything suspicious. That’s all good, and certainly a practice that’s been widely adopted where I work as well. But the thing that caught my eye was this quote by Peter Hosey:
Some of them also made me think “man, I wish we had some tests, since those would have caught this”.
Manual code reviews are certainly beneficial, but I couldn’t imagine doing them without having good, automated tests for my code first. Just think of the regressions issues…
Just got the “OK” on my thesis subject from the professor, yay! Need to get some paperwork done next, and after that my thesis will be underway officially. Bureaucracy…
I’m writing this entry from a bus, hooray HKL (Helsinki transport authority) for free WLAN!
So, yesterday I managed to copy our department’s official LaTeX template and set it up for my own needs – and write some 2 pages of actual text for the introduction! As I mentioned before, all of the text will probably end up scraped off the face of the earth later, but most importantly, some of my ideas are now actually down in writing in a format nearly comprehensible for other people. Only some 60 pages to go 
On the tool front, I’ve been using TeXlipse, which I grew to like when using it in a couple of earlier university projects. In addition to basic LaTeX syntax highlighting capabilities, it offers some neat little completions, such as automatically matching a \begin{something} with an \end{something}, and also automatically completing my BibTex citations for me (see screenshot below.) TeXlipse does have its quirks, but overall it’s pretty great. Its development seems to have died down, though, so trying to open an empty BibTex file will cause you problems to the unforeseeable future.
TeXlipse has a simple but efficient model for generating a PDF of your LaTeX sources: you simply point out the main LaTeX file in your project, select the output format (and the command used to produce the output), and you’re off. Now, whenever you make changes to your source files and save, TeXlipse bakes you a fresh PDF in the background. Thus, my writing cycle is simply write, save and “reload” in my PDF reader.
In addition to TeXlipse, I’m using a tool called Rubber for keeping the LaTeX compilation process nice and clean when run from the command line (Rubber and LaTeX, gotta love the kinky vocabulary of scientific writing.)
All of my LaTeX source files are under version control, naturally. My tool of choice is Git, which I’ve been playing around with in all of my recent projects. My usage of Git is far from complex, and I’m definitely not bending the tool’s limits: I’m basically just enjoying the possibility of committing locally when I’m offline.
Now, off to get some sleep. More coherent thoughts tomorrow, hopefully.
Most of the articles I’ve come across while browsing through the ACM digital library and IEEE Xplore have been very good, quality-wise. No wonder, since most of the articles listed on these sites have gone through a peer-review process and have appeared either at conferences or in scientific papers worldwide.
That’s not to say that all of them have been good. For example, I’m just glancing through a paper entitled Software Quality and Agile Methods, that – judging by its name – should fit the subject of my thesis quite nicely. The paper was released in the proceedings of the 28th Annual International Computer Software and Applications Conference (COMPSAC’04), but in reality, the paper seems to me as if written by a group of students for their Software Engineering 101 course (no offense to the authors, perhaps this has actually been the case.)
The paper is quite superficial in that it spends the first 3 or 4 pages giving an overview on agile methods in general, and then comparing them with the waterfall model, and not making any great strides at that. The research is more of a rehashing of known facts apart from a few conclusions the authors make. It also makes some seemingly unverified statements, such as the authors’ problem statement:
Can agile methods ensure quality even though they develop software faster [...] ?
While there are certainly results that indicate that agile methods might result in a faster turnaround time for a piece of software, this can’t be generalized just like that. And for me, agile methodologies encompass more important features than finishing the project quickly. For example, producing software that the customer really needs (and not just what she thinks she needs at first.)
The authors continue with
Testing and simulation are dynamic techniques.
Sometimes static techniques are used to support
dynamic techniques and vice versa. The waterfall
model uses both static and dynamic techniques.
However, agile methods mostly use dynamic
techniques.
Profound thoughts
On a more serious note, all I’m saying that it’s worthwhile to really dissect and assess your source material, instead of just taking it as the [your-deity-of-choice]‘s honest truth.
