Personal Projects

Most developers have them, an idea in the back of their mind for a project they'd like to write. Could be anything from a little utility app to automate something that they find tedious, through to the next big web 2.0/3.0 application that will change the world (or at least make them very rich). I know I always have a few that I've got on the boil from time to time. Mitch Denny has even gone as far as posting up some of his ideas. My biggest problem has always been finding the time between a fairly full on job, and a reasonably active social life, to sit down and make some significant progress on any of them. This in fact has formed part of my justification for taking a year off work and travelling to Argentina (for a full list of justifications see this post on our tangotrails blog).

I have been making some significant progress on a couple of my ideas over the past few months, and it has re-affirmed to me the professional value of having personal projects like these. The main project I've been working on is an idea to combine my technical side and my creative side. I won't say any more in this post, except that I want to see how far the web can push the way we experience the narrative form.

Because it is my project, and my idea I have full ownership over everything, good and bad. I have full ownership of the codebase, I have full control over the direction, over deadlines and milestones, I have full responsibility for testing and bugs, I'm even in charge of running a beta program (which I intend to do soon), and marketing the product. Legal issues, hosting provider, selection of tools, graphic art, everything is my responsibility, and mine alone. It has been a really educational experience to work on a project so fully from end to end, and not be able to assign parts of the application off that are "not my problem" to someone else. I am learning so much, not just about new technologies, but also some of the non-technical aspects of getting a project like this off the ground.

I think forward thinking companies should try to encourage these personal projects for their technical staff, even if the projects their developers want to work on don't wholly align with their business goals. I'm thinking along the lines of a company integrating personal project time into their staffs professional development plan. Something like allocating X days of your professional development time to a personal project. Of course you may need a project approval process, but this shouldn't be aimed at the business determining if the project is aligned with their goals, but more that the project is significantly challenging for the developer for her to really gain something out of it. Also, a short presentation of their work, in whatever state it is in after the allotted X days, would ensure the developer is kept honest, and that information is disseminated to other developers in the organisation.

I can see this benefiting this hypothetical forward looking company in a number of ways. For starters, I've seen a lot of developers get bored with what their business wants them to do on a day to day basis. Often developers end up in roles where the domain holds little or no interest for them, or if it once did, the constant focus on it destroys some of the enjoyment they once had. Focusing, even for a short time, on something completely different, that they are really interested in, will re-invigorate the developer. Also, having developers play with technologies outside of their normal sphere of day to day experience in the business, will make them a valuable asset if the business ever needs to consider any of those technologies in the future. Being able to advertise this approach to professional development would also attract the right sort of candidates when recruiting. A really forward thinking business may also be open to the possibility that one of their developers might just be creating the next big web 2.0/3.0 application and might even be willing to partner with them in an endeavour to commercialise it.

 

Technorati tags: Development, Professional Development, software

Pocket PC development connectivity issues

I have been returning to my roots and doing some Pocket PC development recently. I haven't really done that much since Visual Studio 2003, and to be honest, apart from SQL CE 3.5 which is a modest improvement on SQL CE back then, I feel like everything is pretty much the same. Emulators are slow, debugging is tedious, and device connectivity is sporadic at best. I was happily developing away when for no apparent reason I got the following error when trying to connect to my device which was happily Active Syncing,

Connection failed. A socket operation was attempted to an unreachable network.

I tried everything, disconnect, re-connect the device, shut down, restart Visual Studio 2008, even rebooting my laptop, I was still getting this error. Google was no help either, it appears to be a fairly generic, but seldom encountered winsock error not specifically related to Pocket PC development. What eventually solved my problem was performing a soft reset on the device.

Consultingware model thwart with inefficiencies

A large proportion of my career has been spent writing consultingware, and I've come to the conclusion that consultingware is inherently an unstable model full of inefficiencies and road blocks that can lead to an un-productive environment.

Let me explain the consultingware model. Consultingware is where a software house (lets call them the supplier) creates a package that satisfies 80% of a generic market niche, and then goes about selling to customers in that market, the base package plus consulting services to customise the remaining 20% to deliver a final product that the client requires.

