Author Archives: Aslam Khan

Geek Dinner Feedback

Posted on by

So I did go after all and it turned out to be a rather interesting event. There was a great turnout of about 60 or 70 people. The venue, The Wild Fig, was great, wine was sponsored by GETWINE (very generous of them), and WiFi hotspot by SkyRove. The talks were well timed, not too long or short, with a good mix of socio-political-technical chatter. The format was perfect: Quick intro to everyone, orders placed, 2 talks, starters, 2 talks, main course, 2 talks, desert, open mic. Just perfect!
Antoine van Gelder did a silent (self-inflicted-ducktape-on-mouth) talk on the One Laptop Per Child project. The point: children are taught to learn in silence, without expression. But expression online cannot be silenced. Very noble cause which I hope will get the time/publicity it deserves amongst the other fundamental challenges (hunger, health, etc) that children and families in Africa face daily. And he brought one of the laptops along for us to play with.

Bryn Divey did a well timed Python-bashes-PHP bit. If you ever liked PHP, you’d wish you didn’t. Very convincing argument against PHP, but I am still not convinced about Python. His delivery and style reminded me a lot of Dan North.

Tania Melnyczuk did one of the best project management flyovers I have seen. Nice to see that she touched on agile methodologies relevance in project management. At least I know one more project manager that I do not have to explain what a user story is and why I need to do a release planning session.

Nick Coyne did a really nice intro of Ruby on Rails and managed to evade the obvious Ruby-is-better-than-Python-is-better-than-Perl-we-all-hate-PHP dissidents. What was great to see was his pitch for having fun again and writing beautiful code. Something I relate to a lot.

Alan Levin spoke about the lack of socio-political endeavour attributed to lack of caring. In this instance, caring about bandwidth costs in South Africa … we all want more bandwidth cheaper but we really do not put our energy to make it happen. Very true. Are social and consumer causes dead in the post-apartheid South Africa? Or is it that only fundamental human rights violations warrant the mass protests of the 1980’s in which I grew up? Sri Sri Ravi Shankar will most likely pose the simple questions: What is your responsiblity and for what are you responsible?

Ian Gilfillan  did a bit on emerging mind games such as Go and Marabaraba (sp?).  He reckons that checkers, chess are dead ever since Deep Blue overpowered the great Gary Kasparov.  It was nice diversion.

The open mic spot was seized by Robin Ronne who chatted about the Ripple project.  I did not get the low down but it was something along the lines of a social network where the trust relationships have credits attached so that you can cut out the evil banks for all your money based transactions.

Neil Blakey-Milner mentioned that he will like to pull together an event in September over a couple of days.  Sounded like an Open Spaces style event even if he did not use those words.

Overall: Interesting event.  Was a bit disappointed initially with the lack of detailed technical content.  Upon reflection, I reckon that the content suited the format.  Highly recommended.

Flowing in the Waves

Posted on by

I just had a quick Google Wave experience with Willem Odendaal and the experience of seeing the other person type was a bit weird for both of us.
Lesson to both of us: Think before you wave!

Also, I have to remind myself to not think about waves as email, or tweets or instant messages. It’s just something else! And it has a different spin on the time dimension of communication.

I suspect that Google Wave will force us to be better at the way we communicate, how we express ourselves and the relevance of the content to the conversation.  I can imagine a wave growing over time that describes a story started by a domain expert with feedback from a developer and a nice cadence emerging between them.  It all is in one nice wave, with playback that tells you how you got there in the first place.  I wonder if this will have an influence on effectiveness of remote pairing?

I also have a feeling that if you’re a waterfall type of person, then waves will not have an impact on you.  It’s all about feedback and dealing with the changes, which is at the heart of agility.

Now I just need someone to wave with to try out a slightly modified development flow.

Technical Debt Does Not Exist

Posted on by

Metaphors may be a good way of getting to grips with a new domain.  It allows you to imagine the behavior of something that you don’t quite understand (yet) in terms of something with which you are quite familiar.  That’s were it should stop. I hate metaphors that extend beyond their purpose.  Once I have a good enough understanding, I drop the metaphor.  My reason is simple.  Metaphors force me to do a lot of energy sapping context switching.
Technical debt is one of those metaphors that have been extended so far, that it is believed by many to be something tangible.  Let’s get real here:  Technical debt does not exist.  It is just a metaphor for us to realise that our code base may cost us more money than it should, and that is a future view.  Sometimes our metaphors become euphemisms, and then it is dangerous.  When it comes to technical debt, the less I think of code problems as debt the more I am able to face the problems head on.

