Software Creativity 2.0 – Quotes and Thoughts

As a follow-up to my rather useless book review section update a few days ago I decided to write some more about Software Creativity 2.0 by Robert L. Glass.

It is easy to read this book and see it as “merely” an important book with a number of important essays. But for me it sparked a few interesting (at least to me!) ideas and it made me recall a few long lost thoughts about the “dichotomy of discipline and flexibility” in the field of software, computer science, programming, etc.

Let me present here a few quotes from the book.

But let me start with one of my (trivial) thoughts that has been stuck with me since reading the book:

The Formal/Structured/Disciplined Approach of Software Development could be characterized as “the act of solving”.

The Heuristic/Agile/Flexible Approach of Software Development could be characterized as “finding previously not known solutions”.

In short: Disciplined “solves”. Flexible “provides solutions”.

You will have to read the book to understand the larger context of this. With essays about theory versus practice, industry versus academe, etc. But for me one of the more important fundamental concepts is captured in the “solves” versus “provides solutions” thought.

Let me continue with some quotes from the book (which are mostly quotes in the book, too). They are not directly related with the introductory thought above. But that does not really matter.. :)

On congruence – in the context of matching the right technique with the problems/complexity you’re trying to solve:

Plauger writes: “The name of the game is congruence.” The techniques you employ had better be consistent with the intrinsic complexity of the problem you’re trying to solve.
(from Software Creativity 2.0 by Robert L. Glass)

A simple but powerful and important statement. Instead of simply saying that you should “not use a hammer for every task at hand” the (for me) most important aspect in this quote is the “intrinsic complexity”. When I look at my software projects, this is the thing that limits me. The intrinsic complexity. For me it is not only about the right technique. I also learned that my brain has its limits when trying to conquer (software) complexity. (You can call me stupid if you want. I am probably quite OK with that.. :) I can try different approaches and techniques. And some problems are solvable by me this way. For some I have to try harder. For some I have to try new techniques. But for some I simply have to back down and say: “Sorry. I cannot solve this.”

For me this was an insight that resulted in quite some relief.

On management – a trivial but very important and much to my surprise often not understood or not accepted thought:

Plauger again: A large enough project is primarily an exercise in management. The programming technology has only a minor effect on the outcome.
(from Software Creativity 2.0 by Robert L. Glass)

I can – to this day – not believe how (plain and simple) stupid many software “professionals” are. Management is key to project success. Of course the skill level of the developers is important. But management is key. Accept it. Live (work) by it.

On mathematics – one of my problem areas, sadly:

“I am simply saying that the help it [mathematics] provides, for the vast majority of software people, is marginal at best. Perhaps, in fact, Latin would be at least as useful in terms of the logic and rigor it offers.”
(Robert L. Glass in Software Creativity 2.0 about his “Latin Syndrome”.

Mathematics nearly killed me back in university. I failed “Analysis” twice and only made it through the verbal examination (the last chance), because the professor was kind enough to acknowledge the fact that I am a really a programmer (by heart) and not a mathematician and the mathematics are probably a bit too advanced for someone that tends to lean more towards the practical side of computing. Back than I realized there is some wisdom in this man that I appreciated on many levels. To this day I am thankful to this man.

On software specification – the core topic of my diploma/thesis:

Frosch 1969: “the idea of a complete specification is an absurdity”
(from Software Creativity 2.0 by Robert L. Glass)

I remember during the time I was writing my thesis how I argued with my boss about the benefits of software processes and having the requirements specified as complete as possible. The goal for my thesis was to evaluate the benefit of doing upfront requirements specification in context of the then available software processes. Mainly limited to the what then became Unified Process I specified a medium sized software project, designed it with Rational Rose, used the Rose code generator to create a nearly executable prototype and then captured this experience and tried to put it into the various contexts of software process, requirements, design, implementation, maintenance.

It was a rather enlightening experience. Not a very “good” or “nice” experience in it self. But enlightening it was.

Reading now what I have just written, I realize this is quite strongly connected to the “congruence” thing mentioned aboce. Yes, sure this approach was “interesting” to follow. But no, it is not very practical. Unfortunately it is rather complicated to formulate all of the draw backs here. For this, read the book. Glass does this much better than I could ever do. Fact is: I experienced exactly what Glass is talking about.

Enough for now. I’ll write a second post with some more quotes later. I did not realize how much has accumulated while reading this book.


Books section updated

Instead of adding posts about each book, I have update the book review section of my old website.

Included books:
* Clean Code by Uncle Bob
* The Passionate Programmer by Chad Fowler
* Pragmatic Thinking and Learning by Andy Hunt
* Behind Closed Doors: Secrets of Great Management
* Software Conflict 2.0 and Software Creativity 2.0 by Robert L. Glass

Clean Code by Robert C. Martin

I have read Clean Code by Robert C. Martin recently. Definitively a recommended read. Many little and a few big insights.

I had the chance to apply some of the new (for me) ideas from the books on a few of my projects and I was stunned by the immediate improvement of my code.

At first I struggled a little bit with recommendations like using object variables instead of parameters for example. But after using this technique a few times the benefits became apparent to me in a very “personalized context”. I still tend to use method parameters to guide the use of methods. My idea was: A method returns a value that is required by another method. This way it is clear in what order to call the methods. But I understand that this is really not a good argument. Why in the first place should/would it be unclear in what order to use the methods? Exactly.. this is the real problem you should tackle. After that it doesn’t really matter anymore whether you use parameters or object variables/fields. And then in fact it is better to use fields because the reduce the noisiness of the code.

Anyway. This book has a lot of useful information and tips. If you consider yourself a genius programmer you probably don’t need this book. For everyone else there is probably some interesting stuff to be found.