Bang for a buck.

Bang for a buck is down right old school. Or is it?

This is a pretty strait forward way to convey a simple but very complicated performance analysis. But what is it that is being citing in the claim "More bang for your buck". 

Microcontroller can be classified several different ways, among those the more common are:

1) Data bus width

2)Program addressing space and type(Rom,Eprom,Eeprom,Flash,Mram)

3)Data addressing space and type

4)CPU speed

5)Number and type of integrated peripherals

6)Power requirements

7) Price

8)Development tools

9)Hardware(electrical,mechanical,environmental)

10) Device maturity status and availability

This is no where near a comprehensive list but I believe most people will agree that this covers the majority of the factoring when determining a cost analysis. In fact those ten classifications could fill dozens of well written text books.

In the abstract it can be argued that "bang for a buck" is a performance gauge. But a performance of what? Surely this can not be used to predict the products performance so what is it that we are attempting to measure here? This is a very difficult question indeed. Perhaps we are attempting to quantify potential in the abstract. In this case it becomes evident that we are dealing with a problem of relation. This is in itself another problem. We can not make this a simple problem of relation between microcontroller and programmer. There are many other factors at play that must be address. Starting with the hardware. In order to achieve a high "bang for buck" figure it is found that the electrical, mechanical, and environmental characteristics must be of convenient terms. After all if the hardware engineer has to spend two years interfacing the microcontroller it is not likely to have a high "bang for a buck" ratio regardless of how attractive the other terms may be. The same holds true for the software side of the problem. At this point we still can not get an accurate gauge of what "bang for a buck" represents. Programmers do not magically conjure up software and teleport it to the chip. Development tools must be used in order to achieve such a goal. The development tools alone can make or break a project. With this I come to the conclusion that "bang for a buck" is a standard assumption that the acquirer is very experienced in the given terminology.

In this case "bang for buck" gauging works both ways.  For the experienced, a high "bang for buck" ratio is a positive number. For the in-experienced, this number will be negative. To me this seems to be common sense. The problem with common sense is that it is not that common.Thus the reason for this blog.  We will compare both sides of this argument.

First we will begin with the experienced side of the argument. The experienced hardware engineer has come to terms with a given manufacturers electrical, mechanical, and environmental characteristics. Everything is second nature to the engineer and projects zip through like the well oiled machine. The programmer, who has taken a liking to the given manufacturers choices of instructions and development tools - feels quite comfortable developing applications on the given device. The programmer has already been through all the woes of the tool chain and can solve most any problem without the blink of an eye.  This management wise tale gets even better.  Suppose the manufacturer develops a device that supersedes their previous product line. This new device is 100% backward compatible, contains ten fold the features of every term and costs half the price. Obviously this team has just hit the rhetorical lottery. 

Now we assume the worst position imaginable. Perhaps that of a start up who has just hired a complete team right off the university press. The entire teams combined project experience is perhaps half a year standard industry work time. This start up is very intrigued about the given manufacturers incredible new product line. They surely hit the rhetorical lottery. As do they buy into the device portfolio and set out to become the next high technology leader. Not long into the project problem begin to arise. The hardware is very strange and the company must invest in additional test equipment and consults in the field. The programmers are already weeks behind schedule when the first design spin rolls off the press. They aggressively work to meet their project deadline but subtle problems consistently stop the development as they attempt to understand this new technology. The development tool has its own problems which can only be managed with time. At some point the programmers manage to get their code onto the chip but it is not functioning properly. The problem is eventually traced back to a hardware issue known in the chip since the first silicon die and the hardware engineer is forced to revised the board. The small start up has already incurred great costs and they still have not met their initial goals. This story is a common story because it holds true for many start-ups.  Also understand that this start up was doomed from the beginning i had set them up for failure to accentuate the negatives of a high "bang for buck" The reality of this is that a start-up with properly management could in fact succeed even with a high "bang for buck" ratio. However, they could do so with far less resources should they stay in their element.

From this you may be able to make your own inferences.