Pricing Models

Dennis was asking what pricing models people adopt

—

Price model:
Do You agree to ship solutions to one price no matter of the number of users or is the price related to a price / copy in use?

Do You offer a price all in for a solution or is it related to a hourly rate?
If related to hourly rate, does it exist any maximum top price or is it a running price?

—-

Me:

For smallish stuff (say under 10k GBP (20k USD)) I tend to go for a fixed price, which I modify based on number of users (ie potential ongoing support) . That would be paid part on proof of concept (POC), part on start of user acceptance testing (UAT) and the rest on live release. I haven’t tried to go for a separate support deal, but I probably will start.

For bigger or less clear stuff I tend to go for a day rate, I have also done a few support only deals recently, based on 3 or 5 days per month or whatever, on a retainer basis. These deals seem pretty hard to get though. Shame, as it seems to make sense for everyone.

I tend to base costs on a mix of the day rate I need to earn to feed the family, what the client is likely to pay, how critical the product is, likely support burden, and how busy I am. I wouldn’t normally go for a maximum cost number.

I tend to develop the high risk, complex and big win parts of a system first, which means I can hack out nice-to-haves if total cost or delivery date becomes an issue.

What about you?

If you are employed I bet you still go through the same process with your internal customers, so how do you play that?

Cheers

Simon

External data in spreadsheets

There are 2 common ways to get external data into a spreadsheet. Either via a worksheet formula with criteria, or via some refresh style command that sets cell values.

Essbase mainly uses the second, this overwrites cell contents with a value from the datasource. Essbase is pretty smart about it and you can intermingle formulas in some cells with data values in others.

Some other data sources provide a worksheet function like “GetExtData(…)” where you pass it some parameters and it goes off and queries the data source and returns a result. I think Excel 2007 has this for returning info from AS cubes (CUBExxx functions).

I’ve always been fairly neutral about which approach is better. But in researching my paper for Eusprig this year I came across a formula that was something like:

=GetExtData(…) + 180,000,000 + 5,968,364.

I.e. manual adjustments in the same cell as the audited ‘correct’ figures. The effect of this is that a ‘refresh’ may not be as thorough as some users might expect. My immediate concern is that those hardcoded numbers maybe a hold over from a prior periods reporting and be no longer valid. Thats not a theoretical concern, I have seen that happen in the real world.

I guess this could be avoided by effective build practices, but they would still need checking.

For me this ‘feature’ is enough to make this approach second best in my view, and I now think I prefer the ‘overwrite-cell-values’ approach (xlSet). I guess to an extent it depends on usage, if you are just reviewing your shopping list then who cares, if you are reporting billions of pounds to the regulator, maybe you need to be more concerned?

I see this as a spreadsheet builders choice thing, rather than a criticism of external data providers, I think most offer both options anyway. I’m thinking my advice in future will be to prefer the ‘set-cell-values’ approach for important data.

Do you have a preference? Or a good reason to prefer the formula based approach?

cheers

Simon

Excel forms

Marcus picked up the sense that I wasn’t overly impressed with Excel (Office) forms, and suggested I post about why that is. So no massive gems of insight or anything but:

1. Excel forms have a lot of useful events missing compared to VB. I really struggle to get the level of control I want because of this.
2. Excel forms don’t have control arrays which I find useful
3. General lack of control about look and feel.

