In favor of recession

Recession, contrary to common opinion, is a needed part of the economy cycle and more importantly for sustaining our civilization.

Booms while great, do have downsides. No need for me to write on the upsides of a boom since they're well known and even fantasized! So to the upsides of a recession:

1. Helps the 'humanity' aspect. During extended booms, its easy for individuals to became part of a rat race ie who has the biggest car, the exotic summer vacation etc etc. Recessions enable individuals to be grateful for what they took for granted. It helps reset the human clock on being content.

2. Improves professionalism. This is my favorite - during booms the dumbest of the lot start to believe an imaginary worth of themselves. During booms, the human resource shortage creates an impression in the heads of the 'not so above average' that they have abilities that need to be coveted by employers. Well, the wake up call during recessions, when the low performers are typically first to be let go helps them get out of their slumber. I've seen engineers being hired in booms who I would hesitate to hire as blue-collar workers, and that puts a dent in any organizations minimum bar of professionalism.

3. Sets up an environment for the next boom. Recessions help people realign such that the bad typically get weeded out and the great get some breathing space to kick around. This sets up the infrastructure for the next boom since exceptional talent is able to focus without being distracted by the not-so-talented.

So next time you hear that we're in a recession, stop and think if you're one of those who needs to realign and/or push harder to be the best that you can be.

Rails Developers

I've recently started noticing the same trend in Ruby on Rails development as Java development was 10 years ago. Everyone who is anyone is jumping into it. From engineers to musicians. While its nice to have a lot of developers, the end quality remains elusive. So if you're thinking about picking up Rails, ask yourself this:

Are you in it for the money or are you in it for the passion?

If you're for the former, all the best to you, I really dont have much to say after that.

If you're the latter, then I suggest you strategize before becoming a code monkey, a list I'd recommend is:

1. Read the basics - ie know what Ruby is first and then pick up on the basics of Ruby on Rails

2. Write a simple application - but dont leave the 'magic' work under the hood without understanding it. Rip it apart, figure out why something works and why it doesnt work. Scaffold's and ActiveRecord in Rails make web development look like a walk in the park. But only those developers who understand what happens under the hood make it past the standard websites and onto the more interesting and challenging tasks of scalability and security.

3. Keep returning back to the basics. A sky scrapper would fall if its foundations were to be eroded. Dont let that happen to you.

4. Be active on GitHub. Nothing beats being the person who writes code that hundreds or thousands of other developers get to use. And you'll learn meta-programming in the process too!

5. Take on energetic developers as your proteges. Every now and then you'll get a question that'll make you think even when your current projects doesnt.

6. Avoid the 'I am god' syndrome. No matter how good you are, there will always be someone better. And nobody likes a snob anyway!

The light at the end of the tunnel for Off-Shore Web Development

If you're in the offshore web development business and think there's a train coming head on - you're probably right!

I've been pondering over this for a few months now and the conclusion I come up with is that offshore web development companies are like tiny fishing boats rushing into the ocean not realizing its the calm before the prefect storm. Most such businesses today are only concerned with one thing, recruitment. Gone is the thought that there can be a storm lurking just beyond the horizon and the more they recruit the bigger the downsizing they'll need to do.

If you're a developer, work hard to be the best. Since the best define their own destiny and even during tough times can find work.

Why do I believe this is a bubble thats going to burst:

1. Recent adoption of consumer devices eg iPhone, iPad, Android, BlackBerry pad etc are sending most brands and companies into a panic attack, the same way the dot com boom of 2000 did. Most of the mobile apps being launched today are plain crappy - they add little value other than being installed on the device and allowing the user to enjoy a customized experience. But WAIT, didnt the web promise us the same? Oh right ...html just isnt ready to do the work these apps can, or is it. It doesnt matter which side of the argument you're on, we can all agree that html5 will become mainstream and these apps will be gone the same way desktop apps have.

2. It takes 3 (three) developers to do the work of one. One developer is doing the website, another the iOS and another the android (lets assume no body wants to develop for BB, WebOS and Symbian). Question: How many browsers are there? How many developers does it take to write an app for all of them? ONE! So we likely have a 3x Artificial/Temporary demand in resources going on right now.

