05.01.08
Posted in Integration, c++ at 1:46 pm by Twm
In cell biology, a difference between prokaryotic cells (bacteria), and eukariotic cells (plants an animals) is that eukaryotic cells are compartmentalised into structures known as organelles.
The compartmentalisation allows eukayotic cells to participate in many more complex metabolic pathways than the prokaryotes, because some reactions require acidic conditions, some require particularly high concentrations of a compound which may be toxic to the cell as a whole.
One of the most fascinating of these membrane bound compartments is the mitochondria – commonly referred to as the powerhouse for the cell. The mitochondira enable the cell to participate in aerobic respiration (oxidising glucose to make chemical energy). What’s really interesting about mitochondira is that they have their own DNA, and replicate independently of the cell (dividing as the energy needs of the cell increases).
The widely accepted theory for the origins of the mitochondria is that a bacteria, which was capable of respiration, but not able to get a good supply of glucose invaded an early animal cell. Perhaps a small fraction of animal cells which did not attack the cell gained a small advantage from the boost in chemical energy provided by the parasite – and then through natural selection, a symbiotic partnership was formed. (in the same way as nitrogen fixing bacteria invade legumes today, allowing legumes to grow in plants devoid of nitrates).
To this day, the mitochondria retain their DNA, synthesise their own proteins and carry out respiration for the cell, but have become so integrated that they cannot be called organisms and could never survive outside of the cell. However their processes are compartmentalised so as not to interfere with cell and importantly so that the thousands of other chemical reactions in the cell do no interfere with its important processes.
Single chip
Cost is the chief driver for one chip – but people often underestimate the cost of modifying and maintaining a complex platform. Software asset reuse is massively important to a big hardware company though some are slower to realise than other that software is less malleable than it seems.
It is becoming far easier for an organisation to switch hardware than software.
If you now consider the differences in hardware between a mac and a pc, all the important bits are commodities, yet the OS software and everything built on top of those APIs represents a colossal body of work.
On mobile, there are only a handful of credible 3G signalling stacks in the world, and most of them targeting a particular OS with a particular compiler.
The effort to port to a new hardware platform is not a walk in the park, but as long as the host OS supports a particular CPU (with the same endian-ness), then most of the effort is spent on verification rather than porting.
Porting a signalling stack to a general purpose OS is fraught with challenges, and poses some interesting organisational challenges when it comes to verifying the system as a whole.
In an industry with a long supply chain company semico->OS->UI->partner delivery->Phone manufacturer->Operator. The only point at which the real-time characteristics can be fully verified is at the point that the product is fully assembled.
The hardware world tends to be fairly mature when it comes to estimating Fabrication costs, Bulk order of parts, Failure rates – and cost of returns etc. A $5 or $10 BOM cost reduction over hundreds of millions of devices is well understood.
The long term cost of being tied to a particular software platform however, is very hard to enumerate.
Software though in it’s malleable form, provides a canvas for infinite creativity which allows many solutions to be attempted before it is released and sets like plaster of paris.
One way of hosting a big s/w assets such as a signalling stack is to introduce an OS emulation layer/personality layer. Essentially this what POSIX does by presenting an arbitrary OS with UNIX like services. An RTOS personality layer provides a library of mutexes, threads etc. which emulate an incumbent RTOS such as nucleus. So long as the target compiler has no problems with the code, and the OS can provide the same or better real time guarantees as the OS it’s faking, then the single chip port can be realised.
The disadvantage of personality layer is that you need one for each OS, and each has to be carefully verified.
It’s also worth bearing in mind that real time programming/embedded programming is a distinct engineering discipline – often clouded by the fact that many developers who have written mobile apps classify themselves as embedded programmers. Which means that the skill set required to do the full integration is often is short supply.
Here are some examples of typical layouts:
- The first Symbian phone which I worked on had RTOS and Symbian running on a single chip (back in 1999). Series 40 devices tend to run everything on the RTOS, but “open” OSes rarely attempt to run signaling stacks.
- The iPhone is 2 chip. It has a 2.5g daughter board which could be switched for 3G without having to modify the main ARM11 CPU and peripherals.
- Freescale’s MXC reference design is single chip, but runs most of the signalling stack on a starcore DSP.
When you start adding real time multimedia, virtual memory paging (by nature indeterministic) and a product which is assembled from many many partner deliveries, it takes an enormous amount of effort to verify the integrity of an entire system.
In summary. One chip, one OS is not a synonym for “best solution”. I think the real skill is to consider when strong compartmentalisation is beneficial, and when it is an overhead. (without intending to stir up a debate about micro verses monolithic kernel designs….hows that going by the way?)
Permalink
03.05.08
Posted in Development, Integration, Mobile, Symbian, c++, carbide at 11:07 am by Twm
I frequently write test code which executes in a “text shell” test harness. This is the Symbian equivalent of running from the dos command prompt.
Aside from enabling the essential automation of unit and regression tests, a key advantage of a text shell test harness is that the emulator will boot in a few seconds rather than the excruciating minutes required for the full S60 environment. In the text shell, the edit->build->run cycle frequency is vastly improved when compared with running a full UI app.
For the emulator, Symbian has a fairly convoluted way of supporting this use case and I always forget what the correct options are. So I’ve documented them here for Symbian 9.x.
Read the rest of this entry »
Permalink
01.17.08
Posted in Development, Integration, Mobile, Treemap at 6:32 pm by design
Finally, in the last in my series of post on Treemaps. I bring you the ROM size treemap.
There are two ways of getting the data. On a pre S603.0 device, it was easy to generate a list of files on the ROM (the ‘z:’ drive). But due to platform security this is no longer possible from a 3rd party application.
The second way is to cross reference the log files generated by the ROM build processes. After a ROM has been build, the .log file contains a list of binaries and their size in ROM and the .dir file contains a map from the binary name to the file system.
So with the .log and .dir files in hand, a ROM size treemap can be constructed.
The following screen shot was generated on a development ROM with a large core image and small ROFS (read only file system) which together form the composite “z” file system.
The file names have been annonomised (sorry), but you can see the contribution of binaries verses resources etc. The files are coloured by file extension.
As a teaser – the largest binary in the top left of sys/bin is the webcore.dll.
Permalink
01.14.08
Posted in Development, Integration, Treemap at 1:43 am by Twm
Following on from the recent post on using Treemaps to visualise large code bases. I’ve made some improvements to the scripts and have successfully used the tools on the biggest code bases I could find.
I was having problems with the Treemap app failing silently with large data sets. A bit of binary chopping showed that the app failed as it’s RAM reached the default java heap size for the VM.
All is well if you run it with a 960MB maximum heap.
java -Xms32m -Xmx960m -jar treemap.jar
Secondly, I found it useful to filter out test code. And so I’ve updated the script with an option “-t” to skip any paths which include the word “test”.
And finally, I added a column which computed the code/comment density. Where 100% Means one line of comment for every line of code. Please see the subsystem screen shot below in which the brighter green represents a higher density of comments.
Permalink
11.29.07
Posted in Development, Integration, Mobile, Symbian, c++ at 3:13 pm by Twm
CLOC is a simple open source tool for counting the number of lines of code in a set of files (minus comments and blank lines).
Recently I needed to run a LOC count on a Symbian based code base to try to make a point about maintenance cost. I came up with a configuration which records the files I would consider code (including rss, rh, hrh etc) but ommits XML and things like SVG.
Read the rest of this entry »
Permalink
11.10.07
Posted in Development, Integration at 4:48 pm by Twm
Yesterday I attended the FogBugz seminar by Joel Spolsky at the British Library. FogCreek has a new release and naturally they want the world to know about it.
I like Joel, he adds value to the industry and has an incredible amount of energy. But I often thought that his larger than life character seemed a bit out of proportion to his product. I tried earlier versions out a few times and though there are some really nice touches, I couldn’t help but feel that this was a product ideally suited for people who create defect tracking software for a living.
(I particularly like Jira’s tag line “Jira : Because you’ve got issues”)
There is always a danger in assuming that all software development is the same. Yes there will be similarities – but why is it that every project feels that they are different and that a shrink wrapped methodology won’t work.
What I like about FogBugz is that it’s all about saving time, for both engineers and project managers. Even if the system doesn’t quite fit the bill – your engineers will not spend stupid amounts of time searching, duplicating info and filling in time sheets.
FogBugz 6 goes one step further than a defect tracking system by introducing the evidence based scheduling. Now a lot of people already do some sort of EBS (without the fancy name) in that they keep estimates and actual for a project and then use that to calibrate up and coming tasks or the data is mined in bulk when planning the next project, but in general tools don’t help.
In my experience, part of the problem is ‘billing time’ against a task is not a comfortable experience. There is a certain amount of guilt involved when an engineer is interrupts a task to make a phone call to the bank, or arrange an evening meal on toptable.com. There is also the other external interruptions by the boss or a colleague who feels the need to discuss in great detail how ‘crap lotus notes is”.
The resultant data is usually a database of lies, rounded figures and compensations. No one feels comfortable in entering time. Automating the process by having the user stop/start each time he or she is actually working on a task is never going to work either. If you forget to stop the clock while you visit the dentist, it’s just going to stress you out.
There is an old project management saying which goes “no matter what method you use – you put shit in, you get shit out.”
So, getting back to the point. I thought that Joel had something with his EBS. The tool deals sensibly with time recording.
- You use a drop down menu in FogBugz to tell it which case you are working on
- Fog bugs keeps a time sheet of all tasks worked on during the day
- At the end of the working day, it stops the timer and when you come in the next morning you just tell it what you are working on first thing and it starts the clock again (it knows about your holiday it will know).
- You don’t stop the timer for interruptions if you are interrupted
This doesn’t help for one tasks, but with enough data – the EBS algorithm picks random estimated/actual calibrations and applies them to your new estimates to determine the overall schedule. In Joel’s example- if you have a David Brent like boss who interrupts you all the time, then the your estimates will be calibrated accordingly since the EBS algorithm is more likely to pick a estimate/actual which contains Brent interruption.
I’ve yet to see how this actually works in practice but the thing I like the most is that even if it doesn’t work well, the amount of time wasted is minimal which is better than a beurochratic technique which manages to both not predict project ship date and add a hefty administration overhead to all invoved. The key to making it work is that it’s about providing a feedback loop to get the engineers to understand and improve their estimation skills – not because “the man” dictates.
A few issues I had:
- Along with a lot of people in the audience, I was uncomfortable with the lack of parent work packages. The flat approach means that tasks are assigned to the Project rather than a work group unit. Even though you can chop and change cases with filters, I’m sure that the flat approach makes people questioned the scalability of FogBugz to larger projects
- In reality larger projects will have more attrition than FogCreek (and more contractors) and so per-engineer EBS may be less effective (at least the defaults assume the worse for new employees)
- The estimator is not always the same person who will write the code. This is a fact in larger organisations -tasks can be switched at the last minute depending on “Show stopper” etc.
- The Wiki is all fine and good, but it adds another place to keep stuff. I can’t see many people storing their entire spec on the wiki. It is ideal however for “setting up your PC environment” and other How-to style documents.
And glossed over was how useful all of this would be in “the crunch” phase. When your engineers are spending a few months just fixing defects:
- Joel mentioned that time of defects should be charged back to the original task. But frequently defects pop up which expose latent problems in really old code for intance – who do you charge this time to if there was no original task on the system.
- Triaging – An awful lot of time is spent on working out who’s problem a defect is. Once the bug is isolated to a component the fix might be applied and released quite quickly. Do you really want the engineer of that component to take the full hit of the defect by charging the time to that task.
To be fair, Joel said that this tool was useful for the development part of your project. But it seems like a cop out. I would like to see more information about how it deals with the above questions.
Summary
So all in all, very interesting stuff. I really hope it helps raise the bar in well though out issue tracking and management software, and in summary, for small-medium sized projects you could do a lot worse than FogBugz. I can’t wait for the results of the EBS in the real world.
Permalink
10.18.07
Posted in Development, Integration at 4:16 am by Twm
I’ve been trying to keep up with the iPhone unlocking stories that seem to have popped up almost daily on the various tech news sites. I especially liked the story about a teen that was proud of his unlocking achievement but his friends said he had wasted his summer. It’s quite fascinating to see the different methods and breaking and entering said device, but I’m more interested in the whole question of the cost benefit of openness.
Read the rest of this entry »
Permalink
10.08.07
Posted in Development, Integration at 12:03 pm by Twm
Branching of code occurs when an organisation or individual make a change to a code line, causing two or more distinct code line points which can be called the head revision of a piece of software.
The definition above is not perfect distilation of a branch, as there are some ambiguities, but it will serve well for the rest of the discussion.
Branching is an incredibly important mechanism for creating code stable enough to ship products, while allowing future work to continue at a decent rate. It doesn’t always allow future products to steam roll ahead since (depending on project structure) the developers often have to spend more time doing product maintenance than writing new code.
In this treatise; I discuss supplier release strategies, and go on to distinguish the term “Fork” as a seperate type of branch which a customer may create in certain situations. Finally I discuss the costs associated maintaining a Fork, especially in a climate of Frequent releases.
Read the rest of this entry »
Permalink
10.03.07
Posted in Development, Integration, Mobile at 9:14 am by Twm
The Quick fix is a well established part of software development, and every engineer has done something in a hurry, under pressure, which bites back in a few weeks when the next level of testing reveals a flaw, regression or worse, they fail to spot it and a customer finds the bug.
Gaffer tape is not good. If we were talking automobiles, a plant manager would never let a car out of the factory with gaffer tape holding the wing mirror or the indicator on, even if the vehicle passes its MOT.
Software is different, it’s not a physical entity – without looking through the code, and you can only see the effects of the code.
On a large piece of integrated software, it’s impossible to test every combination of software variable and so the test has to be constructed well enough to cover every feature to spec, and an important subset of all the possible concurrent use cases.
When a solution is ready, this is the time to write the test case to go with it, get the test and the fix peer reviewed and sleep on it and submit the next morning.
Sometimes it makes more sense to write the test case first, especially if the defect is hard to reproduce, but has obvious cause.
Projects which make a distinction between fix and fix + test code should be weary. Those worried about the extra time taken to write test code should consider the extra time injected later on the whole process of test, triage and resolution has to be applied the next time, or when a follow on fix to the same component causes a regression to a previous fix because the test code isn’t up to date.
The quick fix is like peeing your pants. At first it’s all warm and great and you feel good, but when it goes cold- man your realise that it just wasn’t worth it. (Thanks for that quote Matt).
Permalink
