Category Archives: Software Development

This mess started long, long time ago

Posted on by

My son borrowed Asterix and Cleopatra from Claremont Library last week.  It’s been ages since I read anything from that series.  But page 2 really had me chuckling.  There is an image of the page online, but it’s bit hard to read.  So, here’s the dialog.

The scene: Cleopatra has been challenged by Julius Caesar to build a grand palace that will prove that the Egyptians are an advanced nation.  She summons Edifis, her architect.

Cleopatra: Edifis, I have summoned you because you are the best architect in Alexandria – which is isn’t saying much.

Edifis: Oh!

Cleopatra: Don’t answer back! Your buildings are flimsy.  You can hear every word the neighbours say.  The ceilings fall in!

Edifis:  It’s these modern materials… Actually, what I really want to do is build pyramids and …

Cleopatra: Silence!  You have just three months to make good.  You are to build Julius Caesar a magnificent palace here in Alexandria.

Edifis: Did you say THREE MONTHS?

Cleopatra: If you succeed, you will be covered in gold!  If not, you will be thrown to the crocodiles!  You may go.

(Edifis walks out)

Edifis: (thinking) Three months!  I’d need supernatural powers to do that!  I’d need someone who can work magic.

Edifis: (shouting) Got it!  I know the very man!  He can work magic!

Now, where have we seen that before?

(And just get the original book and read on about mule-driving the slaves to haul huge blocks of stone … classic!)

What freedom?

Posted on by

At the Scrum gathering I had a tiny little conversation with Lorraine Steyn of Khanyisa Real Systems and Henrik Kniberg of Crisp about some of the values in our organisations.  At the top of Henrik’s value list was Freedom.  It seemed straight forward enough, until I started thinking about what freedom means to me.

My early perspective and experience on (the lack of) freedom is based purely on oppression of apartheid.  Ok, that’s over, so I am now free. Right?

Then John Lennon’s Imagine lyrics sang through my head.  If we’ve nothing to kill or die for, will we have universal freedom?

Hold on, what about when Janis Joplin sang Me and Bobby McGee – “Freedom’s just another word for nothing left to lose”?  That sounds too dreary for a concept that should make me happy.

Tonight I saw a quote by Maria Montessori on the wall next to my wife’s desk at home.  It’s been there forever and it says:

“The  essence of independence  is to be  able to do something for one’s self.”

I like this the most.  Be able to something for yourself and you will gain independence which sets you free.  It also reminds me of the self-organising mantra in Scrum-land.  Self organising implies that the team wants to be able to manage themselves so that they achieve independence (freedom).  But, there is a little spark of conflict in here.  As individuals we also have priorities and values, which is not necessarily aligned with that of the team.  Is it acceptable to compromise just to subscribe to the homogeneity of the team?

I think it’s a long walk to freedom.

Advertising

Posted on by

Did you notice the advertising banners on my blog? I’m experimenting to see if it’s possible to earn any money from geek blogging on the narrow subject of software architecture, agility and all the other things I churn out. I’m going to let it run for a while and see what happens.
Oh, I guess I’ve got to do something about the site layout again.

Zero to CI in 6 hours

Posted on by

Marius de Beer is crazy for even trying to do this, but it is such a horribly misunderstood space that it deserves an outrageous attempt to nail it.  I’m talking about the really adventurous deep dive session that will be hosted by Marius at the Scrum Gathering in Cape Town.  If you currently think that continuous integration is a tool, then my advice is simple.  Pay the full fee for the event, sign-up for Marius’ deep dive and sacrifice the second day of the event by going back to your desk and just start doing what  you learnt.

Delusion: A firm belief despite contradiction in the face of reality