Ironically, I did a talk recently on dealing with technical debt.  My fundamental position is simple.  Either your code base has things that exist as a result of broken principles or it does not.  The more principles you break, the more potential problems you have in your code. It is not a problem right now, but it may be a problem in the future.  This future can be a minute away when I run my next test or a year away.  If the future is infinitely far away, then it is not a problem at all.

My first prize is to not break principles, so I don’t create potential problems.  My second prize is to deal with real problems and just leave the potential problems for the future.

(Warning: I’m drifting into my enlightenment self-reflection, so feel free to stop reading now.)

If I am part of the exploration that is looking for a solution (living in the moment and not outside it as an observer), then I should be aware of principles that I am breaking and I should change course immediately.  If I am part of the exploration that is dealing with the potential problem that is now a real problem, than I need to understand the principle that was broken and fix the problem by restoring the principle.  Restoring the principle could mean going on a search for the right solution to the original problem, not just trying to fix the problem that is a result of breaking a principle.  This problem that broke the principle may just be the wrong solution that we thought was the right solution because we ignored our principles in the first place.

Hmmm, that’s an interesting thought.  Karen Greaves asked me if a re-write can be justified and I mumbled something about technology, etc.  What tripe!  Now I think I’ve just reflected on when a rewrite is justified.  When refactoring will not fix the broken principle, then the right solution was never discovered in the first instance.  That is also what I mean when I say that clean code is necessary by not sufficient.  At factor10, we call this a radical makeover.  Radical makeovers are a viable way of getting rid of real problems, and restoring principles.

Heck!  This blog post is less about technical debt metaphors than I thought.  Oh well, the ride on this journey never stops.

By the way, a huge thank you to Steve for helping me realise that all problems come from breaking principles, in code and in life.

Testing is just a laborious pain in the rear

Posted on by

I thoroughly enjoyed Karen Greave’s talk on Agile Testing.  She had just about 100% coverage (pun intended, groan).  Yet, testing is really a pain in the rear.  Testing is execution, and Karen was dead-on right, that automation is the path to follow.  Computers are very good at testing.  A computer does what it is programmed to do, and it can test the way it was programmed to test.  It’s simple: if testing is your constraint, move that constraint away from testing by automating.

Now, you have to deal with the constraint that shifted to the next point: test authoring.  While testing (i.e. execution) is just a passive, laborious effort, test authoring is a very creative, active exercise.  It is actually an exercise in confirming a shared, common understanding.  Kristin Nygard said “To program is to understand” and test authoring is a programming exercise.  That’s why outside-in, behavior driven development style scenarios are actually tests, coded in a human language.  The act of authoring a scenario proves your understanding and the expected working of the software.

This is why I separate test execution (passive) from test authoring (active).  And Karen said that early feedback is good (right again), which is why I author my tests very early.  I’m extreme about this.  I test first.

Fat is the new Thin

Posted on by

During a factor10 virtual coffee break, Niclas Nilsson and I had a chat about what’s going on in web app land, on the browser end of the landscape. So this is inspired by his observations and him ‘pushing’ me to write this.
Recently, I’ve seen a few people searching for the holy grail of the ubiquitous browser UI.  The usual suspects appear: Silverlight, Flex, JavaFX.  Then I always suggest “What’s wrong with HTML, CSS and JavaScript.  You are writing a browser app, aren’t you?”.  And I get this weird, one raised eyebrow look.  So, in response to the one-raised-eyebrow look, here’s what I have observed. (I use the word model and fat below, maybe it’s the wrong usage, but I think you’ll get the gist.)

In the early days of browser apps, everyone was trying to write fat desktop apps in HTML.  And that went horribly wrong because the programming model was different.  We eventually figured out page based, disconnected apps in the browser, then someone did the AJAX thing and we had out-of-bound HTTP requests and in-place DOM updates.  Another small twist in the programming model.  But we had already made the transition to a new programming model and AJAX was not a radical change.

Now we have Silverlight, Flex/Air and others.  They happen to run in a browser, but there’s nothing browser based about them.  Yes, they all let you interact with the DOM and run some JavaScript too.  But these apps might as well not be in a browser.  In fact, that’s now pitched as a super great feature: your code can run inside and outside the browser.  The programming model is different.  No matter what the marketing folk say, I think the in-browser feature is a clever adoption scheme.

