Thursday, September 28, 2006

Acquicor gets Jazzy

Acquicor (AMEX: AQR) in the news again. Woz and gang have agreed to buy Jazz Semiconductor for $260 million, in an all cash deal. Gil Amelio will be CEO of the merged entity. This deal will be put up for approval by the shareholders, and will be completed only if at least 80% votes are in its favour. Jazz Semiconductor, incubated in 2002, is a CMOS wafer manufacturing firm. Numbers: The valuation comes at an EBITDA multiple of 19. Jazz had a net loss of ~15 million in the first half of 2006, hence the EBITDA rather than the P/E.

Acquicor had a webinar conference (recording available on its website) to discuss the merger, in which Jazz claims the main objective behined the acquisition is the access to Acquicor founders' network and to public markets. Gil also touched upon the non GAAP financial measures (adjusted EBITDA) to do the valuation.

I'd posted earlier on Acquicor, just about the time it went IPO. I'm going to watch this company for a while, so you may see more posts about this. My main objective is to understand the functioning of a blank check company, rather than comment on the valuations and other deal aspects.

This 260 million will come partly from Acquicor's trust, part from a line of credit (65M) and part from the selling shareholders (80M) if necessary. This means that Acquicor will have to part with about $ 115 million from its trust account, that had around $ 160 million. Will Acquicor go back to the market to raise more funds, or will it make a smaller acquisition next? This company is definitely on my watchlist.





Friday, September 22, 2006

The Ten commandments for an Agile Developer

I'm not playing God, just being Moses.

I'm putting down things that I feel are important for any developer in an Agile project. For me, any project that involves iterative planning and continuous integration is agile enough to begin with. One can see enormous benefits just by following principles like feature-driven development (FDD) and test- driven development (TDD). You dont have to go from zero to XP or Scrum to be agile. In fact, I think agility is a continuum and each project needs to find its sweet spot on it.

A lot is said and written about the need for self-managed development teams in an agile project. I interpret "self-managed" in a psychological way - I think it is a frame of mind that you need to be in, day in and day out, throughout the project. It requires rigour and a sense of self discipline. This may raise the hackles of developers who think discipline chokes innovation, and it takes out the "cool"-ness out of programming; I'll turn the argument on its head and say that to be truly innovative, you have to be disciplined about your fundamentals.

The rest of this article is about those ground rules. I'm not advocating any Agile process over another - follow whatever processes your project has decided to. This list is a daily to-do list. Over time, these things will be next to breathing for you as a developer (Do you realize how many times you hit Ctrl-S in 5 minutes?). They're really so simple, I should have called this the Zen way of agile development. I've seen its benefits, and more importantly, seen the mayhem caused when these rules arent strictly followed.

Write tests before code. Use a testing framework - there's one available for your language. Writing tests first ensures that you write just enough for the functionality of your program to work, nothing more. We often spend a lot of time writing that one extra method with that one extra parameter just in case you need to use it tomorrow. None of this happens if you first write a unit test before actually writing the code. How many tests should you write? The minimum required to make the code feature complete and secure. Use test suites liberally to create user scenarios involving a set of features. Execute these in your coffee break (Heck, why does the computer need a break?!).

Build from source on your local machine. Every day, before you start work, take the build from the build server (you should have one, btw). Treat every checkin as sacred, especially when fixing a bug. Gone is the era when you could say "it works on my machine". They dont even joke about it these days. Before you checkin, make sure you run the build scripts locally. If it takes too long to make a build, it is the build process that needs fixing (good ruse to ask your manager for a better machine ;) ).

Be lazy (automate everything you can). I mean, thats what the computer is supposed to do, right? Take the repetitiveness out of a job. So, please put the computer to work at the True Purpose for which it was invented. You can build, deploy, test, report bugs, clean-up just by pressing some shortcut key combination. There are plenty of tools available to do this - lots of them are open source too, so there's no limit to how lazy you can afford to get. I'm not going to go into details of how to automate a project (too long, and out of scope for this article), but here's an excellent book that tells you how to: Pragmatic Project Automation.

A feature in the (daily) build is worth two on the (drawing) board. This is about planning how to write your code. Rather than having "database days", where you do all your table design and "UI days" to layout all your screens, have "Create User days" where you write just that one feature - end to end. At the end of the "Create User days", someone who installs the build should be able to actually, create a user in the way your product spec says it should.
Not only is this more gratifying for you as a developer, the whole product starts taking shape much earlier, allowing for mid course changes that may come along because of end user requests, market changes, and... innovation.

Write meaningful comments. If your product is worth something, there'll be modifications to the codebase for years to come. Be polite, and write a line or two about how your method implements the feature. Rather than say /* this method authenticates the user */ (that should be clear from the way you name the method), say /* this method checks the user credentials against the LDAP server. It assumes that the LDAP connection properties are specified in a file called LDAPProperties.xml*/ It takes less than a minute to type that out, and everyone who reads your code - whether to enhance it or to use an API will bless you for it.

Honour change. Change == Good for the product. I deliberately didnt say "accept change". I think we all are mature enough not to crib when requirements change, but we still think of change as something that throws our well made plans awry. In an agile process, assume that change will happen no matter what you do. Plans will change with each iteration, features will change as users start using them, code will change as you refactor and/or integrate. In fact, it is this ability to respond to change that is one of the core tenet in the Agile Manifesto.

Love thy neighbour's code. Code reviews are one of the best software development practices I've seen. A code review can catch a lot of "thingies" early that would otherwise grow up to be "bugs". Especially in a time crunch, we tend to make some easily catchable and fixable errors (we're all so human). Loving your neighbour's code also means understanding it enough to be able to fix a bug in it. Get yourself into the habit of doing code reviews and getting code reviews done. Like debugging, it is a skill that is constantly honed with experience.

Communicate, mate! Key sucess mantra for many things in life - whether it is marriage, a football match or an agile project. If you changed a piece of code in the build, tell the rest. If you are stuck with an algorithm, ask for help. If you think you arent going to meet your deadline, say so upfront. If you found a tool that would save everyone's time, communicate. If you have the next big feature idea for the product, communicate. I think the first thing a project manager should do in an agile project is to setup a communication platform. This could be a wiki, a mailing list, a list of phone numbers, a notice board - or all of them. It is super important that everyone (including the customer) is aware of the status of the project on a daily basis. Use all the
tools you can to make communication better.

Refactor...when you need to. Developers love to refactor - there's always a better way to write that class. Refactoring code should be a part of every project because of the iterative nature in which the code was developed in the first place. Your only objective in the first iteration is to get the feature to work. In the next, you can revisit the same code (or identify common pieces of code) and refactor it into a design pattern, optimize the resources it
uses and so on. (A good refactoring catalog is available online, most of it is from Martin Fowler's book.)How much to refactor really depends on your priorities at a given time. I think it must be done once, and once is good enough.

Stay with the standards. Use standard ways of doing things wherever possible - tools, coding conventions, patterns. Remember, innovation comes at the next level - the level of your product. Follow a coding convention in the project. I dont care about line breaks and where you place your curly braces and whether it is iCount or i or count, but I do care about what you name your class, what package structure you use and where you place your resource files. Dont re-invent the wheel. Scout the open source world for solutions to some common problems, implementation of design patterns (warning: check the licensing model of any external software you use before you use it). Its okay to make an exception if you are consciously doing so.

Well, this is it, my torchlight on the path of coding Nirvana. I told you it would be simple. Amen.