Brian On Software

At the end of the interview with Dick Gabriel (Episode #84 of the Software Engineering Radio), the host surprises us with the funniest song in software development to date IMHO…’God Wrote In LISP‘. Software development with se-radio.net…I’m loving it!

Here are the lyrics to the song (from the Laugh along with GNU page of the GNU website)

I was taught assembler
in my second year of school.
It’s kinda like construction work —
with a toothpick for a tool.
So when I made my senior year,
I threw my code away,
And learned the way to program
that I still prefer today.

Now, some folks on the Internet
put their faith in C++.
They swear that it’s so powerful,
it’s what God used for us.
And maybe it lets mortals dredge
their objects from the C.
But I think that explains
why only God can make a tree.

For God wrote in Lisp code
When he filled the leaves with green.
The fractal flowers and recursive roots:
The most lovely hack I’ve seen.
And when I ponder snowflakes,
never finding two the same,
I know God likes a language
with its own four-letter name.

Now, I’ve used a SUN under Unix,
so I’ve seen what C can hold.
I’ve surfed for Perls, found what Fortran’s for,
Got that Java stuff down cold.
Though the chance that I’d write COBOL code
is a SNOBOL’s chance in Hell.
And I basically hate hieroglyphs,
so I won’t use APL.

Now, God must know all these languages,
and a few I haven’t named.
But the Lord made sure, when each sparrow falls,
that its flesh will be reclaimed.
And the Lord could not count grains of sand
with a 32-bit word.
Who knows where we would go to
if Lisp weren’t what he preferred?

And God wrote in Lisp code
Every creature great and small.
Don’t search the disk drive for man.c,
When the listing’s on the wall.
And when I watch the lightning burn
Unbelievers to a crisp,
I know God had six days to work,
So he wrote it all in Lisp.

Yes, God had a deadline.
So he wrote it all in Lisp.

Amen.

Starting this week, I’ll post a weekly post on recommended links to interesting, educating, and entertaining stuff concerning the world of software development and related technologies. Most of these links point to blog posts, published articles, podcasts, screencasts, news, etc., that I feel like sharing with my fellow developers at work and on this site. Without further ado, here are the week’s geek links for January 25th, 2008.

Blog Posts

• “TDD Anti-Patterns”
  Software developer James Carr shares his own catalogue of TDD Anti-Pattern. It’s a good complement to Gerard Meszaros’ “xUnit Test Patterns: Refactoring Test Code” and pretty helpful in case you’re wondering whether or not your test harness is well written.
• “It’s fundamental: You are a programmer if you…“
  A lot of people are writing posts about the ‘conditions’ that must be met for being considered a ‘programmer’. In his post, Reg Braithwaite counters this by providing his own thoughts on what it really takes to be a real programmer…writing programs! Of course the spectrum between being a good programmer and a professional programmer is quite large, but as long as you know how to work with the ‘fundamentals’ associated to programming, I believe you’re on the right track. I strongly suggest you to read the comments linked to that post…it gets pretty interesting!

Articles

• “VS 2008: The Road Ahead”
  Roger Jennings writes about what .NET developers should watch for the next release of Visual Studio, code-named “Hawaii”. I was blown away with the quantity of new tools and technologies that are going to be delivered by Microsoft (mostly by Microsoft Research) in the next release of their premier .NET development toolset. Amongst these set of technologies related to the .NET platform, brace yourself for the Dynamic Language Runtime (DLR) with support for IronPython and IronRuby, Silverlight 2.0, ASP.NET’s Extensions, the F# programming language, PLINQ and Parallel FX, ADO.NET Data Services (formerly known as ‘Astoria’), Eric Meijer’s Volta project (IMHO by far the most interesting project in the list), and more! Gee, I still haven’t jumped on the ASP.NET MVC, Enterprise Library, C# 3.5, WPF, XAML, WCF, WF, CardSpace wagon!
• “Designing an Entity Data Model”
  John Papa wrote an article covering the basics behind the Entity Framework and provides a good overview of the Entity Data Model in the next MSDN Magazine. I’m not a fan of using wizards to implement code, because I like to have control of my code and to know the mechanics behind the engine, but sometimes it does help to use them. In his article, John uses the Entity Data Model Wizard to generate a model from an existing database. So what? It’s still a good introduction to this new promising technology!
• “Introduction to Object Oriented Programming Concepts (OOP) and More”
  This is an article that was published in The Code Project on Jan.7th, 2008. Even though a huge number of articles, books and classes have been wrote and taught on this subject for the last 20 years, there are still some programmers who can benefit for more simple explanations on some concepts and principles related to OOP. I’m actually going to be teaching an introductory OOP class with C# and VB.NET in a couple of weeks, and this is one link that I’ll share with my students. The programming language used in this article is C#, but the concepts can easily be applied to Java, VB.NET, and other OO languages.

Podcasts

• “Develop with Passion like Jean-Paul Boodhoo“
  Craig Shoemaker, host of the Polymorphic Podcast, interviews Jean-Paul Boodhoo, a MVP and .NET developer from Calgary, Alberta, Canada. JP is one of my favourite blogger because he has this tendency to inject passion behind someone’s desire to become better as software craftsman. In this interview, JP explains in simple and humble words his experience as a software professional, how and why he changes the way he designs software instead of always applying the same pattern or principle without further investigation as to know if there’s a better way to design a software.
• “Dick Gabriel on Lisp”
  Dick Grabriel, a software scientist, poet and ‘code artist’ is being interviewed by my favourite software development podcast, Software Engineering Radio. As stated in the site, “In this episode, we’re talking with Dick Gabriel on Lisp. We started by looking at artificial intelligence as the historic context of Lisp, the goals AI tried to reach, and how Lisp was supposed to help reach those“.

Screencasts

For the C# and VB.NET language aficionados, there are two good screencasts about both of these languages:

• “Bill Wagner on Learning C#.NET From VB.NET”
  In this DNR TV episode, Carl Franklin does a one-on-one presentation with Bill Wagner, author of the excellent and highly recommended Effective C# book, about learning C#.NET from a VB.NET perspective.
• “Kathleen Dollard on Comparing C# and VB in .NET 3.5”
  And if it wasn’t enough, you can also watch Kathleen Dollard on dealing with the subject of comparing C# and VB.NET in the latest version of the .NET platform. This is the first of a two part series.

News

• The .NET Framework library source code is released!
  Yep, it’s finally here. You can now debug some parts of your application that directly uses the .NET Framework libraries within Visual Studio 2008. You can read more about this here, here, here, and here.

Posted under Geek Links. RSS 2.0 feed Leave a response, or trackback.

In my last semester at university, I had the opportunity to attend a graduate class dealing with software maintenance, taught by Professor Alain April. In case you don’t know who he is, Dr. April is responsible for creating the Software Maintenance Maturity Model (S3M). Here’s an overview of that model :

We address the assessment and improvement of the software maintenance function by proposing a maturity model for daily software maintenance activities: the Software Maintenance Maturity Model (SMmm). The software maintenance function suffers from a scarcity of management models to facilitate its evaluation, management, and continuous improvement. The SMmm addresses the unique activities of software maintenance while preserving a structure similar to that of the Capability Maturity Model integration (CMMi). It is designed to be used as a complement to that model. The SMmm is based on practitioners’ experience, international standards, and the seminal literature on software maintenance.

Coming back to the subject of this post, we had to choose a subject amongst a list of proposed subjects which would be our project for the whole semester. I decided to write a paper on my personal recommendations for improving the ISO 14764, a software engineering standard which deals with the area of software maintenance.

The objectives of this paper are twofold :

1. Identify books and articles that discuss software maintenance and have been published since 2005;
2. Provide insights or areas for improvement that could contribute to update the upcoming version of the maintenance chapter of the Guide to the SWEBOK (ISO 19760) and to the ISO 14764 standard.

My recommendations were constituted of four different ideas which could improve the area of software maintenance within an organization which deals with software maintenance (and development). Here’s an overview of the ideas I present in this paper :

1. Instilling a quality mindset to top-level management
2. Introducing agile practices in software maintenance
3. Applying key domain-driven design concepts
4. Adopting a universal coding convention throughout the organization

I have archived both the report (PDF) and the PowerPoint slide that I showed during my presentation in class (some slides have notes associated to them for more understanding, in case you don’t want to read the whole report).

Click here to download the paper and the PowerPoint slides (zip file).

I hope this kind of information will help your organization to improve its software maintenance phase. Keep in mind, that these ideas can also be applied for software development activities, not just maintenance.

Written by Marc Benioff, chairman and CEO of SalesForce.com, “The Business of Changing the World” is a wonderful and inspiring collection of twenty essays written by great leaders on strategic corporate philanthropy. Amongst these leaders who each wrote their essays, we find Michael Dell and Kevin Rollins of Dell Craig Barrett of Intel Marc Benioff of SalesForce.com Steve Burd of Safeway Steve Case of Revolution Jim Donald of Starbucks Mike Eskew of UPS Larry Fish of Citizen Bank Peter Gabriel of WITNESS Jean-Pierre Garnier of GlaxoSmithKline Alan Hassenfeld of Hasbro Akinobu Kanasugi of NEC Phil Marineau of Levi Strauss & Co. Micheal Milken of The Milken Institute John Morgridge of Cisco Systems Marilyn Carlson Nelson of Carlson Companies Laura Scher of Working Assets Klaus Schwab of The World Economic Forum Jeffrey Swartz of Timberland

The main idea behind the novel is that major corporations are doing well because they’re doing good. Even though I only knew maybe half of these organizations (remember that I live in Canada and most of these companies are from the U.S.), it was nevertheless challenging to read how each of these leaders once asked themselves if there was something they could do to give back to society, because society once helped them at some point in their lives. Of course not all major organizations, such as Google and Microsoft, are included in the book. That’s fine because it’s not hard to learn about their philanthropic whereabouts and activities, given that they’re so big and popular. Therefore, the book actually presents what other small, medium, and large companies are doing to help back those who’ve helped them at some point in time.

It wasn’t easy to let the book down once I finished reading an essay, because I felt like reading what the next organization had to say about its own vision and plan towards philanthropy. Another neat thing about the book is that each essay is divided in two parts. The first part discusses about the founder or the CEO of a given company, and how that company came to be. Therefore you get a little history lesson behind some of these big names that are so well known nowadays. The second part deals with the different approaches and activities adopted and supported by the companies and their employees towards philanthropy. It’s brilliant because you also get to know some possible (and very realistic) ways that you can adopt within your own organization in order to give back to society, whether it’s time, money, education, etc. Every essay also presents statistics and facts that compare a company’s overall performance before and after adopting a mindset of doing well by doing good. Therefore you can compare yourself with those organizations if you want, but more importantly it gives you a concrete sense of the real power behind these acts. This is a book that I will read over and over again, and share with my friends and people who want to make a positive difference in their own society and hopefully on a worldwide scale. Living in North America, it’s sometimes easy to forget how blessed we are (financially, materialistically, academically, etc.), and be blind to other communities and nations who are more in need than the rest of us. I believe we have more than the necessary to help each other within our local communities, as well at the international level. I’m glad this book is out because I also believe that we’re going to see more corporate philanthropists in action in the near future, and this time their business will be to change the world.

I took some time this morning to read two simple, funny and excellent articles, which I’d highly recommend if you have a couple of minutes to spear. Both articles are written by different authors, but they both converge to the same principles and ideas which I believe in my heart should never be forgotten: “By all means, if possible, keep it simple please!”.

The first article I’m writing about is “The Master, The Expert, The Programmer”, an essay written by Zed Shaw. I can easily relate with his article and ideas, because it deals with martial arts, coding techniques and simplicity. The idea behind martial arts (or any kind of art, such as painting, ballet or preaching) is that practitioner can normally fall in one of these three levels of expertise: novice, expert or master. Everybody starts out as a novice in everything in life (I’ve yet to meet a human being quoting the Declaration of Independence, just five minutes after leaving his mother’s womb). As you gain experience, wisdom and self-realization, your art begins to be a basic part in your life, such as blinking or breathing. You are now an expert on that field…or so you would think. I say “…or so you would think”, because just analyzing your own merits doesn’t specifically set you apart from one level of expertise to another. I think you become an expert in an area when you can actually speak, teach or share your knowledge with someone in a very simplistic way. If your message isn’t understood in, let’s say, ten minutes (I’m being generous here…), then probably yourself don’t understand your own message.

Getting back to the first article, Zed’s message in regards to code is simple: “Keep it simple!”. I have nothing wrong against XML, SOAP, UML, SOA and other buzzword-driven technologies (even driven is a buzzword now!). I know they’re not perfect tools or technologies, and I sometimes regard them as “functional patches”, but I think they’re a great foundation for future improvements, practices and tools. What I do have a beef with is when they are used in a way that, sadly, adds more complexity than necessary to solve a problem. Take for example this basic math problem. Suppose, I want an equation (a software would represent the equation in this example) that gives me a result of 4 (here the result is the problem I’m trying to solve). You can say that 2 + 2 = 4 and get your paycheck for it. You can also say 4 + 0 = 4, but sometimes people don’t like zeros. “It’s not sexy!” they would say. “Might as well use something better, something sexier”. So we go for an extreme solution that is soooo complex that we actually think it’s bulletproof! Cool…let’s go for log(85)*100-(50*3)-38.94189 = 4. This time you get a paycheck from the customer, and the guy in charge in maintaining your solution gets a headache. I don’t want to be that guy.

Sometimes I wonder why humans like to complexify things. Is it to represent someone’s signature, like graffiti on a wall? Our planet is simple (since it’s my blog, I’ll just say because I believe that God is simple). Nature is simple. For example, cats can’t swim; therefore you hardly ever see a cat near a beach. Programming and software development is already complex, since you’re dealing with two very difficult things: 1) Mathematical abstractions and 2) Humans. I’ll save my ideas on these thoughts for another post, but I just want to say this: Why add a third, or a fourth, or a fifth degree of complexity in our solution? God bless the Three Amigos and the Gang of Four, but do you really need to add graffiti in your solution? Don’t get me wrong though. There are some situations that are perfect for a pattern implementation or an UML diagram. But if you don’t need them in your problem domain, why use them? Keep it simple so that in the future, not only will you be able to tackle its maintainability, but there might actually be a tool or technology to ease your solution in such a way that all you’ll have to do is swap in and out your old solution for a new and better one.

