(or rather respect and stimulating work...)

While we were in Dijon testing our new system I read most of the last IEEE Computer issue - which I often do not, but reading magazines filled out the cab rides. In it you find this article. Nicholas Carr blogged and a pretty nice discussion followed. I certainly disagree with the conclusion Nick comes up with, and I think that the article is more nuanced but many statements are made without proper underpinning. Regardless, the discussion inspired this pretty funny cartoon, too. One commenter (Tony Healy) drew the parallell to geeks great nerd needs: I think that the need for respect and the awesome feeling of being able to help others is magnified in most geeks. Some thrive on the "I am smart" feeling. Like most, I have transformed mine into, "see, you can do it this way!", after which I often get a "oh, great, thanks!", which gives me a warm, fuzzy feeling inside.

That - and feelings like it - are what I live for. Sure, this can be taken advantage of, and is taken advantage of, I'm sure. But, at the end of the day, as long as I keep getting what I live for... it's pretty much ok. Soon, I will cultivate the business person in me, or something... Right now, I gotta go on doing some demos this lovely sunday afternoon.

<rant>
Being an avid resharper user for several years, I cannot live without it.

As time goes by, I also feel that I cannot live with it.  It seems to me that the quality of the product (which has never been great) is spiraling downward.

So this is a word of warning: Before you get addicted to the features, realize that you will pay a price in bloat and bugginess in the studio, that may or may not be substantial.

In one out of my three current setups it's not that problematic.

In my daytime setup with the latest stable patch, it is crashing the studio several times a day, and the bugs I have mailed them have never been fixed.

Reinstall of my environment is probably the way to go right now, but it is eerie that not much has changed except the resharper updates.

Most people I talk to have similar experiences, turning the thing on and off, like a bad relationship. Bugs and bloat seem to appear often at blogs discussing resharper. What are your experiences?

Is it worth 249? Sure, its a great product. 249 + much of your time? Hmm, I'm starting to loose faith.

</rant>

I am here in Cambridge, at the SPA conference, and held a workshop on testability and encapsulation. I promised to publish my sources, so here they are! I will post presentation in the near future.

Most of the articles can be found via acm (portal.acm.org) or ieee, but I always search via google which usually leads to acm.

 

Abstraction, information hiding and encapsulation

Most of the good stuff here is from different OOD books. Here are some old articles I found interesting, (tiny archaeological warning), worth skimming:

    "Data abstraction and hierarchy"
        Barbara Liskov
        OOPSLA 1987
    "Encapsulation and inheritance in OO programming languages"
        Alan Snyder
        OOPSLA 1986
    "Encapsulation constructs in systems programming languages"
        W. F. Appelbe, A. P. Ravn
        ACM Transactions on

        Programming Languages and Systems (TOPLAS)
        April 1984

Parnas on information hiding is classic but the examples dated.

    "On the criteria to be used in decomposing systems into modules"
        D L Parnas
        Communications of the ACM, December 1972

Abstraction is not mechanics of coupling, but is about semantics and meaning - designing is creating models that communicate:

    Good vs. Evil: Abstraction
    Manuel Klimek, article on blog
        http://klimek.box4.net/blog/2007/03/18/good-vs-evil-abstraction/

 

Testability

If you read just one article on testability, Binders old from 12 years ago is the the best I've read. You will have to "translate" concepts to todays terms, and it pretty condensed (but it is at the same time not "being difficult"), read it twice.

    "Design for testability in object-oriented systems"
        Robert V. Binder
        September 1994 Communications of the ACM

The first article I've read that actually talks about testability of software with respect to test creation in a pragmatic way, is Freedman. It is still interesting, although not as current. It's non OO and a bit silly on the math side, especially for a practicioner, but I just skim that...

    Testability of Software components
        IEEE Trans. Software Eng. 17(6): 553-564 (1991)   
        Roy S Freedman