This sounds fair enough, especially considering that there are many systems that would seem very similar, but because of the way the business is run, just require some tweaking at the end user level to make it fit straight into there current business processes. It is also attractive from the point of view of the supplier producing the consultingware, because although it's not the ideal model of selling bits of paper with license numbers on them (i.e. shrink wrapped software), if you find the right niche, you can charge big bucks for the initial package to each of your clients, and then continue to charge fairly lucrative consulting rates to customise the application because the client is essentially locked in to buying consulting services from the one supplier. However there are a number of inefficiencies and false economies that are inherent in this model if either the supplier or the client are not careful.

Let me start with the ongoing issue of code maintenance and improvement. Usually the supplier has spent a long time producing this base package with little or no financial support from any actual sales, and unless you have an absolutely brilliant development team there are always going to be code maintainability issues, performance issues, architectural problems, scalability concerns etc.... The shrink wrapped and internal development models have fairly well known processes for continuous improvement of code. The issue with consultingware is two fold.

Firstly the client is never interested in things they can't see. They are only ever interested in high level features that they can use in their day to day business. Even if they start to complain about things like performance, they are likely to be reluctant to fully fund the necessary development time to fix these issues considering they are only one of potentially many clients (current and future), who will see the benefit of these improvements. The same logic can also be applied to bug fixes, why should client A pay consulting rates for a bug to be fixed just because they were the first to see it and demand it be fixed. This leaves the supplier with the responsibility for these kinds of structural issues which creates a bit of a dilemma.

Inevitably if these kinds of improvements are done without direct funding from a client, this means that developers who could normally be charged out at the lucrative consulting rate become non-chargeable for a time loosing the supplier money. Not only that but if the changes actually improve developer productivity, (i.e. it makes adding features more efficient), the supplier will start to see a negative shift in their profit/feature ratio as developers start finishing chargeable features quicker.

Admittedly this is a false way to look at the problem. Ideally the way the supplier should look at it is that improving their own efficiency will make their clients more profitable and more likely to expand their business and hopefully require more of the suppliers consulting services as they grow. This is sometimes a very difficult argument to propose to bean counters when it is full of if's and maybe's and things that can't be measured easily.

The next problem is the way in which suppliers attempt to grow their product. They think that they will use their clients consulting dollars to add generic features to the product so that they can build a more out of the box solution for the next client (i.e. turn that 80% functionality into a 85% or even 90%) so that they can get more sales. This is problematic because the client again is really only going to be willing to pay for what they actually get benefit from, and to implement a feature generically so that all clients can use it, will inevitably cost significantly more than implementing it specifically the way the client wishes to do it. For example if Client A has a SOE that dictates everyone uses IE7, they aren't going to be interested in paying the supplier to ensure that the software works with Firefox, safari, opera, etc...

Another issue that frustrates the problem is the upgrade cycle. As more clients come on board, and more features are added, when clients upgrade, they take on risks associated with features they never asked for. This requires a very modular approach to adding features, but even still often changes to the core software are required to add new features, and this will impact on existing features.

This feeds into the final problem I want to discuss, and that is who is responsible for testing? I've seen a number of wrong approaches to this, including "The client will test it". I would suggest that any client that takes on a piece of consultingware needs their head read if they don't do some form of user acceptance testing. However, again, the client will really only be interested in testing the features that matter to them, and not being a software company, they won't really appreciate proper regression test cycles. Ultimately a proper regression test and defect fixing cycle is going to be left to the supplier, but if no client is willing money towards that cycle, it will very quickly eat into the "lucrative" consulting rate the supplier charges for additional features.

So I guess I've really just stated the problem here, and offered no real solutions, and guess what... I don't intend to... at least not in this post. I would like to hear how other people have seen these issue tackled from both sides of the fence (client and supplier), and in a few weeks time, I'll put together another post with what I think are some potential solutions to the problem.