Posted on by
DevDays 2010 in Cape Town yesterday was slick.  Very slick.  It’s always slick.  Those guys really know how to put an a good show.
Most of the speakers are good.  Most demos were good.  Most jokes were funny.  The food was mostly good. The mood was mostly good too.   And the MS fan club was mostly impressed.  And most noobs were converted for ever.  And the improvements were mostly apologetic of the earlier short comings.  And code that you were promised you would write was mostly minimal.  And most absent was the word design.  Most ignored was TDD.  And most content presumed that we are dumb ass developers that don’t care about good code, good tools, good software.
If it was not for Bart de Smet’s two sessions on Core .NET 4.0 Enhancements and Language Enhancements in .NET 4.0, the day would have been mostly wasted.  Bart gave me a glimmer of hope, not for MS but for the manner in which he assumed we are not moron developers that can’t think.
The EF4 code first demo was explained completely as if the classes in the model are no different from entities in a table.  You may be have slides with the words “code first models”, but if you don’t actually do it for real, then you’re just leading dataset happy, marginally object oriented developers further away from the truth.
I understand that it’s a marketing game but, come on, MS South Africa, at least pretend that we are capable developers that care about being professional.  We care mostly about design. Mostly about clean code. Mostly about quality.  Mostly about getting projects done on time, within budget and mostly maintenance free.  We care mostly about being agile, being able to refactor code continuously, being able to test first, and not tossing code downstream.
Ahmed’s ping-pong of bugs is so irrelevant, when the developer is test-first infected and the tester is actually your continuous integration server.  Mostly we are developers that test our own code.
Glimmers of hope
– IE9 has developer support in mind
– EF4 has code first, but still so far from being a decent ORM
– DLR has a potential sweet spot

DevDays 2010 in Cape Town was slick.  Very slick.  You guys really know how to put an a good show.

Most of the speakers were good.  Most demos were good.  Most jokes were funny.  The food was mostly good. The mood was mostly good too.   And the fan club was mostly impressed.  And most noobs were converted forever.  And the new features were mostly so good, apparently, you won’t have to write so much code anymore.  And the most underused word was design.  Most absent words were TDD, refactoring, quality, and clean!!

I understand that DevDays is a product showcase but, come on, MS South Africa, at least cater for the entire spectrum of developers, just a little bit, and in a responsible manner.  How about pitching content that shows that you do care about design, about clean code and quality.  How pitching the new features in a way that shows a trend towards agility, to being able to refactor code continuously,  to test first and other vital aspects of professional software development.

Let me give you just an example to illustrate what I mean.  The EF4 code first demo was explained completely as if the classes in the model are no different from entities in a table.  Even the language used was “entities” and “keys”.  I don’t think I heard the word “class” or “object” once!  You may have slides with the words “Code First Model”, but if you don’t actually do it for real, then you’re just leading dataset-happy developers that are marginally object-oriented further away from good code and good architecture.  You need to explain why it’s better:  that it promotes better object orientation, that POCO models disconnected from an ORM can be done test-first, and you can evolve your model, instead of designing up-front, blah, blah, blah.

Another time there was a ping-pong table with a developer at one end and tester at another with a bug being batted between them.  That pulled quite a laugh from just about everyone.  While that is reality in many organisations, there are many of us that test our own code and deal with our own bugs.  The tester that we toss our code to is our automated continuous integration server.  Tossing code downstream when it’s too late for reprise is not very professional.  How about focusing on the testing tool, as opposed to pitching it in a manner that makes everyone believe that dealing with the bug downstream is just the way its meant to be.

Sure, I know that you need to show off the latest cool things and evangelise your products, but there is a sector of developers that you are blatantly ignoring.  It is the sector that is, perhaps, the most influential amongst other developers. We are those developers that value our craft of software development.  We evangelise the craft and the value that it brings to our lives, our teams, our projects, our clients and our organisations.

Perhaps I am just delusional.

Oh well, so long and thanks for the fish.

Beware the Big Industry Specification Up Front

Posted on by

If you have done any development in Java-land, then surely you came across the dreaded three letter word EJB.  And you were most likely duped into thinking it was great.  I did!  Then I realised it was just a specification.  It was a great big, furry, non-executable PDF.  A specification for managing objects but the creating of these objects were just horrid.  EJB3 was a clean-up exercise, but still far from nice.
A couple of months ago I ran into OSGi again, but with SCA on top of it.  Horrid!  SCA is yet another warm and huggable specification.  But it’s so ugly to work with.  Everything feels so over the top complicated and restrictive in expression.  And the tools that I saw built on this SCA implementation were just awful.  Beyond being buggy, the enforced paradigm was just counter-productive.  When will tool vendors realise that talented developers do not want a diagramming interface to write code?  But the root cause is that the SCA specification describes the diagramming notation. Yuck!  Same reason that I do UML sketches with a lot of bastardisations with no tie-in with my code.

And let me not go into domain specific big vendor specs, designs, blue prints, etc. like IBM’s Insurance Application Architecture (IAA). Nasty stuff.

More commonly, I see so many self-confessed agile teams fearing the dreaded big design up front, and the big requirements up front document thrown over the wall.  If there is such a fear for big-x-up-front, why is there no fear for big-industry-and-vendor-specs-up-front like EJB, SCA, IAA, etc?