Not so long ago I found an excellent recent summary of testability work, that I could have made good use of earlier. (Note the weird publishing spot.)

    "Predicting Class Testability using Object-Oriented Metrics"
        Magiel Bruntink, Arie van Deursen
        September 2004
        Proceedings of the Source Code Analysis and Manipulation, Fourth IEEE
        International Workshop on (SCAM'04) - Volume 00 SCAM '04

Magiel Bruntinks "Testability of Object Oriented Systems: a Metrics based approach" (dissertation, 2003) is pretty nice as well.

We talked about two basic models of testability, which were kind-of based on Binders categories of fault and conformance directed testing. A model of testability that focuses on fault directed testing is that of Jeffrey Voas. He has published alot, I found this article to be the most accessible:

"Software Testability: The New Verification"
    IEEE Software may 1995
    Jeffrey M. Voas, Keith W. Miller

There are a couple of others worth checking out, this one is ok:

"Factors that affect software testability"
     Voas Jeffrey M.
    October 1991          
    Technical Report
    Publisher: NASA Langley Technical Report Server (available via acm)

Stefan Jungmayr has published alot an+d has focused on dependencies and metrics, this short article sums up alot of his work. Both this and more can be found on www.testability.de/E_index.html:

    "Testability and unit testing"
        Stefan Jungmayr

His dissertation is lengthy, there is some useful stuff there. His clear definitions of dependencies are a good contribution.

 

Books

If you want a good and accessible text that does cover a lot of the issues we talked about, I really have found good use for Feathers "WELC" book. I recommend it to anyone learning behavior driven or test first design as well.

    "Working effectively with legacy code"
        Prentice Hall, 2004
        Michael Feathers

Chapters addressing test construction factors: Chapter nine and ten talks about controllability and a little about observability. Other chapters talk about design and abstraction, notably chapter 17. Great book on the subject of testing object oriented code, one of the best IMHO.

There's also Binders enormous book, which is not mentioned that often, so I'll mention it. The parts I've read are excellent, but it's quite enormous. He should have split it into several.

    "Testing Object-Oriented Systems: Models, Patterns, and Tools"
        Addison-Wesley 1999
        Robert V Binder

 

Testing general

I brought up some stuff (the testing periods, etc) from an old article that is really nice, and highly recommended, well worth a read. Short easy read that has many insights, although it is a bit historical.

    The growth of software testing
        D. Gelperin, B. Hetzel
        June 1988, Communications of the ACM,  Volume 31 Issue 6

This is an old classic and still very amusing read, could use another font:
    "In defense of program testing or Correctness proofs considered harmful"
        Andrew S Tannenbaum et al
        ACM SIGPLAN Notices Volume 11 ,  Issue 5  (May 1976)

 

OO

I mentioned the study on core OO concepts:

    "The quarks of object-oriented development"
        Deborah J. Armstrong        
        Communications of the ACM  archive, February 2006

 

TOOP - Testable object oriented programming

There has actually been some work on what testable object oriented programming might mean. What I've read has not been terribly interesting, but here is one I read anyway:

    "On testable object-oriented programming"
        Y Wang, et al
        ACM SIGSOFT Software Engineering Notes, July 1997

At the latest AgileØresund meeting we had the usual mix of new and old people representing both devs/techleads and project managers. I (again) wanted to talk about team morale. Being a consultant I get to move between company cultures quite often, which allows me to more easily see and experience differences among them. Having worked for some of the larger traditional companies in Sweden, this is a most fascinating aspect. It is fun to reason about how the company culture has been devised and/or emerged, and what the logic behind it is - what must have been the benefits the leaders saw when promoting some values inside the organization? Morale in a team comes both from the context - from "upwards" if you like - and from within the team. A team needs a vision in order to believe in the work they do. If you do not think that the work you do will matter to anyone at all, then you are not likely to invest heavily in the work. From within the team, a breach of morale will spread: If someone looses faith in the project, that may spread and will at the least affect the others.

 

I think there is a junction where these things meet; how we express our faith and passion can become a heuristic that is then expected - a mindless rule that the team has to work overtime at some point, that the team has to do this and that. (Well, blindly following rules is almost never good, nothing new there.) This junction is basically where acting and appearances are more important than actual results. Acting and appearances are naturally very important, but are not directly related to the results.

 

Anyway, Chris mentioned this post from Kathy Sierra (I don't read her blog regularly anymore myself) that talks about the target of passion - company or work. I really see a connection to her post.

Roy blogs about testability in the language. I definitely think that the language could cater testability, much like it connects with other development needs. For example, in .NET there is the obsolete attribute which we may decorate a method with, which causes the compiler to issue a warning if someone compiles code that uses that method.

Likewise, I have for some time wondered if using an attribute indicating that a method is for testing purposes only would be useful. I think so.

Anyway, thanks for this Roy! It's amazing to see how quickly that debate springs up again! I am doing a workshop on testability and encapsulation and this is definitely inspiring, I almost thought that everyone had already gone past the encapsulation debate and that I wouldn't get anyone to discuss it with - but here is proof that it is not so again!

Hopefully we'll get even more perspectives.

There was a project called the Netron project a while  back, that offered a nice graphing library and several related libraries. I used to check the blog regularly, to see progress, and so on. I stopped for a year or more, but not so long ago, I ventured to do so again. I got really suprised, and went to do some checking. Check this adress, you may be surprised to:

 

http://netron.sourceforge.net/

 

Don't read on until you've checked it!

 

Checked it?

 

Were you surprised? I sure was. If you did not bother to check it, the sourceforge project page has been emptied of all contents (don't know if the source was ever hosted there though, here is someone saying that the CVS repos were removed, which would be very odd indeed). The project homepage link instantly redirects you to an ordering page for a graphing product "Go Diagram". Basically, an ordering page on sourceforge! Odd!

 

In summary, Netron was an open source project that did not use a well known license, but the license was a "use anyway you want" type of thing. It appears to be affiliated with this go diagram commercial venture, but there is no indication of how or why. I don't think there is anything wrong about that, per se. These things feel strange to me, though:

• The redirect from sourceforge to the order page.
• Not leaving a trace of the OS project - after you have accepted donations to the open source project. Check out the thankyou note to "Axel" at the end of this page.

It looks strange, and not pretty. If I had to call it by the looks of things, someone went commercial with the stuff and (perhaps even as insiduously as being part of some agreement?) removed all content they had control over, everywhere (sourceforge, codeproject articles, etc).

 

Other people have written about this, I wanted to note my own findings here. Do note this posting. There is a resurrection project for the source here, and much of the previously available documentation is hosted here. You can of course browse the archived versions of the homepage, archived codeproject article, and blog. It is strange, isn't it?

(Photo: Tony Richards, Herford)