The truth is that this new thin is actually fat, FAT, FAT!  It’s just fat and disconnected.  That is all.  My advice for those that want to go this pseudo-thin route, is to just write your app to run outside the browser.  Just forget about the browser.  If you want to use the browser, then go back to HTML and JavaScript. The common counter statement is that these clients get rid of browser incompatibility issues.  If you really want to get rid of browser incompatibility issues, then don’t use a browser.  Simple.  And these confused thin clients will let you do that.

But the part that really scares me is that the fat code I have seen so far reminds me of unmaintainable VB, Delphi or PowerBuilder code.  And there are other scary things too.  For example, the Cairngorm framework for Flex is based on a singleton pattern, but the underlying language does not make it easy to create singletons.  Imagine all the code to create a singleton just to get the framework to work.  And these frameworks are not very DRY either.  Somehow, it seems like a new group of developers are writing these frameworks and they have not bothered to learn from 10+ years of web UI framework lessons.  The good news is that code maintenance and framework quality issues are solvable.

But the game itself has changed.  It’s not a case of new rules in an old game.  That’s what caused the mess in 1999 with HTML.

By this time, most people either close their eyes or raise the other eyebrow at me.

Coding for Enlightenment

Posted on by

Jimmy Nilsson asked me in an email a few days ago “How’s life?”.  I’m sure it was just a regular, friendly question, but I gave him a “life” answer.  It was not spontaneous but something that has been brooding in me for a while.   It is about things that I have been trying to do for a long time.
Here’s a few splintered thoughts from my email exchange.

  • Enlightened, for me, is about happiness that comes from being content; unenlightened is just trying to be happy.
  • There are many solutions for every problem, whether I am aware of them or not; and the problem has already chosen the best solution, but I have not found it yet.
  • Code from my heart because I should trust myself first.
  • Be part of the exploration, not just an observer.
  • This moment is more important than trying to figure out how it impacts the future, because I can deal with the future in that future moment.
  • Passion is constant whether I succeed or fail.
  • Let the project plan me, by bending to suit the situation not and not bending the situation to suit me.
  • The code I write knows everything, because every line of code has an impact on someone else or some other piece of code.

Now I’ve decided to actively explore why I write code, or why I wish to continue doing what I am doing.  I am not sure what I will uncover in this exploration, but I know that it will be very personal.  I don’t even know if it will be worth sharing, that’s why I am sharing so early.  It just felt right.

I think it will be really tough, but I take solace from my 9 year old son who told his 6 year old sister “Getting hurt is part of playing”.

PS: I don’t think Jimmy will ever ask me a “How’s life?” question again 🙂

Stranger Danger in the Cloud

Posted on by

There will always be someone who will scream that Cloud Computing is new.  And there’s someone else that will tell you it’s old-school-been-there-done-that.  And there will always be some vendor that will try to sell something too.
Since we shrink in body and mind to the state of children when thrown into a new context, beware of stranger danger.  It’s tempting to follow strangers for cheap candy in the cloud.

And yes, like SOA, we’ve seen and done this before.  But I think it is important that we let the passage of time to gel our experiences and ideas over and over again.  Why?  Because contexts change with time and we can use new contexts to innovate again and again and again.

You’re allowed to think … for yourself … and decide … for yourself.

Two Angles to Sustainable Pace

Posted on by

At the Scrum User Group South Africa meeting last night Marius de Beer did a really good talk about Software Development Practices.  It’s been a long while since I saw anyone attempt to draw so much from such widely spread corners of wisdom.  In one slide Marius mentioned the practice of Sustainable Pace.  Many take the view that this is about cutting back on working overtime and that it supports the principles of energised work, and work-life balance.  Marius did make the same point, and it is correct.
But there is another angle to Sustainable Pace.  As a developer, you need to build a rhythm, or flow.  It’s a cadence that you establish as you are writing code.  It’s a cadence that TDD helps you establish itself.  This cadence is also sustainable pace.  And one thing that kills this cadence and your pace in a flash is a mid-stream meeting.

In the panel discussion afterwards, there was a question at the end regarding ways to reduce the number of meetings which I just glossed over.  If you schedule meetings with developers for only the first hour in the morning, you not only reduce the number of meetings but, also, you don’t destroy the sustainable pace built up from the morning.

So, don’t think about pace as just working 7 hours a day, it’s about what you do in the 7 hours that matters.  Get the rhythm going and be anal about things that can kill your flow mid-stream; especially meetings.

Lean Software Development Webinar

Posted on by