3. Labor Intensive. All labor intensive industries have gone the way of disruption through productivity tools and automation. Software is no different, and we're already seeing the emergence of a new breed of RAD tools as well as technologies that enable porting to all devices by writing code once. Ahh - Java Applets, you were born prematurely! Flash - you suck. Microsoft SilverLight - you belong to the 'dark side'! HTML5, you'll do just fine.

So the million dollar question is, When is the bubble going to burst. Thats anyone's guess, but a market correction will come. Have you hedged your bets in terms of growth initiatives?

StartUp! Why NOW?

I've been doing extreme forms of mental tightrope walking over the past few months. And the end result is me going my separate way. Each time I state to someone that I've left my X-Company to form a startup, I get asked "WHY" ??

So here it is, and for those that dont know me, I hope it helps you think about your own aspirations and next steps.

THE WHAT

I've resigned as a CTO & partner of a mid size software services/products company specializing in web and social media applications.

THE WHY

My career path (you can check the details at http://www.linkedin.com/in/asyed) started with a step into a 20-30 engineers company and then went on to working for a 50,000 engineers company. Then the downward slope of joining a 5000 man company and then to a dozen or so engineers based one. The latter being the place I'm just exiting from and now being over 80 and likely to be the next big software house in Pakistan.

Reading the above, it almost makes me want to pinch myself on leaving a technology company when I'm confident in its growth, and by and large being a great place to be. Even my exit speech left most confused if I had changed my mind to stay or if I was indeed leaving :)

However, my biggest fear was an image of myself that I saw 2 to 5 years in the future - an EX-engineer who's stuck doing management crap primarily troubled with recruitment and employee training. Growth for a software services company will always be about the ability to recruit the smartest engineers, thats because engineers create value and not the business managers. And constant growth pains isnt the kind of problem that gets an engineer-at-heart excited. And lets face it, services industry is not for the faint of heart. Its a shop thats open for business, and you dont get to choose your customers. The customers choose you. Read the story of the mac store employee to see how even top brands have to entertain jerks at times

***Disclaimer: Most customers are professional, but every now and then the few jerks can hit the raw nerve, or at times the firms own jerk engineers can cause perfectly professional customers to match them.

And then the light at the end of the tunnel, the product idea for mid to large businesses. I remember having to waste my weekends just to file paperwork while working at the fortune 500, and its still the same for my peers working in mid to large enterprises! Keeping the actual product ideas under the lid until its ready for the curtain raising!

The idea(s) came about during the usual client calls and even recruitment interviews with fairly experienced software development managers working in/for large enterprises. And it hit me that most mid/large sized companies are still stuck in the early 2000's ... a decade of catching up still needs to be done in how most companies run their internal software development units. Having worked in a fortune 500 while interacting with a couple dozen other fortune 100's, it was like a huge 10,000 Watt bulb switching on! The ROI and the pain each employee of a mid to large size firm goes through to get their job done is considered part of the job.

No more pain for employees of mid to large size firms is the value proposition of the fledgling startup!

THE WHY NOW

I'm betting on 2011 being a great boom year, and that a professor of mine once explained to me the greek concept of opportunity or Kairos. MIDDLE EAST: Get your act together quickly, high oil prices are NOT good for the global economy!

And like any business that needs to be successful, the passion to excel and deliver must exist. And for me, its now! I believe in the mid to large businesses product space and more importantly the ability to execute on it. The rest of the matters will be tackled as they come (the "what if questions")

Lastly and probably more importantly, if you want to be part of a journey that is sure to be exciting and nothing short of a crash course in creating a great products based startup targeting the North America market AND you're great exceptional in UI design or Rails development, then get in touch with me! jobs 7vals.com (spammers - stay away!)

To Write or to Rewrite

Anyone who has ever managed engineers would know how most love a clean slate. Its natural to want and yearn for a clean canvas where the engineer can let loose their 'creativity' and 'architecture' sense.

That stated, most real world problems require adding to an existing structure. For software engineers, that means working with an existing and typically significant codebase that may crumble if not handled correctly when adding functionality.

I've seen software engineers attempt whole re-writes just to avoid reviewing existing codebase and its associated delicate handling. The question being when is a rewrite justified, and my rule of thumb is:

Do Rewrite: Existing code is in a technology that is outdated, or is written in spagetti code, or has Systemic issues (security, scalability, performance etc). All of these stated classifications must also meet the criteria that any enhancement or fix done on top of the existing code will require more time than the rewrite. The enhancement can be the specific task or group of tasks in the roadmap.

Dont Rewrite: Existing code is more or less feature complete with possibly a few glitches.

The reason to avoid a rewrite as much as possible is that code generally evolves from its original specifications, and while attempting a rewrite a lot of unwritten specifications are overlooked thereby arriving at a rewrite that is functionally less mature as well as possibly suffering the same issues that exist in the older code.

An interesting experience I had recently around this subject was with my ATS (Auto Transfer Switch). The picture of which is above. The Magnetic Connector got worn down and I asked a electrician to replace the specific component. He stared at the circuit for 15 minutes and then prescribed that he needed to completely rewire everything (and will obviously charge me for it!). On my insistance that only one component is broken, and he just needs to make sure the replaced component is installed correctly, he refused to take on the project since he had no idea of the circuit. It was obvious to me the electrician was more a creature of habit and preferred to work on circuits created by him so as to avoid having to use diagnostic tools to determine where the '0's and '1's are. I knew he'd create a similar layout and then I'd have the same problem if I ever called in a different electrician with similar traits. So I stared at the circuit for about 60 minutes after he left and it finally made enough sense for me to do the replacement (which was a 10 minute task!)

Empowering Employees

Great companies have empowered employees, and they're trusted to make the right decisions. However often we come across cases where really smart employees make the dumbest of mistakes. It shakes up the whole notion of delegation and if indeed micromanagement is the way to go (not!).

I recently came across a three letter acronym that tied up a lot of loose ends of such thoughts. The magic acronym being FAE (Fundamental Attribution Error). In summary this means that when we observe the behavior of an individual, we overly attribute it to his/her personality traits rather than the environment or context.

As an example, software engineers might be writing extremely poor code not because they're bad engineers but because:

1. Timelines - the team manager might overly emphasize timelines and not enough on quality. This will cause many good engineers to unlearn their good practices for ones that get the job done in the eyes of their manager, and at least in the short term keeps things running.

2. Precedence - if a new engineer is added to a team where best practices are not implemented, but rather the only form of measurement is getting the task checked off in the project plan, then they'll do as 'When in Rome, do as the Romans!'

3. Extreme Pressure - too much pressure (such as regularly being threatened on loosing pay/job if ...) makes things worse then good. Under extreme pressure, the 'thinking' part of the brain for most individual stops working and the primitive one takes over. The goal is to just make it to the next day without concern for making the best decision, which relates to something that lasts, scales and all the other goodies!

4. Context - Logical decisions require understanding the context. If a developer does not understand the bigger picture, he/she is likely to make mistakes since the context does not exist for evaluation of the trade offs for the design decision. So each and everyone in the team should understand what the end goal for the team is.

So next time round, when dealing with a generally smart employee having made a poor judgement call, do think if it relates to the context/environment. And if it does, how to go about changing the environment to ensure it doesnt happen again to other employees.

Operation Flood Relief - Swat, Pakistan

Picture 1: Thumb prints along with names and id card numbers of those who were identified by a survey team and then received the rations

Picture 2: This river flowed on the far left corner, while a road and houses existed where the river is now. All points beyond where we were standing were now cut off with no access to food supplies. The river was originally 50 m across, now its 230 m!

Picture 3: This is a blurry picture of a US army helicopter participating in the relief effort.

Picture 4: Just one of the many bridges washed away by the floods.

A few weeks ago I got the opportunity to participate in a flood relief effort that a friend of mine had organized. Knowing my friend to be a good planner and executioner, I took it on to accompany him during one of the many trips he'd carried out for the relief effort. Here is a narrative on my experience.

Purpose: The specific relief effort that I was part of consisted of approx USD 16-20K of food items (with due thanks to a lot of individuals that my friend had been able to reach out to). Each assigned person was to receive 2 bags of food. Which was:

a. 20 KG of Wheat

b. 20 KG of misc items including: Rice, Cooking Oil, Sugar, Tea, Onion, Potatoes and Pulses

Scale: 500 families were targeted ie 500 x 2 bags = 1000 bags = 40,000 KG's of food.

Strategy: A local NGO was picked to provide administrative support. The benefit of local on-ground NGO's with active presence during the pre-flood days being they have good awareness of the ground situation as well as crowd management, a major issue which I'll refer to later. The particular NGO picked during my trip was MuslimAid, a UK based charity organization.

Our original goal was to target Mianwali, a city in Punjab submerged by water, but thanks to the feedback from the NGO, it was made clear that this particular town had now started receiving flood relief and aid. Swat, an area in the north western area of Pakistan (now known as Khyber Pakhtoon Khwa) however was not receiving much aid and the situation there was quickly becoming catastrophic. So Swat became our target area. Specifically Bahrain, Kalam and Uther town residents (there is no road link to any of these towns at the moment)

Execution: Three trucks loaded with relief goods were prepared with the help of MuslimAid, and directed to move towards Swat. In parallel, an on ground team started the survey of affected families and handed them coupons for collecting the ration items at a pre-stated distribution point and time. Most of the families sent an adult member or two to hike to the collection point to bring back the ration.

The trucks reached the point of distribution in the morning while we (NGO rep, my friend and I) headed off to the area separately. At the pre-determined time of distribution, the NGO rep first gave a run down of the distribution strategy to those who had gathered. Only those who were in the list were to receive it, so others need not wait. And being orderly was a requirement since everyone on the list would receive the rations, and it may take some time but at least no one would be hurt in the process.

Most of the folks had come after a day or ever 2 days of trek. Swat is unique in the type of flood devastation since it was not devastated by the water coming into the towns as its a mountainous area, but because of massive landslides. The landslides had cut off major towns of the area that were known to be dependent on the lower areas since vegetation and food items were not grown in abundance at high altitudes.

Most of the rivers had carved out 2x areas for themselves. An analogy would be to assume the grand canyon was populated by thousands of people and the road network to be around the cliffs of the Colorado river. And the river suddenly swelling up and eating away all the bridges and most of the road network by carving out double or even triple area for itself leaving people stranded on cliffs and mountains (those who were not washed away) with no food.

As the folks came by one by one on their name being called, they lifted two bags weighing 40 KG on their backs; an immense sense of sympathy struck me on what still remained for them to return back to their families. A trek of a day or two with two bags weighing 40 KG must be back breaking. I do hope all of them reached their loved ones and they were able to have a decent meal to eat for a few weeks (our estimation was the ration would last a family of 5 around a month).

Conclusion: Relief effort is not for the faint of heart, although I believe we should all make an effort to participate with on site presence, since it helps ensure minimization of wastage since food is not dumped in the wrong areas or distributing of wrong items is fixed by enabling quick feedback to the stakeholders.

And by using on ground NGO's or other individuals well versed with the locals, who have done their homework in terms of identification of needy families and individuals, the distribution can be extremely gratifying knowing its going to the needy who may not be strong enough to stand random food throws from the sky or fast moving trucks. The planned effort also ensures:

a. Fairness - Relief goods that get thrown from trucks or helicopters in crowds typically lead to the toughest men receiving it. It truly is the law of the jungle since every man and women are up for themselves in trying the snatch whatever they can grab for sustenance. The worst affected individuals suffer since they're typically too weak or hurt to be in the crowd.

b. Civilness - Random distribution leads to reinforcement of unruly behavior during relief distributions. We observed a distribution of water bottles during our trip (claimed by someone to be from Jazz/Mobilink), where two individuals were throwing away bottles and two were using sticks to fend off the crowd from climbing into the truck. Once they left, it could be seen that a few folks had a few packs of bottles while most had nothing. The sad part was that this area had ample clean water since Swat is an area of natural water springs! It was food that was scarce.

c. Measurable benefit - All individuals who collected the relief items were checked against their national ID card number to be residents of the affected area in addition to having the coupon and listed in the survey list. The ID card numbers were then to be submitted to the local administration to ensure they know which families have received rations to facilitate other ongoing reliefs. Of course, I think its obvious the lists would not be used by local administration since they're not known for their competence, however that shouldnt be a reason for not following through on this practice.

Miscellaneous: A number of helicopters could be seen flying, both Pakistan and US army. It was heartening to see US army active in the humanitarian relief effort since the only way to get food to the worst affected areas is to ask the folks to do the 1-2 day trek (like we did), or use helicopters.