As I've mentioned in my previous posts I've become interested in the role of marketing in software companies. One area that crops up is something termed the M/E ratio (Marketing/Engineering Investment Ratio). Essentially the premise is that your company is more successful if you have more investment in marketing than in Engineering. OK, maybe that is true...maybe. However, whenever I dig a little deeper I seem to uncover some "interesting" points;
1) The "proof" seems to involve surveying companies that have succeeded and failed or as the reports state, the 'super successes' and the 'flaming failures'. I'm not sure I buy this proof. Lets take a look at a couple of well known names in these reported flaming failures; Xerox, Wang and Lotus. For me the suggestion that these companies failed because of their M/E ratio is be taken with a large handful of salt. I can certainly remember Lotus (of 1-2-3 fame) and their marketing was pretty slick, indeed at the time I was employed to investigate and implement a new office system for small database company. I chose Microsoft Office over the Lotus offering because of my technology investigation not their lack of marketing. I was invited to their offices for a demonstration of the products. Simply put the Microsoft offerings (mainly because of the close ties to the Windows OS) were easier to use (if only that were still true) and were quicker to utilize new OS features. So was it a marketing failure that caused Lotus to fail? I don't believe so because the feature set was almost, and maybe even 100%, identical. It was the implementation of those features that made me choose MS and it was probably the same story elsewhere. It's also interesting to read the number of excuses that Microsoft win because of their marketing muscle. It's equally interesting to read a number of articles debunking this as simply an excuse, indeed a number of cases point to Microsoft having poor marketing.
2) With terms like flaming failures and super successes, who is it that popularize this theory? Oh yes it's marketing companies. No surprise there but I certainly don't blame them.
3) 'Lies damn lies and statistics'. Statistics are a fun area. I was unfortunate enough to have to do 'further statistics' course and hated every second it, why, because I soon realised that you could pretty much put any spin on a topic by carefully ignoring salient points. I realise that marketing isn't sales but the ability to apply spin is a shared talent. Unfortunately I don't have access to any of the data in these reports but I'm pretty sure there are some important issues that have been ignored. For example, it is simplistic to say that the top x software companies have a high m:e ratio because the statistic ignores the scale of the company both in terms of number of heads and the Return on Investment (ROI), i.e. a small company can make a relatively large profit with a tiny m:e but they'll never break into newspapers top 100 company list.
4) Staff type thresholds - I don't have *any* research to back my next claim but it seems logical to me that a successful software company needs a number of people developing software, I don't like the term R&D it's too woolly for me. I also believe that as a company grows there becomes a critical mass of developers where adding more developers isn't a good ROI, in-fact it encourages the command and conquer model and removes some of the best developers from developing. So lets take another look at some the poster software companies. The IBMs, Oracle and Microsoft's of the world require a huge army different staff types to produce and sell their products. (It has been noted that a number of people that leave Microsoft to form start-up's fail because they underestimate the "behind the scenes" support staff that are needed). A proportion of staff will be developers and a proportion will be in marketing (or at least the proportion of the costs if not head count). With my theory of a critical mass of developers then I would expect that in these large companies the number of developers will have plateaued but the ever expanding world wide customer base will require more and more marketing effort. So by examining these companies m:e then you would see a large m to e, again statistics can tell whatever story you want if you ignore the whole picture.

So back to the heading of this post, is M/E a lie? You've heard my opinion, I don't have a great deal of research or a diploma from Harvard Business School but I hope my little investigation and logical thought will be enough to at least make the reader question the "truth" of these M/E reports.

Another issue I have with placing too much emphasis on "Market Driven" is what does it actually mean? Who is your market? A market, in this context, is all of your existing customers plus all your potential customers whether they or you know it or not. In other words your customer base. I don't believe anyone would agree with that as a definition of Market Driven. What Market Driven actually means is Market Analyst Driven (MAD). I'm sure such an analyst would argue that they do indeed represent all the custom base but it's their job to guess what a market wants, they don't know. How do I know that? It's simple really, if they were sure of something they'd do it themselves! I was talking with someone pretty high up at Microsoft and we were discussing market analysts. They told me a story about one particular well known analyst who published a paper misrepresenting a Microsoft technology. So they were invited to a Microsoft seminar and admitted they didn't know the product and was forced to publicly amend their review. I'm not writing this to bash analysts, but what you have to realise is that these are simply the opinions of people that believe they understand your market, they don't actually know and they do make mistakes. The emphasis of my high-school history class was to always qualify your sources. This leads me back to my conclusion from part 1, your should make decisions based upon a collection of sources not just one, and don't assume that any of those sources will be 100% correct.

