Mujtaba Hussain

A long time ago in a university not so far away, I was about to commence a subject that every body said was one of the most fundamental subjects available. Software Engineering; Processes and Tools. Before that, I had completed(barely) the prerequisite for that which introduced us to the basics of Software Development. So I was excited and very motivated to get this one down pat. I really wanted to do this right and learn as much as I could about the intricacies of designing and developing software in a team environment.

Apart from the usual load of assignments, tests, tutorials and final exam, the one thing that marked this subject out was a large project designed to be completed in a team environment. Whereas previously, in the prerequisite, I had worked with just one other person, this subject would involve teams of five and/or six. I was very excited and immediately approached a few of my friends in the same year and we all agreed to do this project together. I distinctly remember thinking at that point, this is going to be fun!

Alas, I was wrong. Very very wrong. And all the misery that ensued from that point on had one and one simple reason. I was not objective! Don’t get me wrong, my friends were very talented and committed, but they had different scales of working. They all worked in a different manner, some at different times of the day! Some worked at home while some preferred to pull night shifts in the university! The only thing that bound us, was that we were friends! And therein lies the problem. Had I approached my friends on the basis that they were very talented people with whom I could objectively work and finish this project and my friends, in specifically that order, we might have developed very good software. As it turned out, my priorities were skewed. I wanted friends to work with, not to work with friends.

Hence the point of this post. One must always, always, be objective. If you are working with friends, in a professional environment, you must be able to tell the truth to them, in front of others and in private. If you are leading a team, then you must be able to tell people to pull their weight, first by example and then by actions. Being friendly with your friends only works when all of you are clearly working towards a goal and objectives are clear. Trust me, friendships are strengthened when you are brutally objective towards each other professionally.

Postscript: We managed to pass the subject, but ended up not learning much. And thanks to ashridah for the objective talk after my results.

1984 made me experience unplumbed depths of anger. Brave New World did the same, but for frustration.

I can’t tell which is happening now, if not both!

I can’t tell which scares me more!

A very good article on the what a Cyber War entails. Taken from here

Using cyber attacks to spy on another nation is a grey area, which gets greyer still when a country penetrates information networks, just to see if it can do so. Penetrating such networks and leaving a back door open, or even leaving logic bombs behind to be used later, is a harder case—yet the US and China are doing this to each other right now.

On the second and final day of the YOW 2010 conference, there were a few management oriented sessions in the evening, a few technically descriptive ones in the morning and two very nice focussed ones in the middle. These were the DevOPS session presented by Michael .T. Nygard and one about taming large builds by Chris Mountford

Chris started talking about how they worked at Atlassian, particularly on JIRA and how they have problems testing and managing the tests. He showed us a few screen shots from many of the builds and frankly they were monstrously large, especially the one about JIRA, which between the time he had made his presentation and presented it, grew larger. He mentioned some very nice techniques that could be used to prevent and/or maintain monstrously large builds as they are very bad. Why ? Because builds are there to give you better feedback and quick. A build that takes 10 hours is of no use in an Agile world. Another thing, which might interest the business owners more, is that large builds have large turn around time and consequently more time needed by the developer to fix the build, which is less time she or he is spending on the work that the business wants done. The one thing I figured that Atlassian does that we don’t do are Canary Builds. But soon, I think we will. A very good session that was very informative, and slightly reassuring that we are not the only ones wrestling with huge monstrous builds.

It was refreshing to have another session which based on actual events and the conclusions and/or lessons that could be and were drawn from them. I have seen many speakers over the last two days conjure up scenarios to fit the example on the upcoming slide, but this was very nicely structured around real world events, with pictures as proof. The whole session was basically an operational and development postmortem of a few events and why those events demonstrate the invaluable aspect of no barriers between developers and operations.

Then Michael went on about how they diagnosed incidents along with developers after chaotic incidents that led to downtime. How they went step by step through any causes and how they actually constructed a KanBan wall without realising it. How process went out of the window and how that had both good and bad consequences. He also reflected on how that defined, to an extent, the intersection of the roles a system administrator and a software developer.

All in all, of all the talks in these two days, these two are the ones I have enjoyed the most. Practical, simple, and extremely well presented.

On the first day of the YOW conference, I was pretty excited about the post lunch session (even after eating a delicious lamb kebab). The two topics that I was very interested in were NoSQL by Justin Sheehy and Strategic Design by Eric Evans.

So off I traipsed into the NoSQL talk, eager about some new news on things like CouchDB, MongoDB and maybe a bit about Mongoid. It certainly was not what I expected. The first half was passionate analysis of what exactly NoSQL is, and more importantly, how we should choose it! The second half of the talk focussed on Riak and I confess uptil today, I had no idea what it was. From there it was a bite more interesting to see actually how Riak worked and how scalability and extensibility were inbuilt into it. Not sure I will be using it anytime soon, but good to know me thinks.

Out I came from this one and went to hear the Strategic Design talk. It was a very well constructed talk on how the best of motives could lead the best of developers astray by setting wrong goals and the drive to never make a compromise. And also metaphors are slightly evil . But the talk was worth listening to, as it demonstrated how refactoring needs to be targeted and how to get business on your side to sponsor the things you think they won’t agree to. Eric demonstrated how models can be extracted in different forms by using a poem, a map and a quote as example domains. It was pretty instructive. Looking back at some of the work I have been doing at personally and some work we have been doing at REA, I would definitely say that we have implemented a fair number of said strategic ideals, especially for the latter body of work.