And thats pretty much it, those are the reasons I prefer to use VB6 forms (well C# .net are my favourite actually – I like that its easy to make them semi transparent, and controls can be anchored for really simple resizing).

However the bigger issue is that I tend to use a worksheet rather than a form. I find worksheets very powerful, so it annoys me when I get some crappy list box interface that is so feature poor. I tend to use the forms controls too, not the activex ones.

If I use Excel for a system then I use as much of it as I can and I try to leverage the users skills in the product too. A good example of that is the index thing here, (the workbookstructure index sheet). I could have done that as a forms thing, and it would probably have looked more ‘professional’, but I did it in a worksheet so users can sort, edit replace, group etc easily using skills they already have. Of course it also saves me writing and testing code to do all that stuff.

If I do something that is mainly forms based I would probably do it in C# or VB6 as an exe, and automate Excel in the background.

I’m not convinced either is better or worse. It could be that I am just lazy and/or poor at user interface design, but I like to dress it up as using the product as much as possible. I also tend to use workbooks with code behind rather than add-ins in a corporate setting. Mainly because its easier, even though I have menu generators etc, and it makes it easy for the user to control the opening and closing. I tend to use add-ins if I’m doing something to the activesheet/wb, but little utilities etc tend to be plain workbooks.

Whats your preference (Forms engine, UI, add-in v wb) and why?

cheers

Simon

Broken client 2

Mrs smurf pointed out (gleefully) that she has earned more than me this last quarter. She works mornings at the local kids nursery!

So much for ‘Advanced Excel Development’ for feeding the kids!

My possible get out didn’t materialise so I’m just in the queue with the other unsecured creditors. But on the plus side I have a bit of free time to keep the blog up to date and play with the kids in their summer holiday. (during which Mrs S still gets paid of course, so the gloating won’t be ending anytime soon!)

Cheers

Simon

Code location

One of the great things about Excel/VBA apps is the ease of deployment. Either email the workbook or add-in and you’re done. (assuming your customer has Excel of course)

From a security POV that is not ideal, the code could be changed to subvert its intended use, it could get infected, and a bunch of other bad stuff might happen. I don’t ever recall an example, although I have seen infections from that crappy laroux VBA virus years ago.

From a management POV it can be a challenge too. Lots of different physical copies, how to check they are all the same if they should be? how to update when business requirements change?

One of the things VSTO offers is the ability to connect a workbook to some separate code that lives on a server somewhere. That solves many of those security and management issues, but at a cost of possibly more difficult deployment, less certain usage (eg if the server is unavailable).

So my question is, do you prefer the all-in-one VBA style, or the separate components VSTO style?

And, are they both valid and useful?

Personally, I think in general I prefer the all inclusive style, but I can see situations where a single code resource on a server would be miles better. Although if most of the logic is in the worksheet cells (as I think it should be in Excel based solutions) what you gain by centralising only a small part, may not be worthwhile. I guess this is where Excel Services steps in. But thats a topic for another day.

I find the possibility that VSTA (maybe?) in some future Excel version may offer us proper, compiled (ie a bit more secure than VBA, maybe faster???) embedded code quite appealing. Do you? or are you a ‘code-should-live-on-a-server’ person?

What do you think?

cheers

Simon

Office developer

What does that mean to you?

If I said I was an ‘Office developer’ what skills would you expect, which would you not expect?

Here is roughly my current assumption:

Expected knowledge

• Decent grasp of Excel and probably Jet/Access, maybe other dbs, developed over years of real world usage
• Maybe Word/PowerPoint/Outlook dev skill/experience, maybe not.
• Decent VBA skills to glue stuff together
• ability to pick up new COM object models pretty easily
• probably some relevant business domain knowledge.

Not expected knowledge

• Any Visual Studio stuff
• Any packaging/deployment stuff
• Any server based development

Yet I get the feeling Microsoft expect all of the above plus SQL server, plus Sharepoint, plus VSTO of course etc etc the list seems to go on for ever. Well except maybe the business acumen part.

I think the key point for me is that I see an Office dev as someone who has relevant business exposure in exchange for deep technology knowledge. They have experience of using Office to solve real business issues, before and as a part of being a developer. Do you see the business exposure as relevant?

Which of these would you call an Office dev?

Peaches, originally an accountant, good at Excel, copes in Access, decent VBA.

Fifi, degree in computing, exellent at C#, never used Office ‘in anger’, develops web parts for Sharepoint.

I’d say Peaches-yes, Fifi-no, but I suspect MS see it different (opposite in fact). If so, when did that happen? how come? What are those people that used to be called Office Devs now called (let me guess – amatuers?)?

Does this all tie in with the rather difficult (and ongoing) birth of VSTO? Because I’m sure nothing in Office itself changed to re-classify a bunch of people.

Do you agree or have I been left behind? (If so what other things did I miss?)

Cheers

Simon

Coding preferences

I was reviewing some VBA code someone else wrote recently. I always like to see how other people approach and solve development problems. I find that reviewing other devs code helps me think more deeply about the stuff I write.

One thing I have noticed in my code is that I rarely use

do ... while/until or
do while/until ... loop

(looping recordsets is one use, no others spring easily to mind) 

I almost exclusively use

For... next and
For each ... next

for all looping.

Don’t know if its force of habit, defensive programming (I like to find the end and check its reasonable before looping to it), just the type of stuff I do in VBA, or maybe just lack of imagination.

What do you do?

Do you find yourself tending to repeat the same mini designs?

do you have a preference?

Cheers

Simon

How much don’t YOU know?

Fantastic quote from a recent training course.

The trainer pointed out some clever trick, it can’t have been that clever because I can’t just remember what it was.

Anyway one of the delegates said ‘oh I didn’t know that!’

The trainer turns round – ‘of course you didn’t know that, and theres lots of other things you don’t know. In fact there is more that you don’t know than you do know. And it will be that way for ever.’

How true. Thanks Ty!

cheers

Simon

Excel and .net

I have a few Excel Add-in type tools in development on my laptop. These are written in VBA, VB6, C# and C++. I use them regularly on client assignments, but they are far too rough for more general release.

I hung back from the C++ option for years because there is quite a significant learning curve. I focussed on C# instead in the expectation that .net would overtake these ‘legacy’ technologies. I would class that as a massive strategic blunder (on my behalf), and have invested tons in C++ more recently to catch up.

Still now after the release of Excel 2007, xlls (ie C/C++ or Delphi) are the Microsoft recommended technology for Excel add-ins.

Its like the Visual Studio .net train left the station ages ago, and the Office folks are still at the ticket booth choosing what ticket type and what destination. VSTO seems to offer some promise of putting this right, I look forward to delivering working systems to clients with it, sometime around 2011 probably.

Like many software developers I have a dream to release software for sale on t’interweb and work from home in my jarmies. I went to a shareware conference about that a few months ago which was excellent. One very interesting point was the tools people were using roughly (by show of hands):

• 50% delphi
• 40% C++
• 5% .net
• 5% other

I was surprised somehow at .nets poor showing, even though I have reservations about using it myself. The general view at the conference was that .net is great for corporate developers, but that Microsoft currently offers no development tools for software vendors targetting broader hetrogeous client systems. Would you agree with that?

It seems from comments on the last post most people would agree with that assessment, and would recommend either 10 year old tech (VB6) or non MS (Delphi) over .net. I can’t help thinking our little corner of the market has fallen through the cracks in Microsofts market segmentation. That puts those of us wanting to extend Excel in a difficult place (either by accident or deliberate).

It looks like the .net dev opportunities are likely to be in the Excel Services world, rather than client development. That is a new and therefore risky market in my mind.

So my summary is:

.net is great for server dev work and for corporate dev work (after they have committed to the frameworks), not so hot for desktop work that targets varied clients. For that just the old tech is any good. Why is that? (is the desktop dead?)

Cheers

Simon

Technology choice

Following on from the recent post about who is the host I have a specific question.

I have an Excel add-in that I want to distribute. I can write it in any of the available technologies, and I am familiar with many of the issues around how to choose (there is some stuff on codematic about that). So without going into the minituae of how and when to choose XLLs over VBA for example my question is this:

Should I

1. write my app in VS2005 C# using framework 2.0, and be a part of the ecosystem that is driving more broad adoption of this framework?
2. Or write it in VS2003 against framework 1.1 because this is more widely distributed
3. Or write it in VBA or as an xll as these have no deployment pre-reqs?
4. COM add-in in VB6 maybe?(I know people with quite lucrative VB6 add-in businesses, even though it is approaching retirement)

I find myself in a catch 22. I would prefer to use C#2005, but I am concerned that the low penetration of framework 2.0 in my target large corporations will lose me customers. If I use 2005 then I may assist in the uptake and thus improve prospects for this technology longer term. In terms of the functionality of the product lets assume it doesn’t matter at all. I do believe that my target audience will be highly controlled environments, probably slow adopters. I remain unconvinced my product would have the power to drive installation of  a new .net framework.

Of course the big fly in the ointment is framework 3.5 (VS2008) which may be released before my product, thus fragmenting the market even further.

So what would your advice be from a purely business perspective?

I keep coming back to 3, even though I want to play my part in the ecosystem. Maybe I need to forget desktop and client development and jump on the server, software as a service band wagon, at that point there .net starts to make sense.

Anyone got an Office/.net product out there?

Cheers

Simon