Why?

There are deep lessons and principles lurking beneath this surface.  Agile demands you to be a lot more aware of actions, decisions and consequences.

So why do you choose not to be agile when you are trying so hard to be agile?

The Last Sprint Challenge

Posted on by

In agile economics we often talk about stopping the project before it 100% complete; when you reach a point of diminishing returns; i.e. that agile fail-safe point when the cost of producing software is greater than the value of the software itself.  Kind of.
So let’s try a weird-ish thought experiment.  You’re in such a project and you’ve reached this point.  You are about to start the dead last sprint and then it’s over.  The team will be disbanded, but the software will live on.

You have just one more opportunity to work on this product, with this code base, with the people on this team.  Your legacy is in this software.  Every decision you made is sitting in a vast time line of deltas in your version control repository, all the way back to day 0.

What do you choose to do in this last sprint?

I wanna hold your ha-a-a-a-a-a-and

Posted on by

Do you remember that catchy Beatles song? 

Oh yeah, I´ll tell you something
I think you'll understand
When I say that something
I wanna hold your hand
I wanna hold your hand
I wanna hold your hand

So what made me think about this?  That frustrating construction of the new M5/N1 interchange in Cape Town!!  When you’re sitting in traffic, you can’t do anything but look and think.  And I’ve seen this scaffolding get taller and taller and wider and wider and longer and longer and more and more people appear on it each day.

I know that one day, they will remove the scaffolding and the concrete will just hang there in mid air on those massive pillars and walls that they’re busy building, and I won’t be sitting in traffic any longer, and it will all just work.

What a shame that software is not like that !!  So many people get turned on by scaffolding.  And The Beatles sang on …

And when I touch you i feel happy, inside
It's such a feeling
That my love
I can't hide
I can't hide
I can't hide

And just like the M5 construction, so much scaffolding gets built, and so many people climb on.  But then, they don’t climb down.  And they don’t tear down the scaffolding.  And it just stays there mashed in with the concrete bits.  And then they ask people to use it.  And it takes strain and then it’s a performance problem, or a load problem, or it just crashes down.

I do use scaffolding, but most of the time it’s in a spike and more often it’s in a test, just to get me over my point of fear.  Deploying software with scaffolding is just dangerous and negligent.  I really don’t want to drive my car over the M5 interchange while those thin steel pipes are holding up the concrete slabs.

But above all of that, the most important scaffolding is social scaffolding.  It’s better to provide human scaffolding to support each other on a team that is focused on delivering quality software.  It’s worse to plug in weak struts in the code base that will just collapse when the next developer builds on top of it.  Very un-ubuntu!

So, the Beatles song still holds true, but only for social scaffolding.

Yeah you, got that something
I think you'll understand
When I say that something
I wanna hold your hand
I wanna hold your hand
I wanna hold your hand
I wanna hold your ha-a-a-a-a-a-and

What’s worse than BIG DUF? A BIG DIC!

Posted on by

Most agile people say big designs up front rarely pay off.  You spend so much time doing design that you delay the opportunity of feedback from real, working software.  But I sometimes do BIG DUF.  It’s not that the design is big, it’s the problem that is big.  So I need an up front big picture with just a few big parts.
It helps me conquer and divide.

That’s not a bad thing.  What I find really painful is casting the design in concrete.  When your design is cast, then your mental state is already cast in concrete too.  And that means that it is a lot harder to do the right things.  So, more gets added to the concrete slab and it’s real hard work to break anything off.  When I have a BIG DUF, I often look at how to reduce it, rather than increase it.

I don’t think it’s wrong to have a  BIGDUF, it’s worse if you have a BIGDIC (BIG Design in Concrete).  That concrete block will hurt you later … a lot.

In other words, the size of a BIGDIC does not matter, it’s the rigidity that’s the problem (— That’s so lame, I could not resist!)

ESCOT 2010

Posted on by

I have no idea what I’ve gotten myself into now, but I’ve agreed to help out the Empirical Evaluation of Software Composition Techniques workshop will be held as part of the next Aspect Oriented Software Development conference.  I doubt I will attend ESCOT or AOSD but it will be good to collaborate once more with some very enlightening people that I met at OOPSLA last year.
I guess I’ve got quite a lot of reading coming up and it will be fun to read what is coming out of the research channels and cast my own weird industrial perspective on things 🙂