Three Things I Learned About Software WHILE NOT in College

29 June 2007

Scott Hanselman lists three things he learned while in/not in college. Here are three things I learned in/after Uni.

Things I Learned about Software in College

  1. Always lock resources in the same order to avoid deadlock
  2. Adding more whitespace around your code gets you higher marks
  3. Friends let you see their private parts

Things I Learned about Software While Not in College

  1. Software is only soft if you build it to be soft. Otherwise, its a trade off between refactoring or hacking to change it.
  2. Iterative development doesn’t work when phase 2 is a complete rebuild of phase 1 because you didn’t get the requirements right in the first place
  3. You will never ‘add the comments later’

2 Comments | Software | Permalink
Posted by Andrew

PlanHQ

28 June 2007

I’ve had the opportunity over the past few weeks to use PlanHQ to prepare a plan for a small software project.

Writing a business plan can be daunting and can often end up containing useless information, or being far too long. I found PlanHQ to be a good way of keeping the plan focused and organised. It guided me though the high-level thinking about the vision, objectives and opportunity before getting into the detail of the solution. The fact that I could also leave the marketing & sales section to someone else, while focusing on the delivery plan was excellent!

What sets PlanHQ apart is the integration of goals and finances into each section of the plan. The goals help you to plan for important milestones and keep the financing in-sync while executing the plan. The new dashboard also helps to keep you focused on the goals that will drive the business forward and keep your plan alive instead of gathering dust like most business plans.

The only downside was the limitations on the cheaper plans. My plan was very small, yet I needed the top price so I could have more than 10 goals. I’d rather have no limitations on the content in a plan and pay more to manage multiple plans.

Check it out: www.planhq.com

1 Comment | Business, NZ Companies | Permalink
Posted by Andrew

Straylight Studios

24 June 2007

I met Tim and Emma from Straylight Studios about a year ago at a small business expo and was quite impressed with them.

They’ve now just released their virtual kitchen training system, which is a 3D training environment for the food industry.

Straylight’s CEO, Tim Nixon, has been guiding the company’s vision to bring games to the mass market by finding immediate vertical opportunities in the Serious Games sector, a highly untapped and lucrative marketplace. Previous Straylight developments focusing on such markets as Small Business and Injury Prevention training have paved the way for this highly detailed, yet incredibly intuitive educational tool.

While the momentum gathered for this product is already huge, Mr Nixon insists that this really is only the beginning. “We’re working with partners in Europe, and the USA to ensure that we’re finding the most exciting opportunities worldwide, not just in the training space, but also in ways we can bring our distinct accessibility to the entertainment market.”

This innovative development and more are profiled on Straylight’s website http://www.straylight-studios.com/

Another software company that NZ can be proud of. Go Tim.

Leave a Comment » | NZ Companies, Software | Permalink
Posted by Andrew

s.i.m.p.l.e.

12 June 2007

No blog would be complete without a post on simplicity, so here’s mine. Simplicity is:

  • The ultimate sophistication
  • Taking a pencil into space
  • Ditching basecamp … if it doesn’t do half what you want, then its simple to stop using it

When it comes to building software, keeping it simple can mean anything, or nothing. Is less features simple, or is it simpler to have the tools at hand to do the job? Is better design simple, or is less design simple? Is less engineering simple, or is more engineering simple?

Here are six trade-offs for keeping software development simple:

S Scope Keeping the scope simple means less complexity, but less product. Keeping the scope simple is a good divide-and-conquer strategy, but needs to be done within a bigger context to ensure its not just scatter-gun approach for developing features.
I Interface Keeping the interface simple means a lot of design and testing and hiding and automating complexities, which can mean more logic and more complicated engineering.
M Maintenance Keeping the maintenance simple means good engineering and architecture, but with more cost and less-simplicity up-front.
P Planning The most simple approach is to take the first and most obvious solution, but is likely to mean more complex scope and interface and can result in building the wrong thing.
L Logic The fewer business rules and behind-the-scenes smarts, the simpler it is to understand and build, but needs to balanced with the scope. To simplify logic without simplifying the scope will lead to under-engineered software. To simplify the scope will naturally lead to simpler logic.
E Engineering Doing proper R&D and architecture will give a simpler, more elegant solution, but requires more work upfront and isn’t the simple approach of ‘just building it’.

