Bazooka Developer

It is so told, that there should come a time for every developer, when he be faced with the challenge of coding in the sky. A situation like this happens when a client is faced with a critical problem and needs an immediate solution. The solution provider decides to give it a go, sends out a repair man, for a fast, cowboy style solution, and cashes in the check.

When my turn came, I was handed the assignment along with the flight tickets and a brief rundown of the functionality I had to deliver. The functionality took about an hour for him to describe.

This kind of positive thinking often reminds me of the ‘Bazooka Joe’ bubblegum fortune, telling me that by the age of 21 I would probably land on the moon.

Keeping that same positive thinking in mind, I realized it would be a nice opportunity for setting my agile development skills to the test. I preach agility all the time. I preach it to my colleges and to my developers. I even preach it to my boss. There was no way I was about to turn ‘cowboy’ on all that.

The entire time frame for this task was less than a standard agile heart beat, but I stuck with the principles, and used them to guide me.

My first task was to deliver functionality. So I set to inquire whatever I could about the requirements. There was the way my boss envisioned it and there were some correspondence with the customer that preceded the request. I swept through the mail exchanges, to find out how the customer wanted it to work and how it ought to be fitted in the surrounding landscape of the other systems. I came out with a detailed feature list, reflecting the functionality requirements, an outline sketch of the interfaces and a high level cubistic design with a short list of would be obstacles (i.e. outstanding issues yet to be resolved).

Meeting the bare minimum to enable testability: I wrote a mock up interface invoker (two actually, that know how to talk to each other in a session like manner). Just like in the real world, my module was going to be ‘stuck’ right in between the two mockups, doing so I could have a convenient testing envelope where I can gradually grow my functionality.

I felt I was ready for some hard core coding.

Fortune: you will not get much sleep the next few nights.

I developed in short cycles. I used my short list of suspected pickles to define the steps for development. After coding a new solution that was suppose to address a particular issue, I ran the module against the testing facilities, with all the scenarios I had so far, and a new scenario that would test the solution. This got me through debugging and I made sure that I was not disrupting previously developed features (i.e. regression testing).

I know, I know, I was sprinting or whatever. In any case it kept me focused on my goals and constantly in check with working functionality.

I sprinted at the office, I sprinted at home, I sprinted at night, in the airport and on the airplane.

It so happened that by the time I got to the site, I was far from done, but I did have a prototype that was solid enough and being as it was, I had it installed on one of the development environment there.

I made use of the customer. The customer in this case was a respectable American corporate. I met there with the IT team that held everything together. Right at the beginning, they brought into my attention that they had four sets of environments. This was an important point to note since there were differences in application versions between them. The version differences meant that every time I got environmentally promoted, I had to adjust to the changes in protocol and behavior.

Fortune: an overnight success is the result of years of preparations

At this stage, I could have my testing cycles run up against real applications and not the mockup applications I prepared myself. The people from the IT team helped me learn about the extreme scenarios and together we were able to devise a meticulous testing plan. Together we defined the scope for load testing.

During the working hours, I ran tests on the various environments that were available and spent the nights at the hotel for code fixing and optimization. This was not an easy time for me. By the end of the first week we have conducted a few cycles of testing and amendment, and we were already deep into the load testing.

Fortune: the love you give is equal to the love you get

I was also able to cater for some extra requests for changes. These were minor modifications that had to do with logging and configuration options, but it made customer happy. The help I got from the customer staff I met there was absolutely essential in making the delivery and having the module go into production.

A month after I flew back, my module was set into production. Of course there were some more bugs identified and some new feature requests as well. But all in all, the customer was satisfied.

Fortune: don’t let it go up to your head

Flex MDI, Always On Top window

So how does one go about and opens an “Always On Top” window, using the FlexMDI (on flexlib)?

Sadly, I wasn’t able to find any nice solution for this problem and when such frustration comes, I resort to tricks.

My trick in this case was to wrap the MDICanvas with a class of my own, and in it I had two MDI canvases one on top of the other.

I added a nice utility method for opening a window, and according to an indicator on that method I either open it in bottom layer, or the top one; hence the “always on top”.

Not perfect, but working.

Flex loads with a blank screen

I'm developing some complex GUI app using the Flex builder 3 (eclipse plug in) and while i was working i suddenly got a blank screen when i ran my application.

no error was printed out in the consul. it appeared that flex was loading but wasn't loading my application.

if this happens to you too, check your code to see if you are embedding a file as XML:

[Embed(source="...data.xml")]
private static var xmlData:Class;

if you are, and the file happens to be malformed (some mistake in the XML structure) you are not going to see any error from the compiler or the runtime(!)
just a peaceful, zen like, blank page.

bugger

Agile Safari

A giraffe, which I hold dear, once told me that agile application development is all about pace, straight forward thinking and relevance. I can’t help thinking that us humans, like to make things all so complicated, even when we intend them to be ‘agile’.

We adore rules and regulations, and a static algorithm is fantastic when your target is motionless. The nature of things is not as static and rigid and not having a timely response might lose us the patch. “Follow your own heart”, the giraffe would tell me, “it should be as good as anything else you might find, and you can always change the rules and adapt to the new situations as they present themselves”.