I don't think many people will disagree with the practice of adding unit tests and striving for 100% code coverage. However, I think there is a very real downside to it. It wasn't so long ago that I was faced with making a change to some code that had zero unit tests and a fair amount of coupling. I hated making that change and it was the coding equivalent to treading on egg-shells. After a period of refactoring and creating unit tests the story is better...or is it? I no longer have such a fear when it comes to changing that code, I know that even if I don't find the correct unit test to run the continuous integration process will run it and complain if there is a problem. However, I am now faced with a different dilemma, every code block I add I need to create a unit test for it. There is no escaping the fact that it does take some extra time to write the tests and it does impact on the here and now. Of course I will write them because it will be better in the long run but my real fear is that you start to code differently because subconsciously you start to avoid doing things that require you to write extra tests. Consider this very simple example of checking an age...

totalAges = newAge + currentTotal

Now really I should throw a specific exception if the age is negative...
if newAge < 0 then throw new AgeNotValidException
but if I do that I'll need to write another unit test to ensure that this exception is raised. The little devil on my shoulder says, "but that's not likely to happen is it, no need to do that, it's not in the specification, why add it, look at all the other code you've yet to write, etc, etc". It is a matter of pride in your work and ultimately you should always do the right thing, but I can't help feeling this is like red-tape. I wonder how much Test Driven Development dynamic language developers will use?

Well the use of the off-line keyboard map seems very positive via ToUnicodeEx. It took me ages to realise that I'd got the Virtual Key and Scan Code values the wrong way around (doh!). I hardly spent any time on it, but my final test correctly displayed an accent from the Virtual Key of Tilde. Given that ToUnicodeEx takes a keyboard layout (or was it locale?) as a parameter then I'm confident this should at least provide fair stab at a decent keyboard translator.

Yesterday I was asked, "the application isn't sending out emails, what is wrong?" The simple answer was, "you've installed McAfee Antivirus". The default installation this AV is to block the SMTP port, nice.

I'd like someone to do an impartial review of modern "protection" software. I recently read a review in MacUser about the hype of threats and I'm beginning to come around to their point of view. It's not that I don't see the value of such monitors but in my experience this particular tool seems almost as bad as the threats it reports to stop, I'll explain why. What is the threat of a virus? Well there are many privacy related issues but for a modern company behind a hardware firewall I believe the two main risks are; Trojans and denial of service (DoS), both often resulting in a large amount of downtime to repair.  A Trojan is a risk as it could send important details to a basic HTTP site and could be very damaging, so I want my OS/Virus checker to stop things changing/installing executables (DLLs, scripts, et al) without my permission. DoS - where naughty software is doing something for its own gain (spamming) or just bringing a system to its knees for "fun". For DoS I want my OS/Virus checker to stop things changing/installing executables (DLLs, scripts, et al) without my permission, sounds familiar. Modern virus checkers do this so what is my issue? I wouldn't have one if that is all they did. No they go the extra mile, they turn off useful ports (see SMTP above) without asking me, they inject script to help ensure scripts I run are ok (and those scripts then cause failures), they double check every file that is read (yes read as well as write). Not only that but one version (the one with lots of yellow) they can install loads of odd software and services I didn't and don't want - but can I get rid of the sub parts, nope.  Essentially the modern Virus Checker is one of the slickest DoS and Trojan installer you're willing buy and install. DoS from a virus checker is no laughing matter. I regularly compile large projects and you can easily see the significant difference in speed with the checker on and off. So if I was to add up all the time lost in these minor DoS attacks from the checker against the number of infections * time to rebuild PC/PCs infected I wonder which would be worse? Now it doesn't have to be as black/white as that. As I've said, if my checker simply attempted to stop nasty code getting on my machine then I'm pretty certain I would have a machine that does its day-to-day tasks efficiently with a very small chance of having nasty code installed.

I guess the moral of this story is choose your AV software carefully, consider what you deem to be an acceptable threat and learn the mantra, "options exclusion is your friend, options exclusion is your friend".