Focusing on keeping the scope, interface and maintenance simple is a good thing. Trying to make the planning, logic or engineering simple is a bad thing.

All this aside, the most important factor to keep simple is the cost/benefit. As Joel Spolsky says, “With six years of experience running my own software company I can tell you that nothing we have ever done at Fog Creek has increased our revenue more than releasing a new version with more features. Nothing.”.

3 Comments | Software | Permalink
Posted by Andrew

Estimating a software product

1 June 2007

Estimating the development required for a software product is quite different to estimating a project or single feature, so this is part 2 to ‘Estimating a software project‘, which suggests quite a different model for estimating when it comes to new products.

A product estimate has to be based on a roadmap, so is really a series of estimates. This would be easy if only the roadmap was clearly defined, but at the inception stage of a product, the roadmap is often being driven by the estimates, so its a big catch-22.

To provide an estimate for a software product, I use the following model:

1. Understand the objectives of the product

This is important because to create an estimate that has any value, you’ll need to divide and conquer and a good way of doing this is to create a model. As soon as you start doing this, you’ll have to start making decisions. Decisions about scope, features, roadmap, business rules, use cases etc. Its important that all of the stakeholders are clear about the objectives, so that every decision you make can be aligned with the objectives, giving you a stable foundation on which to build a model of the product.

How do you know that the objectives are stable and valid? They should be inline with your strategy, which should be inline with your mission, which should be inline with your vision. If they’re not, then they’re likely to change, in which case you’ll base your entire estimate on the wrong decisions.

2. Understand the business goals and targets

How long have you got to reach break-even? How well do you know your target market? How well do you know the competition? How confident are you in your business model? How long is the window of opportunity for the product? What are the barriers to entry? Does the product need to prove itself in the market to secure funding?

Questions like these will drive the business goals which will drive the schedule of milestones that need to be achieved, so its important to have a good enough understanding so that you can create realistic road-map schedule.

3. Set a road-map schedule

For an unfunded concept, its likely that you’ll need to have a beta version out within 3-6 months, a limited release within 3 more months and a v1 release after another 3 months. The beta product will be validating the market and proving the concept and opening the door for further funding, so hitting the business targets is vital.

4. Estimate the available resource

Working backward from the schedule, there are two main factors: features and cost. You either let features drive the cost, or more likely, let the cost drive the features. A good rule of thumb is that the cost will be 7 x the development cost – whether you plan for this up front, or end up paying for it later with delays and maintenance issues or even worse – incorrect features that have to be rebuilt.

5. Work backwards to identify what can be achieved in each milestone

Once you know what development resource you’ve got, you can estimate what is feasible to deliver in each milestone. This part will take some real work to actually build a model of the product and use the objectives to identify what the key v1 features are and what is necessary to prove the product in the market.

If the numbers don’t stack up – then its a better time than ever to realise that the product is either under-funded, under-resourced, too big or you have wrong business model and either fix it, or not waste your time & money on it.

Its also important to remember that this is inception only, and once done, there is a valid go/no-go decision that needs to be made. The right answer may be to abort the product, or to proceed to the market proof stage. After 6-12 months, the product should have proven itself , so there will be another go/no-go decision. From here, the ‘go’ decision will need to have real funding behind it to commercialise the product and take it from ‘concept to profit‘.

The bottom line is: you’ll be making hundreds of decisions through-out this process, so its important that they are aligned with the objectives and to understand that everytime one of these decisions is changed, you are departing from your estimate, which is going to happen because you have to be agile and adapt daily, but you also need to be aware of how fast the initial estimate will become worthless!

Leave a Comment » | Business, Software, Vision | Permalink
Posted by Andrew