Modular development with Lego!

I have a real liking for explaining complicated virtual concepts in an easy to understand way, and Lego always springs to mind when I think of software. I have my son to thank for this.

Lego is modular, it’s simple to use and its fun to build! Why should software development be any different?

So here it is, software architecture explained with Lego, complete with cheesy elevator music!

[Official disclaimer: this is only one (my) idea about software development in an Oracle environment and it ain't Gospel]

enjoy…

Modular software development with Lego!

Modular architecture, Lego and my Son’s bedroom…

This, I’m ashamed to say, is my son’s bedroom.

As you can see, he loves Lego.

Don’t get me wrong, I like Lego too, I like the modular nature of it, I like the way you can take small units and combine them together to make bigger, more complex things. I like the way the blocks snap easily together and I like the distinct colours each block has.

The problem is this. When I look at my son’s bedroom it reminds me of some of the software I’ve seen in previous job’s. No structure, no organisation, things in places where they shouldn’t be, basically a mess.

When software is designed like this it becomes unmaintainable and un-scalable.

I prefer to design my software so that everything is in it’s proper place. Tables, Packages, Sequences, Objects, Javascript, Style Sheets, HTML all have separate and distinct functions. Don’t mix them!

It makes my toes curl when I see HTML/CSS code embedded in a PL/SQL package or Javascript code in an APEX page region.

So I said to my son that I would get him a little unit of drawers so he can keep the Lego in that and he can organise it by colour and type. This seemed to make some sense to him since he could then easily find pieces and build bigger and better Lego creations in a short time.

So far he hasn’t tidied his Lego into the drawers, but one day I believe he will. One day the light bulb will appear above his head and when it does I’ll take a photograph of his room and post back here.

The Bus Factor

The Bus Factor

Years ago a boss of mine once commented on what would happen to the project if I was run over by a bus.

Thinking about it I then decided to take it as a compliment. Apparently he was suggesting that I had sufficient importance on the project that if I was to “kick the bucket” in a horrible public transport accident, the project would be in trouble.

Apparently there is even a wiki on this kind of thing, http://en.wikipedia.org/wiki/Bus_factor.

Of course other situations could occur which would have similar consequences for example, having a baby, getting a new job, winning the lottery.

Well one of those could happen, the other two are as likely as a Michael Jackson comeback Tour.

To be honest I feel that there is nothing a developer can write that cant be debugged by a similarly qualified developer and the concept of the Bus Factor is a little over exaggerated.

But of course, we all document our code anyway!

Pair Programming

One of the great things about Agile development is the concept of pair programming.

Every so often this is made glaringly apparent to me when I sit looking at some code with a blank expression on my face and time slips away.

Sometimes you can be hypnotised by code and your brain goes round and round in circles.

So, thinking like an Agile developer, I call over a friend to look over the code with me. As I sit and explain the problem, as if by magic, the answer begins to crystalise before me. And my friend has done almost nothing!

The simple process of explaining and discussing a problem with someone often brings about the solution.

Within 10 minutes, my code problem of two days was solved with a couple of lines of code and an exception handler!

I just wish I could have those two days of my life back!!!

Table Script added to Unit Testing example

Thanks to Narisu for pointing out that the create table script was missing from the Unit Testing sample download file.

You should be able to install the complete working sample now on your Oracle database.

So why the Lego man?

Ok, so some people have been asking, Why the Lego on a site about Oracle Unit Testing!

Well, the analogy I’m trying to express with lego is that software development is a bit like building a lego house.

Software is built in Units, Blocks, Packages, Classes, whatever you want to call them, they’re basically some form of encapsulation of code.

Gone are the days of endless scripts of code all in one file.

We now develop software in Units and test the Units with other Units. Then once that Unit is stable we build another Unit on top of that.

So what we end up with is a solid Lego house that isn’t going to fall down.

Oracle Unit Testing – New Website

Welcome to the redesigned Oracle unit Testing website!

I hope you find it useful, so please contact me[/szb] if you have any ideas or suggestions for the site.