Umair Aziz

I’ve been reading ‘The Pragmatic Programmer’ by Andrew Hunt and David Thomas. I don’t think I could have done justice by paraphrasing their observations on pragmatic programmers – so here it is verbatim….

“Programming is a craft. At its simplest, it comes down to getting a computer to do what you want it to do (or what your user wants it to do). As a programmer, you are part listener, part advisor, part interpreter, and part dictator. You try to capture elusive requirements and find a way of expressing them so that a mere machine can do them justice. You try to document your work so that others can understand it, and you try to engineer your work so that others can build on it. What’s more, you try to do all this against the relentless ticking of the project clock. You work small miracles every day.

It’s a difficult job.

Read more…

It has only been 15 months since we moved out from our “software house” on Hali Road into a classy 5000 sq. ft uber-tech, architect designed space in Clifton. It took us over 10 months to build and by the end of it we were tired, went way over budget, and ended up with one of the best looking offices in the city. My partner and I congratulated ourselves and thought our new home would serve us for a good 3 years. We were so wrong!

Our office seats 60 people. Currently there are only 2 seats empty and they will be occupied in the coming week. We have 18 openings and are aggressively interviewing every day to fill these up. We anticipate a need for another 20 engineers in the next 2 quarters. If you do the math – you will see that we need more space for another 40 engineers.While some of you may be thinking how in the world are we going to find so many people – let me tell you that finding developers is the least of our worries. Here at Creative Chaos we’ve got ‘finding the right engineer’ down to a science. Its pretty simple actually – find the smartest software engineers in the country and hire them. No seriously – that’s it. I’ll repeat it again – find the smartest software engineers and hire them.In a class of 100 students, only 9% are smart, of which 4% are outstanding and 2% exceptional. The rest are just average. We do not hire average at Creative Chaos. That may sound discriminatory but that is the way things are here. Who would rather have as your heart surgeon, a top student from a high profile med-school or a doctor that is just good enough? When it comes to choosing a software engineer to design and develop your applications why would you ever choose an average engineer?Just like the best physicians and surgeons – the top 9% software engineers in the world can work anywhere they want. They are never desperately looking for jobs – and are usually busy working their way up the ladder. The average ones are busy zigzagging between different roles / responsibilities and organizations.It is much like applying to college. The best students apply to tier one schools, the above-average ones apply to tier two and the mediocre ones are stuck with tier three. Students with high SAT scores (1450+) and decent applications are pretty much guaranteed admission into any Ivy League institute. Why does one choose a tier one college? And aren’t these colleges discriminating? Well of course they are – they are targeting students that exhibit intellect and intelligence consistent with their ranking and profile. The students understand this and to them the name and reputation matters. They also know that good colleges invest money in creating state of the art facilities, hire the best professors and guarantee a rigorous and challenging program. And that’s not it – these colleges are also willing to give money (scholarships) just to have these top guns study at their institutes. It makes perfect sense for smart intelligent students to choose a tier one college.

For some reason people running software companies don’t understand this. I keep hearing from friends in the business that they are unable to find or hire good programmers. The problem is that they have not yet defined which tier their software company lies in. Their interviewing is not targeted which leads to frustration and hiring mistakes. I have only one thing to tell them – if you want to attract top talent, go fix up your office, create an environment that is fun and challenging and once you are able to bring some good folks on board – then empower them and treat them well.We think of ourselves as a tier one specialty institute and are absolutely discerning about who gets to be part of our family.

We spent a lot of money on our office – not to impress our customers but to provide our employees a great place to come in to work every day. We engaged an expensive architect; thought about lighting and ergonomics, installed RFID sliding doors, custom built our furniture and used European tiles.When these smart tier one candidates come to our office for interviews their faces light up. And while they are still admiring the interiors – we ask them if they would like to drink coke, mountain dew or coffee before we get started. We tell them we have a vending machine and all sodas are free, munchies and late night dinners are all expensed. We have contracted vans to pick and drop everyone at home so they don’t have to worry about commuting. And incase some one stays late to finish off work and misses the van – we happily expense their cab fare home. These smart engineers can work for any company they want – we want to show them that we have a top notch environment where coming to work is fun and challenging.Our vision is to create a model software company. We believe that we can only produce top quality software by employing top engineers and creating an exciting working environment that our people can cherish.

As the saying goes – a happy engineer is a productive engineer.In order to seat the 40 odd engineers that we plan to bring on board in the next couple of quarters we have taken up another 4000 square feet of office space in a building next door. We will once again engage an architect to help us out create a great facility, experiment with a few new ideas and overcome previous short-comings.Last time around – due to space constraints, we were not able to create a large enough kitchen. In the new office we are planning on setting up an in-house café with seating space for 20-30 people. We will have a waiter to serve coffee / tea, put in comfortable couches, a large screen TV, an Xbox 360 and if we have space – maybe a pool table as well.