I couldn’t help noticing that there was a wide nose rhino, staring at us from the other side of a patch of coffee.

Grasslands and software projects usually exist within a particular window of opportunity. The grazing has to be finished before the grass disappears: the problem has to be identified, addressed and delivered before it becomes irrelevant. “It has to be done and over with before the dry season” the giraffe would say. Managing software projects with agility is all about keeping up with the changing seasons, and the other moving animals.

The rhino was eyeing us ferociously. He wasn’t going anywhere.

Sitting there, leaned against a baobab tree, I heard the ‘agile of three points’ coming from above, straight from the giraffe’s mouth.

• Always deliver functionality
• Develop in short manageable cycles
• Make use of the customer

These three principles form the conduct and rhythm of agile development: Combined together, they insure the growth of the product in relevance, while maintaining a steady flow of fresh capabilities under close supervision and immediate acknowledgment of the customer for every step.

“Is it clear yet?” asked the giraffe. Here is some more:

Delivering functionality

Delivering functionality has to do with the continuous effort of implanting new business ideas and capabilities into the product by way of every software drop. Functionality delivered alongside other non functional changes.

The principal has two immediate benefits.

From the customer’s point of view, each code drop brings some fresh and new solutions he needs for his business. After all, new functionality is exactly what he paid for.

From the development standpoint, the proper prioritization for new functionality prevents the product from freezing while the development team works in full capacity in revising and rewriting already working code.

I’m not saying that code maintenance is irrelevant. Software releases should be a balanced concoction of improvements both in business relevance and in code quality.

Short development cycles

Development in ‘short bursts’ is an all too familiar concept to the Agile advocates. This is a principal that has to do with the pace of the development and of the software delivery.

Having short and manageable development cycles insures close proximity for each issue between the time it is developed and the time it is tested. Nothing is lost by time or forgetfulness.

Another byproduct is by having pending and immediate deadlines; it is easier to keep the developers in check and optimal production.

Of course I’m letting go of many other aspects, but I think this captures the essence.

Customer involvement

This principal has to do with relevance. Nobody knows the business better then the customer. Hence, customer’s involvement in the application development is an asset.

Sounds so simple, but it’s probably the most difficult to practice. To make this happen, the customer needs to have focal points for every issue that might rise in development, and define direct access to these key professionals.

Having customer representatives on board during progress and status meetings might sound to some as walking naked in Times Square, but the other side for this exhibitionism is the total involvement of the customer in progress and prioritization.

And while involvement means cooperation and clarity means trust, the chances of the project to eventually ‘go live’ is as high as is can get.

Maybe next time I’ll have a short chat with the rhino.

Homecoming

I have just got back from a month long vacation to Australia. No words can do justice with the magnificence of that continent at the other side of the globe. When I grow up, I would like to be an Australian.

During my too short a visit, I had the pleasure of engaging with some very interesting people in the Sydney Open coffee meet up.

Harsh times have come to the hundred-acre-wood of the IT industries, and the Australian IT was not spared. Yet, it was apparent that the world wide gloom was not in residence. The messages I’ve heard were about times of change, opportunity and of new beginnings.

It had occurred to me that in deed times have changed. The rules of engagement are being rewritten. Opportunities lay in initiative and added value, rather than in the sole code-literacy capabilities that are the tools of my trade.

I was discussing exactly this with a good friend and experienced Sydney IT Recruiter Darren Saul at one of the Sydney meet-ups. Darren mentioned that he has seen a definite shift in the way employers qualify potential employees – “after all”, said Darren, “a great organization is only as great as its people”.

The way Darren put it, is that employers need as much added value as possible and it’s no longer enough to “just” be proficient technically, it is as important to really understand your industry sector as a “Domain Expert”. Employers recruiting in the financial sector, for example, will be looking for technical support specialists or developers with a very strong understanding of the financial industry, a strong knowledge of the industry specific applications and will be looking for individuals that are generally “Business Savvy”. Thus continuous learning and broad thinking are of the utmost importance to stay ahead of the rest and ensure your place as an integral, valued and respected member of your team.

As I see it, Darren’s definition of Business savvy hits the spot in what concerns the attitude for the IT people and industry. It’s like the difference between being a co founder in a startup opposed to the first employee being hired.

When I was fresh in the army, we used to practice night time maneuvering. They would team us in pairs, and we were given two legs to cover, one for each in the pair.

While one was doing the navigation, the other would follow until it was his turn to lead. The partner that was not navigating was called the dummy. He would carry everything and concentrate on following.

We quickly came to the understanding that the more involved your dummy was, in the actual navigation, the better your own results would be. Even if it’s your turn to follow, do your best to help lead.

For more of Darren check out his blog at: www.carnegiehillblogging.blogspot.com

Step up, lead the field.

Open coffee in Sydney

I love coffee, I love talking passionately about the things i do and the combination of both was what happened to me today.

Today I went to a gathering of entrepreneurs in down town Sydney and it was lovely.

Kim H is the organizer of this particular event and it takes place every other Thursday morning, behind the coffee shop of the Allianz Building.

Hanging out with a pack of people who are so receptive to innovation and ingenuity fills me up with so much energy, i can practically run on it for days.

My verve.