I will be joining Kent Beck and Henrik Kniberg on July 20, 2011 for an SD Times webinar on Lean Software Development.  As usual, Kent has put up a great abstract for the event.  I’m absolutely certain that Kent will set the scene with his usual deep insights, and Henrik  has some amazing “from the trenches” experiential material to share.  Overall, we will explore this concept of waste vs value and how lean influences application development.
Personally, I want to cover what flow and waste mean to me, and examples of the huge piles of waste that I ended up manufacturing or walking into blindly and then struggling to dig myself out at great expense.  If the time allows, I want to weave in some models of flow that work for me and those that contributed to waste.  All of this fits into my rather weak thoughts on designing feedback loops.

 

Introducing the A-* Stack

Posted on by

Nowadays, software architecture and agile methodologies seem to be inextricably inter-twined. Everytime I have a chance for geek-talk with a bunch of software architects, there is always someone that will throw in some of the softer issues that deal with how we run our projects, how do we estimate, something about big design up front no-no’s, YAGNI, DRY and other buzzwords. Since architecture is full of metaphorical stacks of many kinds, I thought it might be useful to invent of an agile stack. Humor me, and let’s call it the A-* stack 🙂
I think there are several layers in A-*. I have no idea what is stacked on top of what, but Here is my A-* stack as I think of it right now, and we’ll try and refactor it later to gain deeper insight into the layers of responsibility and order that must evolve out of the chaos.

  • People Layer: This layer is responsible for establishing a team ethos. It is vital to creating a common work ethic in the team, shared values and principles. It is the lowest common denominator. In high conflict teams with high discord, things fall apart easily. Under these circumstances, you need to drop to philosophical introspection of your team values such as honesty, respect, reasons for existing on the project/or building the solution.
  • Project Management Layer: Managing a project founded on agile practices, even those that use agile practices partially, is no easy task. There is a dedicated layer of responsibility that keeps track of project velocity, prioritization of stories, facilitating feedback and managing change. Sure, we embrace change in agile projects but it still needs to be managed within the prioritized list of stories and other constraints of the project. This is different from traditional PMBOK style project management and deserves its own layer of responsibility.
  • Development Layer: This layer embraces the technical practices of the software developers. It includes niceties like continuous integration, test driven development, code refactoring, single code repositories that guarentee one version of the truth. This is, perhaps, the one layer that is best understood and have tangible actions at the code face.
  • Architecture and Design Layer: This layer is more than it’s really cool acronyms like YAGNI, DRY and BDUF. The focus is on gaining deeper insight into the problem domain. It very likely shares a gray and fuzzy area with the Development Layer and that’s ok. It really doesn’t matter that we have spillage into the development layer or vis versa. As long as we focus on gaining maximum understanding of the problem domain and modelling the solution as simply as as is possible.
  • Run-Time Layer: This is an oee one that I’ve dwelled on for a while. Sometimes the run-time environment really gets in the way and obstructs fluidity and rhythm in the development and architecture layer. It may well be the least agile of all layers in A-*. So, choose wisely … if you can. Let me explain a little further by example. The Ruby on Rails folk have made many screen casts that show how you can change code and you can just reload the page and, magically, the change is visible. Now compare that to someone writing EJB’s. Write, package, undeploy, deploy … it’s just painful, even if you are POJO+TDD inclined. The EJB container will bite you, eventually. So, in some respects the RoR runtime is more agile than the EJB runtime. (Aside: I think the only agile runtime in Java world is OSGi because it supports dynamic loading and unloading of classes and multiple versions classes in the same namespace. Now that’s agile!)
  • Environment Layer: The place where the team work is an equal contributor to agility. From how your workpace is layed out to desk configurations in an open plan office space, it is significant. Audible and visual communication is important and this may overlap ever so slightly with the people layer. I think the environment has a dedicated layer of responsibility in A-*.
  • Toolbox Layer: The tools you use can help you become more agile. I find that a flip chart, white board and multi-colored markers keeps me fluid and helps me progress rapidly, especially when I am working in the Architecture and Design Layer. We all have our special favorites that include the full blown IDE with our special key bindings, code diff tools, and even specialised items like shared whiteboards. I know of one team that has a Skype bot that acts as their JIRA interface – chatting to thet Skype bot allows them to update statuses and query JIRA. What tool ever keeps you agile has a place in this layer.

Perhaps, you have some other thoughts about what goes into A-* and what should be taken out. Maybe you have some real world insights that go beyond my meagre learning experiences. Drop me a note … I really would like to know how your A-* stacks up.