Coming up on paulbattisson.com….

July 17th, 2011 Posted in Agile Practices, Maths, Personal, Salesforce
No Comments

So it has been a while since I have written anything on here. I feel terrible about this and really want to be writing more regularly and sharing some of the cool things that are going on with people.

So what have I been doing all this time? My last post was in February and revolved around some of the Force.com features that I had found most useful in team based development. I made a short presentation to the Agile Yorkshire user group based upon this post that was fairly well received.  In one of those interesting moments of hindsight I am getting now, I honestly don’t feel the presentation was really that good and if I were to do it again I would completely rewrite it, but the presentation did encourage a few people to look into Salesforce and that is good enough for me.

At work I have moved onto doing some iPad and mobile development which has been exciting, culminating in the recent release of DATASHELTER Mobile for Salesforce. I am now working on other exciting pieces and look forward to releases and launches of these for you guys to see.

There has been some slow emergence of some open source projects I am founding and co-founding for Salesforce developers and users. One of these will be based around the premise of improving the ease of learning Salesforce development for both non-developers and migrating developers. We saw recently
with the hiring of Matsumoto-san that Salesforce is very keen to drive developers to its platforms and is aware that the strength of any platform offering comes in no small part from the way it interacts with and aids developers on it. A large reason that Microsoft were so dominant in the past 20 years is the way in which they looked after the developer community they had. We all remember Ballmer’s developer chant. It is evident that Apple and Android are destroying RIM and Nokia because their development platforms are easy to use. I think Salesforce realise this (and if they don’t they should soon) and as such want to try and help developers utilise the technologies they have in the best way possible. The hope is my little project can help this aim on its way.

Again, revolving around the world of work, we have started using the fantastic GitHub system and I have been given the enviable job of leading the roll out of this. I can honestly say I have never used a more consistently brilliant and quick system. [On an aside, I did try out the GitHub for Mac offering and its nice. It just din't do everything I wanted exactly as I wanted it to though and I did find myself grumbling at its speed and feedback occasionally. It will remain installed and updated, but only get used sporadically. The command line is much more fun anyway.] I have been coming up with a branching pattern and testing it to ensure it fits in with our development systems in the smoothest way possible and hope to start linking Git and Chatter together for our own internal reporting needs.

So I do plan on keeping this more up to date. I haven’t even mentioned the fact I have been playing with Ruby, looking into UX and Human Interface, getting back into some graphic design work and reading a lot into Agile development and complexity theory, Core Animation and re-reading the brilliant Pragmatic Programmer, Refactoring, Design Patterns and slowly working through The Art of Computer Programming. I have started looking at obtaining my DEV 501 status as well and whether I should renew my CSM, obtain a CSP or quit the Scrum Alliance all together.

So expect some hopefully exciting writings soon!

Read More

Thinking of Your Software Project as an Investment Portfolio

October 1st, 2010 Posted in Agile Practices, Maths
3 Comments »

Ward Cunningham in 1992 coined the term “Technical Debt” to describe something done (or not done) during the software development process which will require to be worked on in future, possibly at a higher cost. For example, I write a nice new class but do not do any refactoring or unit testing. In 6 months I do not touch this class before then having to use it in a new piece of functionality. Changing this class can then cause a myriad of problems for the system, and so I am paying a lot more for the work than if I had invested some time before hand.

I recently read a blog post Steve Freeman wrote entitled “Bad Code isn’t Technical Debt, it’s an unhedged Call Option”. I really liked this idea for a number of reasons. Firstly, it is a bit nicer to play around with mathematically (more on this later) and secondly, as his brilliant post describes, it is a far better analogy for what we are really talking about. I also like this viewpoint however because it counteracts the way we consider debt in western society. We see debt as something that is acceptable as long as it is managed, and we consider it fixed and managed. We can pay the debt of incrementally when we wish and there is a pretty (generally) small interest rate and linear growth pattern. This as anybody who has worked on a piece of software for more than one version will tell you is certainly not true of “Technical Debt”.

Whilst at university I studied a couple of semesters worth of lectures on financial mathematics and I remember learning about call and put options as well as their involvement in a portfolio (and stochastic processes in some situations). As is natural then, Steve’s post got me thinking, if technical debt is a call option, then what analogously is a put option and can we consider our software development project to be somewhat similar to an investment portfolio? (Here we begin to stray into some wonderful theoretical musings on software development as a complex non-linear dynamical adaptive process. But we shall save that for another day.)

Firstly, let us clarify a few things. The underlying asset I am describing here for our call or put option is effort, which we can measure in hours, story points, bananas or any unit of work that it takes to develop a piece of software. Obviously this itself is a loose concept, as the effort on a piece of work varies through the project lifecycle, but we will use it as it is a concept we can understand.

Taking a call option out on this is then a management process:

“Management will pay a premium up front (in terms of hours of testing for stability or extra documentation/customer support) to take out a call option on a piece of code, hoping or betting that the price of effort to work in that area has not risen too high if the option is exercised (they wish to work in that area with new functionality again).”

If such an analogy is true then we can use the notion of a put option to be the following:

“We pay a premium up front (in terms of effort spent refactoring, unit testing etc.) to take out a put option on a piece of code, expecting that the price of effort to work in that area will rise to make the premium paid worthwhile (effectively negated).”

If this is a correct viewpoint (which I believe is logically sound) then we can consider our project or work on a piece of code to be somewhat similar to managing an investment portfolio by buying a series of different put and call options to achieve the maximum return on investment with the minimum risk available. We will want to do as much work as possible in making the software stable and extensible later on (put options) yet we understand that there is always some risk taken when having any software.

I would love to be able to determine some sort of price for code smells (or use a rough story points estimate based upon some team values) to see how best a portfolio could be managed. I have spent some time already on paper messing about with this, and will hopefully sometime be able to jot something up here. I was also looking into modelling agile as a crude non-linear dynamical system, so don’t expect anything too soon ;-)