Writing code is mentally exhausting and we want our engineers to have a place to de-stress without ever leaving the office.In our current office a lot of the developers sit in an open space planned in cubical style straight workstations. We thought this would work out great – everyone would be close to each other and would allow better communication. What we did not realize was that that when people would communicate they would disturb everyone in proximity. The space occasionally gets too loud and distracting. The project areas on the other hand (rooms to seat 5–7 engineers) worked out really well. We create agile teams to develop applications and seating the whole team together in a room not only gives developers a sense of privacy but also allows them to self-manage their conversations and noise-levels. The new facility will only have project space seating. We also plan to add more conference rooms, at least 2 discussion rooms (6 people) and 1 large conference for 16 people.We don’t have 10 months to build this time and our budgets are pretty tight. The plan is to have the site live by the 1st of May 2008. I know the next few months are going to be painful but the thought of providing another great facility to our engineers excites me.

I’m looking for project managers to help me out with some new projects. I have interviewed at least 25 candidates in the past couple of months; some with just 6 months and some with 16 years of experience. I always ask how these managers estimate time and effort and come up with release dates for their software. As expected, 90% of the candidates tell me that the release dates are dictated to them by ‘their management’. Which leads to my next question – so how does ‘their management’ come up with the date? What is their estimation technique? The typical answer has been that it is a function of how urgently the client / product marketing wants the application and the experience of the firm in developing similar applications.

Most of these managers I interviewed confessed that they have usually taken these dates with a pinch of salt. They protest – but in vain. Some break through and are able to buy a few weeks. However I hear the same story over and over again that their CTO, product marketing, business management and customers drive release dates. And just like that – all the time -managers all over the world are taking on a date thrown to them by a bunch of people who are not active developers or don’t understand how software is developed. The development teams (and their managers) think they will be heroes if they accept the date and then make the release on that date. Developers are skeptical at first and will tell you it is a difficult ask. The project manager will persist telling them how much confidence the management has in their capability and the fact that it is a challenge makes it a perfect opportunity for them to win and shine. Think recognition….bonuses…promotions.Most developers live in a fantasy world and think that they are ‘supermen’. It really doesn’t take much to convince them to take on un-realistic deadlines. Just keep telling them how super important / business-critical the task is and that if they try hard they ‘can do it! Yes it will require late-sittings maybe even some weekends – but it will all be worth it at the end of the day. A great product will be released on time, customers will be excited, money will roll-in – and management will laud the heroics of the development team!Thus the project manager marshals his troops into battle – knowing well that the road ahead is difficult however is convinced that his team of supermen who have ‘accepted the date’ will ensure that he becomes a hero too.Back to my interview where these project managers think their management pulls dates out of their ass (excuse my french) – and makes them look bad when they can’t deliver on time. I ask them what they want and what should be done? To my surprise and disappointment all of them tell me they want control over the date. They tell me that with the help of developers they can now come up with better estimates. And since the developers are now involved in time estimation – we can be hold them accountable and responsible.I tell them I can give them anything they want – (even unlimited resources!) – however everyone seems transfixed on the date and wants control over it. They truly believe that the solution is that management and client give up their right to setting release dates and hand it over to the project manager and the development group. This is the only way we can ensure that our project doesn’t fail.As logical as their request sounds – it is sadly unrealistic and impractical. Developers and project managers can never have control over delivery dates. These dates are tied with revenue and allow these companies to maintain cash flows and pay their monthly bills. No matter how good a reason developers give – if a company needs to realize revenue in a given quarter they will make sure a milestone release date is set in that term. Unless you are Microsoft (who just delayed SQL 2008 by a year) – the financial repercussions of moving release dates is tremendous.And that is why project managers and developers can never and should never set release dates. Since no one has unlimited resources – project managers have to work with time and resource constraints on any given project.Project managers should fight over what will be delivered – not when. The stakeholders of the project (management or clients) should tell dates that matter to them most. These dates are business-critical and should not be tampered with. Stakeholders are also responsible for creating a prioritized list of workload. We must know which features are most important and which are the nice to have items. Project managers should then work with the developers to create a set of iterative releases based on the release dates provided by the stakeholders, focus on the most important features and deliver them when they are needed.Project managers should be telling stakeholders that they can deliver say 6 out of the 10 features by their given date. The stakeholders get to choose which 6 features make it in the release. If the stakeholders insist on all 10 features and say all are business critical and must be done within the allotted time – project managers should walk away. They want you to be a super hero and if you don’t have special powers like batman and superman chances are you’ll be working hard – beating yourself and your developers to death and finally getting rewarded with a pink slip at the end of the project. Note: I’ll be writing more about stakeholders and how project managers should estimate team velocity, identify release work-load amongst other areas in future articles.