And that pleases me

Tomorrow, is the last day of YOW 2010 and I am excited about a devops session amongst others.

I am currently sitting in the foyer of the Jasper Hotel, sipping a cup of tea, thinking about the two sessions I have just had and the one I am waiting for. The sessions got kicked off by Obie Fernandez about the evolution of Rails 3. My first assumptions on listening were that I do not know why I want to know how Merb and Rails merged and who was involved and what was said to whom. But I was clearly in a minority. I put this down to the fact that I have not been as involved with the rails community as much as the majority of the people in the room.

Towards the latter half of the session, Obie began showing the new features in Rails 3 and I have to say that they do look very promising. I have not yet used Rails 3 myself (I began installing it in a separate gemset during the talk) but things like routing(in routes.rb), deploying(using rack), persistence handling and querying (using ActiveRecord etc have been made very very and easy to understand. I particularly like the lazy execution of DB queries and the subsequent chaining. I am told that upgrading from 2.X to 3 is a bit of a pain, but I guess I will find out.

The second session was delivered by Neal Ford about how he was involved a 3 year (and possibly ongoing) long project using Rails that is very enterprisey[sp?] in nature. It was interesting about the philosophy of tests should do but a lot of talk was bout the tools used. (A lot of them happened to be ThoughtWork tools )

One interesting point that did come up was that they had 15 pairs sometimes having one stand up and that the stand up was still quick! I would have loved to see how that was enforced, as I know that from first hand experience that that is not easy. They created things to make software development easy and they made life of people as easy as possible so that people could concentrate as much as they could on their core task.

But what I liked most of all is that they had 4 work day weeks. 10 hours a day, sure, but small price to pay for a 3 day long weekend.

I am currently waiting for the next session, which is titled “Why NoSQL” and I am really looking forward to it considering I am thinking of moving my personal projects over to Mongoid

I am currently sitting in the lounge opposite what is known as the green room at the Jasper Hotel awaiting the start of the YOW Conference for 2010. There are quite a few interesting talks that I want to attend but I am not sure what I am hoping to get out of them.

My idea of a good conference is 50% talking by speakers, whilst showing what they are talking about (preferably in the form of working code) and 50% code hackery based on what they talked about. The DevFest in Sydney was cool like that. I heard about new features and then I got to hack at them. Lets see what this brings.

At the moment, there are lots of companies with lots of stands and even more coffee stands. I have taken a few pictures and will be posting them soon, along with my impressions of the talks.

As a side note, turns out my company is a silver sponsor.

As a student of Computer Science, a university can have two roles. One is to teach you how the very fundamentals of Computer Science and the other is to teach you how to think independently in situations which you may not have encountered before. Situations in which you can use your creativity and intelligence to develop better solutions. The latter is highly important because that is the one which makes use of all your gray matter. But now I feel it may not be so important.

How many jobs can you think of in the industry where you will be working on something new? Something exciting? Something that will keep you up at night trying to think out an elegant yet logical solution? Not many I would say. Most of the time, when you join a place as a Software Developer or a Programmer or an Analyst, you will be working on something that has been developed by someone else. Sometimes it will be interesting, most of the time, not. Most of the time you will be maintaining, and not developing. It is no one’s fault, it just the way industry works.

The Software Developer is dead. Long live the Software Maintainer.

Today was fun. A lot of fun! I paired all day today with Jared Hunter from operations and we spent all day deploying about four applications written in three different languages to two different environments using three different deployment tools. And today’s attempts have made me realise a lot of things

….

OK fine, I am lying. It wasn’t a lot of things!!!

But this experience has made me realise a few things!

Operations are over worked. I knew this fact of course. I knew this in the same sense as I know getting shot or being stabbed hurts. There is a lot of difference between knowing and realising. We spent nearly two hours in total debugging failed deployment because certain assumptions were made in the applications which did not coincide across all environments. Sometimes the environments were at fault, sometimes the applications.

I have learnt that one cannot leave deployment towards the end of the iteration. It must be planned at the same time as when we kick our iteration off. When we discuss the work planned in the iteration, it is at that point, we must write our deployment notes, and keep adding to them as work keeps getting done. The deployment notes should be nothing less than a technical card and must be approached by the business in the exact same way as developer asking to remove some technical debt.

The problem with leaving deployment planning towards the end of the iteration is that people have to now remember work they did at the start. Do it at the same time as you hand over the card to QA and you are done with it; no more chasing up after the fact.

I have learnt that having consistent deployment procedures when you deploy applications written in three different languages is not possible. Layers and layers of decoration buffers must be applied between the deployment procedure and the applications for that to happen and God help you if you have to then debug something. Java is very different from Ruby and Perl. And even though the latter are both interpreted, the way they manage dependencies and interact with other system layers is different. At least the way we do it. Choose one platform, if you can, and stick with it, if you can. It makes deployment, debugging, rollbacks and dependencies much much easier.

I learnt Puppet is very cool. I managed to give access to a bunch of users across different environments, documented the change and kept the history of the change for posterity using puppet in a few simple steps. I will however have to shelve my idea of using Babushka and Puppet together. (I think I had had too much coffee at that time).

Last thing I learnt is that canadians have a very good sense of humour, no matter how much you needle them about maple syrup, or ice hockey or you know, basically being Canadian. They are a lot of fun to work with! Mad props to Jared and Kerri for giving me that belief. Come to think of it, even the tree we associate with Canada, the Maple tree and the tree associated with Kashmir, the Chinar tree are similar.