Inigo
2008-05-30
On Managing Risks
Not identifying and managing risks in a project leads to problems and possible project failure. It is a critical part of iterative development process but also applies to projects in general. An iterative process helps you discover and evaluate risks so that high risk, high priority issues are dealt with during the early stages. Not dealing with them at an early stage, or revisited in an iterative manner leads to a multitude of problems.
There a few things you need dig out for risks:
- User Requirements
- Development time
- Resources (personnel and infrastructure)
User requirements
Are really important. One of the lessons learnt when I was a grasshopper (maybe still am), is that this needs to be dealt with continuously and you need to lead it. If there are any ambiguities, it needs to be cleared up. This needs to be done continuously at least on a weekly basis. Constant feedback is important, with priority on the major concerns.
Development and implementation time
For IT projects, I consider this a major risk, as it is the most expensive one and increase the risk for personnel resources. For IT the highest costs are skilled developer and engineer time. Anything the requires significant development time, is high risk. From experience development isn't a case of, let's put developer x for 5 days, and he will create 5 features. In 5 days, the first iteration, those 5 features are going result in the need for testing, result in new issues and an investment in particular code. User requirements become damn important here, as you need to make sure you're doing things so that the users can test early and provide feedback. Funcationality over gloss, is important at this stage.
Beyond that developers and engineers need to look at the technical risks and match it to user requirements. You'll need to test very early on, frameworks and components that you will be using. For example, if you're storing in an RDBMS.. does it have the features that allow you to deliver on the user requirements? These will need to be early testing focuses. As a real world example, one of Inigo's projects, the requirements was integration with different web applications or systems for user authentification which were undefined. "Undefined" means it's a high risk. So it was a testing focus way back and different authentification plugins was already evaluated and a difficult requirement was researched and communicated to the client. So when there was a suggestion to implement, we can be confident in delivering a quality solution, ahead of time. It's beyond the scope, but not beyond resources, which translates into a very happy client.
If it wasn't a testing focus, it would seem like it came out of the blue, and then developers would be pushed to implement something that their existing code base doesn't support near tight deadlines. Result? Possible delays, unanticipated problems, overtime, cutting back on something the client thought was an important requirement... well you know the drill, it's a common situation.
It can be avoided with proper processes that evaluate risks and sets the right priorities.
Resources
The previous risks also tie in to a major, major one.. human resources. None of the above matters then when you have nobody around or they are not productive. The risks are even higher if you count productiveness and quality of a good team, in addition to the acquired knowledge that may be lost. Look after your skilled staff, and have teams that overlap in skills.
Hardware, by comparison is an easy risk to manage. You just need to communicate to the client, the costs and risks clearly for this. Most clients just put in 99.9% uptime, but if you communicate with them the risks and downtime they are willing to tolerate, they may be thankful that the costs can be much lower by reducing it to say 95% uptime, and explain clearly that it will be up almost all the time, but if their is a hardware failure which is rare (once a year?), it may take up to 5 days before it is up again. People are happier when they understand the choices they have to make.
2008-04-11
Real Innovation
One pet peeve of mine is when I hear local input that for various reasons business, research grants etc. is difficult for open source.
There are plenty of examples, where local people have done very well for themselves at the local and international level. They're working for open source MNCs (not sales), wrote a key database library for PHP, developing on Linux/FreeBSD kernels, released popular open source e-HRM systems.. the list goes on. Most of the people I know in this group, don't get any form of grants, support or incentives from local sources. And yes.. they're getting nice income from it, invited to speak at international conferences etc.
The same goes for research, Andrew Tridgell who wrote rsync for this Phd. thesis and during his studies also wrote Samba So if he can do this at the ANU as a side project, why not locally?
For his master thesis, Linus Torvalds wrote Linux. What are the submissions that failed to get grants locally? Are they at a similar level?
Have a read also of Michael Tiemann's startup of Cygnus Solutions They started up with USD6,000. RedHat started in an apartment, Google in a garage.
Did you know that a local IT SME can get up to 5 years tax free profit without even getting MSC status?
A lot of innovation can happen if you main incentive is the will to succeed and not handouts.
2008-03-30
Updates
It's a relief to be healthy again. Being sick also highlighted that I need to quickly finish and reduce additional work, which are now overdue. My personal goals are to continue supporting FOSS accessibility work and continue laying the foundations for Inigo. So I'll have to cut down a lot of additional consultancy work.
Inigo
Kagesenshi's been holding down the fort for past few weeks and he has been doing good work on a UN site we've been contracted to work on. Inigo is a lot of fun as he can attest to, as we pervasively do things the FOSS way. New memory is in gambit, so slowness for past month should be gone. From July onwards, I hope that Inigo is ready to grow quickly if needed. If you're a student keen on FOSS and Python, do contact us for internship/practical opportunities. Part of the vision I have for Inigo is that we follow in the paths of many successful technical startups elsehwere. Which is that early employees have a share in the ownership and shares of the company in addition to working on stuff that's not mainstream. This is part of the excitement that you feel when you read about how companies like Apple, HP, Google, RedHat etc. started. I strongly believe, that this can be done in Malaysia also through Inigo. I think me and Kagesenshi should start posting pictures of our current environment, and then compare every few months, as our workspaces improve.
Accessibility
The main community work I'll focus on other than development would be accessibility. We plan on running volunteer LPI classes for the visually disabled and I'll try to continue support in different ways on accessibility like presenting at the Web Accessibility Conference http://accessibility.ncbm.org.my/ on how to use FOSS CMS (Plone) to make your sites more accessible and standards compliant.
2008-03-16
Overtime and Capacity
Something is screwed up when there is constant overtime and you have to work on weekends to catch up. It is never normal working practice. Spikes do happen in any industry such as end of financial year, the release date of a software project or unforeseen emergencies. Not being in constant overtime, allows us this spare capacity to deal with them. If you're constantly working overtime, it means there is no capacity left to deal with spikes.
What happens then?
People start to get sick. Mistakes start to creep in due to lack of sleep or fatigue and procedures are worked around ending up in an organizational mess.
Capacity and efficiency issues such as this require a bit more thought and planning, as it's a difficult problem to find solutions for.
An opinion was given to me, that for an IT related project, where you don't have capacity, the solution was simple, just hire a bunch of contractors. Sounds simple? This is a packer statement. It assumes that in an IT project, you can just slot in blocks and stuff will be churned out. When one of these contractors quit, you simply replace them and new hires will continue churning out stuff. Doesn't work that way, as it assumes that individual capacity such as subject matter knowledge is the same, and application for this knowledge is the same.
So a 3 year experienced person = 3 year experienced person, but both are worth more than a fresh grad. Never works that way in my experience. This same line of thinking also gives small value to the training that a fresh grad or intern gets. Oh, the value of a trainee lost is not that much, since their pay scale is still that of a fresh grad or trainee.
I hope this kind of thinking continues to be pervasive throughout the IT industry, as then I know that Inigo will continue to have a competitive advantage.
It's also why I've been slow to take up new interns or hires. I believe that adding 1 doesn't mean capacity goes up by one. In fact the team should jell so that:
capacity = y^x.
Where y is the number of employees, and x is the jell factor and ability of the team to automate and innovate by working together. Capacity is roughly equal to the output of one IT staff at a local IT company. Currently Inigo is I believe where x=2.5 and I'd like to keep it this way. In a small team, adding the wrong person can cause a reduction in this x factor, which can be painful.
2008-03-06
Server upgrade needed soon
When kenw spoke at MyOSS Meetup, he mentioned that Exoweb focuses on fast turnaround time and getting things done for the clients with high quality. This is through a bunch of best practices that I've seen to be common amongst various large successful FOSS projects.
I've been working on that idea for Inigo as the base competitive advantage and business model for some time. Now it's starting to come together, albeit a few months too early with a potential client already deciding on the Plone platform we support. Warranty replacement time for gambit's memory is going way to slow (2 weeks more). Going to have to get another two additional replacement (expensive) 1GB DDR1 sticks this weekend to hold until the planned upgrade to a proper 4 core opteron with plenty of ECC memory from a vendor that can provide next day replacement on parts. Those upgrades are not planned until July though.
Another interesting point from kenw's talk is the fact that their company is basically an outsourced IT department and paid by time for resources. angch was actually discussing the exact same thing with me several years ago. The problem was that at the time, the company we worked for, the main clients was .gov.my and it doesn't fit with their contract model. This model however does work with with clients which gives out consultant contracts.