Read More

The Nooka Counting Systems

August 15th, 2010 Posted in Maths, Nooka
3 Comments »

I was recently contacted by a representative of Nooka (http://www.nooka.com) about a new nomenclature that their founder Matthew Waldman has devised. Having seen how cool his watches looked, I thought I would have a read through the materials they sent me, and delve into their new linguistic setup for the number system.

I have been sent images that contain the linguistic and representational systems for counting in both decimal (base-10) and duodecimal (base-12). Below is a discussion of each.

Decimal System

The image here shows the decimal system representation of the Nooka system. Notice that the same numerals are used to represent the numbers as in the “normal” decimal system; it is merely the linguistic terms that have altered. The system is very similar to many eastern systems (my knowledge of Mandarin Chinese informs me that it is very similar to Mandarin) in that to say a number you merely say the value of each column and the type of unit in it. For example, 42 is “forty-two” in English but “orenu” in Nooka decimal, which means four-ten-two. This is a far more logical and systematic system of counting and representing numbers linguistically than English as it describes exactly what the number is for you. It makes no difference to most mathematics as any sufficiently advanced mathematics (i.e. most of the field of mathematics) is algebra. However, when trying to teach a child how to do simple addition, they are told to put the number in to columns of tens and units and add up the values down the columns.

When trying to explain to an English child how to do this, you are often met with the idea of “fifty is five tens” being difficult for them to grasp as they have just learnt the term “fifty” parrot fashion as the number after 49 (i.e. the next value when you add one to nine in this case). A child having been taught Nooka (or Mandarin for example) would find this much easier to grasp as a concept. It is more natural to them to think of what a number actually is.

Another key feature here is the amount that you require to learn before you can proficiently count in a system. In Nooka’s decimal system you are required to learn 12 words and a simple rule in order to count to 999 (11 words and the same rule to count to 99). To count to 999 in English you need to learn 29 words, and there is no simple rule to describe where they come in order. This may not sound too bad, but consider the following. When a child learns to count, they will most likely learn the numbers 1 to 20 first. This requires the learning of 10 words and a rule in Nooka and 20 words in English. It doesn’t take a lot of thought to come to the conclusion that this has to be an easier way of learning the number system.

Honestly I am a fan of the linguistic setup of the Nooka system as I think it is a far more logical structure to naming than the existing systems. In my limited psychological opinion I think using a counting system with such a setup would likely improve the take up of mathematical concepts by children, however how we could test this is a different question entirely.

Duodecimal System

Below is an image showing the Nooka duodecimal system (base-12) and we can notice that there is a new visual representation for the numbers.

I want to start this discussion by saying that there are many mathematicians (myself included) who believe that counting base-12 would be much easier mathematically than counting base-10. It is fairly obvious as to why we count in base 10 (hint: look at your hands!). The reasoning behind base-12 instead of base-10 comes down to the number of factors of the base. The factors of 10 are 1, 2, 5, and 10 whereas the factors of 12 are 1, 2, 3, 4, 6 and 12. We count angles in multiples of 12 (360 degrees in a circle for example) as well as measure the passage of time and it is therefore a better system to use. If only we had been born with an extra finger on each hand we would be using a (slightly) more powerful number base as our default.

The naming for the Nooka duodecimal system is only slightly different from the decimal system, with the addition of “e” and “el” for 11 and 12. This is an improvement over the standard base-12 where the numbers 10 and 11 agree instead labelled A and B and 10 is used for 12 (to ensure that the system can be used for values greater than 12). Similarly to the Nooka decimal linguistic structure, this is very easy to use and makes systematic sense.

When it comes to the visual representation of the values, the Nooka system is runic although follows a logical pattern of adding markers to your number to display what number you have. The issue with this system however, is not that doing simple maths is hard, far from it, doing basic addition or subtraction would be easy using this representation, although one would have to learn some rules to be able to multiply and divide. The issue is the number of symbols used to represent some of the numbers. For example “orelor” which is only on the fifth row is already required to have 3 symbols, yet this is not a sufficiently high enough number to warrant this complexity. In standard duodecimal, the use of the 12 alphanumeric symbols implies that 143 in decimal is written as BB in standard duodecimal but requires 3 characters in Nooka’s system. Seemingly then trying to write a larger number like 353 in decimal goes from being 255 in standard duodecimal to a series of more than 3 characters in Nooka making it very hard to distinguish placement (I made an attempt and retrieved a 5 symbol number for this).

Conclusion

Both the Nooka systems are an interesting premise, to provide a universal linguistic system (and graphical representation) of the numbers in 2 different bases. The linguistic setup for the decimal system is I believe a very good idea. The logical structure provided would aid and improve the grasping of mathematical concepts by those learning it, whilst at the same time retaining the use of the standard graphical representation used worldwide.

The duodecimal system itself I believe has real promise but is unlikely to ever be used as the default due to our 10 fingers and 10 toes. As for the Nooka duodecimal system, I find the use of the runic symbols cumbersome in anything more than basic addition and this would lead to in actuality a restriction in the usage of what is a far more flexible counting system.

In closing, The Nooka systems are interesting, and the linguistic setup of the decimal system is for me a winning idea, but the big question is, why would I use that instead of something like Mandarin (or a tweaked version of Mandarin) which has already got an extremely large number of users?

Personal note, I am very grateful to the people of Nooka, Jon Patterson who contacted me and Matthew Waldman who designed the system for contacting me and asking me to look into their work. I would gladly help them in the future and found this to be a most enjoyable and interesting bit of side research.

, , , , ,
Read More