The second article I read is “The S stands for Simple” by Pete Lacey. I almost fell off my chair laughing while reading his article. It’s short, hilarious, yet very realistic. He basically writes a dialog between a developer and a SOAP Guy. The SOAP guy can actually be anyone who swears by all these new technologies that are appearing on the Web. Like I said, I like to call them “Functional Patches”. It’s like in America, they say “Guilty until proven innocent”. I say the same thing in Canada regarding software development “Useless, until proven useful”. Check out this dialog….

Dev: Let me sum up. The definition of SOAP is in constant flux, SOAP is anything but simple, and it is no longer meant for accessing objects-even though that’s what all the tools still do.

SG: That’s about right, but we’re way ahead of you on this. We’ve deprecated the meaning of the SOAP acronym.

Dev: Really! What does it stand for now?

SG: Nothing.

Dev: (blink)

SG: Let me tell you about UDDI.

“Let me tell you about UDDI” This is the part where I almost fell down my chair.

For this review, I decided to target a technical book which I think should be on every software enthusiast bookshelf. Whether you’re a computer science or software engineering student, a software professional, manager, consultant or trainer, you will NOT regret reading Head First Design Patterns by Eric and Elisabeth Freeman, from O’Reilly. I think you can guess what this book is about (I admit it wasn’t a hard guess…), but you’re right! It’s a book about software patterns, and by far the book I mostly recommended on the subject. Using the Java programming language and UML diagrams, this book deals with all the original patterns from GoF and presents them with a unique sense of humour, simplicity and fun! It doesn’t matter if you’re a first time learner on the subject or if you’re an expert. Head First Design Patterns will surely teach you more than one thing about software patterns for sure.

