Monthly Archives: February 2013

 

There’s always a tradeoff between time, money and quality in software development. More often that not nowadays, product managers are asked to deliver excellent products on a tight schedule and on a budget. Agile processes and the trendy idea of the minimum viable product only confuse things further because they seem to prioritise quick iterative development and a tight rein on features. How does one build a good product on time and keeping startup thriftiness in mind? I have six clear steps for you to follow:

One: Before building anything, dig to the roots and find product goals. Ask your client (or yourself) “Why do you need this product built?”. Answers like “We need to run a twitter campaign” or “We want a CRM for our sales team” are not clear enough. “We need to run a twitter campaign to promote our new startup” & “We need a CRM that tracks and updates senior managers about daily sales” are better answers, but ideally what you’ll dig for and get is the true reason behind the product’s existence. For the twitter campaign, it could be “reaching out to potential customers who are likely to purchase our startup’s product”. For the CRM, it could be “improving sales performance and making our sales team more accountable”. You are digging for goals—the why—not features—the what—that comes later, and that’s less important.

Two: Minimum viable product is a great idea. But when choosing what to whet down, keep the goals in mind. I have little patience for managers who come back and tell me, “But isn’t this what we decided to build?”. If you can’t deliver what your clients need, then you aren’t doing a good job. Keep product goals in mind, and prioritise features that will provide the most bang for the buck. Only then will Agile and MVP work well for you.

Three: Find great developers. What’s more important than your process are people. Great developers can manage themselves, figure out their own deadlines and do a lot more than a mediocre developer. Give them great tools too: a good working space, the editor that they want, and their operating system of choice. It’s also much better when you have a good team to split work into spheres of responsibility rather than into discrete chunks where many developers work on the same piece of code. Adopt practices like pair programming & SCRUM and promote discussion within the group. If at all possible, guide every discussion to a consensus and make sure every developer is aware of potential tradeoffs.

Four: Try as much as possible to not build engineering debt. This is easier said than done, but few rules go a long way: adopt a good source control system and practices, a development, staging and production deployment for every product, a continuous integration and deployment server, and have a system in place to code-review every commit before it gets merged back into the main tree. Make your developers police each other.

Five: Have an independent team to do security audits & quality assurance. This is a “manual testing” team, and while they might use several different tools, their mandate is to make sure the product has the features necessary, doesn’t have bugs, and is secure from a security standpoint. This team can be external to the company as well, but it needs to build a good rapport with the engineering division so that they don’t work at odds.

Six: Have regular deployments or sprints. Nothing focuses a developer more than a predictable schedule of deployment. Divide chunks of work into sprints and have staging deployments between them. Make sure that developers are responsible for successful deployments and pour woe to the person who breaks the build.

Well, those are the rules. Sticking to them is hard, and at times impossible, but my experience is that any deviation has always resulted in a loss of quality. While that might be acceptable in the short-term, in the long-term, it always comes to bite you on your ass. However, being a product manager is one of the best jobs out there! Figuring out the nitty gritty details of product construction, overcoming obstacles, finding consensus within the team and outside, and finally, building a product that meets the requirement is a very rewarding job. I’ve done a few stints here at MobME building good products and I’ve loved every challenge.

Update: I’ve started a Github repo that has completed assignments.

I’ve mentioned this before countless times to friends: the Stanford course on iOS Development is really mind-blowing. It’s the best way to learn iOS and Objective-C: Paul Hegarty is a wonderful teacher, the content & density of the slides is excellent and the complex Cocoa Touch framework and the Xcode 4 development environment is brought out very well through hands-on coding sessions.

Just to take one example, take a look at this slide above detailing MVC in iOS. I can point out dozens of developers who wouldn’t have this condensed understanding even after months with the ecosystem. In this small slide, you have:

• Models, Views & Controllers with road lines between them depicting the fact that models and views never talk to each other (double-yellow line), controllers always talk to models and views (dotted white) and when models and views need to talk to controllers, they do so in very defined ways (solid white).
• When views need to talk to controllers, they either fire an action arrow into a controller target, or delegate will, should, and did methods to the controller, or when they want data from the controller, set up a datasource and ask for data at & count methods.
• When models need to talk to controllers, they set up a radio station and broadcast notifications that controllers then tune into.

And this is just one slide in the introductory lecture. It’s a wonderful time to be a self-taught app developer. The Stanford course is right now ongoing and lectures are being updated on iTunes U. There’s a Piazza discussion forum as well for the course.

So I recently got a bunch of calls from an NGO calling itself Relief India Trust. The calls themselves were a bit odd and over zealous with the volunteers flinging themselves at me and describing the plight of children in gory detail, but it was the frequency of the calls that first gave me a clue that something wasn’t right. Then, when I finally decide to put in some money, there’s a volunteer who calls me up, takes me through the donation process and then offers to stay on line until I give her a Transaction ID for the bank transfer.

I did up a Google search and found tons of consumer complaints about the organisation. And if you notice their NGO registration number in the link above, it’s just a plain four digit number: 3696. The Indian Government has an NGO search site where you can search for voluntary organisations by name or their unique registration ID. 3696 doesn’t turn up Relief India Trust. Neither does a search for their name. These are a bunch of scam artists.

Real NGOs probably needn’t be this aggressive. I donate every year to SOS Children’s Village India, which has been my charity of choice since forever. They have a unique take on bringing up disadvantaged children, a personal dialogue (if you wish it) between your kid and you, and I’ve visited their centre in Kerala too.

Update: I’ve receive a legal notice from Relief India Trust. Further developments in a new blog post: Relief India Trust, the Scam NGO, Files a Legal Notice Against my Blog Post for Defamation