What fascinates me the most about Head First Design Patterns is its style of writing, because the approach taken by the authors to present each patterns is simple and easy to grasp. For instance, each pattern is presented in an intelligent and smooth context via a little story. The story starts with a problem between some characters or a witty situation, such as a one-on-one interview with a pattern (seriously, have you ever heard a Singleton being interviewed? It’s awesome!) It then continues by providing different solutions (I do mean solutions in plural, as it tackles the problem domain using different solutions via the same pattern) and testing your knowledge on the pattern via questions and answers, crosswords related to the particular pattern, how the pattern relates to other patterns, tips and tricks, etc.

The picture on the right side shows a sample of the unique style of the Head First series.  In this page, the authors are writing about a key object-oriented programming principle: Single Responsibility.  You can also read a limited preview version of this book on Google Book Search.

As written on the back cover, Head First Design Patterns will show you

• The patterns that matter
• When to use them, and why
• How to apply them to your own designs, right now
• When not to use them (how to avoid pattern fever)
• OO design principles on which patterns are based

Erich Gamma and Richard Helm, coauthors of the original Design Patterns book, as well as Ward Cunningham, wrote praises for this book. It is smartly written, fun to read, challenges you at regular intervals, and makes you appreciate the fundamentals behind software patterns. I wish more technical books were written in the same style as this one. I highly recommend it, especially if you’re teaching software patterns to individuals.

The following is the Table of Contents for this book:

1. Welcome to Design Patterns: an introduction
2. Keeping your Objects in the know: the Observer Pattern
3. Decorating Objects: the Decorator Pattern
4. Baking with OO goodness: the Factory Pattern
5. One of a Kind Objects: the Singleton Pattern
6. Encapsulating Invocation: the Command Pattern
7. Being Adaptive: the Adapter and Facade Patterns
8. Encapsulating Algorithm: the Template Method Pattern
9. Well-managed Collections: the Iterator and Composite Patterns
10. The State of Things: the State Pattern
11. Controlling Object Access: the Proxy Pattern
12. Patterns of Patterns: Compound Patterns
13. Patterns in the Real World: Better Living with Patterns
14. Appendix: Leftover Patterns

The Strategy pattern is described in chapter 1, whereas the Model-View-Controller pattern is described in chapter 12.

The Appendix covers the following patterns:

• Bridge
• Builder
• Chain of Responsibility
• Flyweight
• Interpreter
• Mediator
• Memento
• Prototype
• Visitor

If you have the original Design Patterns book by Erich Gamma et al., Head First Design Patterns will be a great complement to fill in the gaps you might have on some software patterns.