A means of (ex)change ?
In part 1 we asked can money become means of change as well as a means of exchange?
In part two we learn why the answer is 'hmmm, not likely'.
ESG Money is a bit like a fenceless gate, too easy to walk round with standard money.
Take taxes as an analogy, we all know they are a collective good, yet still need a legislative 'fence' to enforce payment.
The Centre for Citizenship, Enterprise and Governance have carried out much research into this area. And were mentioned in this recent BBC Radio 4 Bottom Line episode . The founder, Oliga Taeed recognises a shortfall inherent in finance in valuing 'value' itself, as described in this whitepaper. One of their (many) iniatives is the Seratio Bank. The 'S/E ratio' augments the traditional P/E ratio with an S/E ratio or 'Social to earnings' ratio. The idea being that an 'Internet of ESG Value' can be created and traded.
This raises a dilemma, is it OK to trade moralism? Does putting a price on it create a conflict of interest? Seratio Bank takes the concept further with Seratio Assured Branded Coins (p20), with Women’s Coin, Carer Coin, Students Coin, Black Value Coin, City Coin etc etc. There's also the Blockchain Alliance For Good and the Transnational Transparent Procurement organisation enabling global supply chain provenance in an attempt to harness big corp purchasing power for good.
This is all a bit complex, a bit like using the Baanx.com fiat/crypto bank account.
So we're back to the tax analogy and hence the need for legislation. Saul Griffith in a clean economy presentation (49 min in) makes the argument that we are out of time to fight irreversible climate change, calling for a 'World War Zero'. One idea includes a 'forgiveness' of the oil and gas industry in return for their assistance in the transformation away from fossil fuels as they have the skills and size to do it. His Otherlab company is worth following.
As an aside, imagine if the 'World War Zero' effort could use mechanisms similar to the events leading to Hitler's 1933 Enablement Act, a kind of climate crisis marshall law (hmmm, maybe a thought experiment too far...).
Behavioural change programmes like smoking reduction (gradual price rises and graphic packaging images) take a long time to work - too long according to Saul Griffiths and legislation isn't quick either.
While corporate law has no concept of ESG as exemplified by this Alexandria Ocasio-Cortez interview of Exxon execs, it continues to undermine good behaviour.
A great Hidden Brain podcast discusses how the human brain's excellent leaning and communications skills make us more susceptible to fake news (aka gullable) than our less developed animal relatives. Maybe an anti-disinformation law should be high on the list?
Digital money and smart contracts can't usurp the means of change that is the legislative process.
Posted: Thursday 31st October 2019.
Author: Nick Thorne.
A guide for the non-techie tech entrepreneur (part II).
In the previous post, we discussed source code, what it is, why you need access to it, where to find it and how to ensure you own it. In the second part of this guide for the non-techie tech entrepreneur, we go into more detail on the software development process, tools and terminology, then review developer skillsets and how to find them.
As we learned, source code quickly becomes very complex, with e.g. Wordpress running to over 600,000 lines of code. That's a lot of text, especially when changing one character, adding a space or even opening it in the wrong text editor can break it in very-hard-to-diagnose ways.
Your developer will (should) be using a suite of tools to control the complexity, and a way of working called the 'software development process'. It is possible to go tool-less. It can even be a valid way of working for extremely simple, single person projects (less than a few hours worth of developer time). Beyond that, it's a recipe for expensive failure.
'The Joel Test' is a quick and easy way to see if your development team have the basics in place. Don't worry if the terminology unfamiliar. The key points are:
Source control; Bug/issue/task tracking; Specification; Testing;
Source control is part of the source code repositories we discussed in the previous post (Github etc). Every time a change is made, it can be committed to the repository. Each increment is stored as a 'commit'. Upwards of 40,000 of them for Wordpress and counting. All previous versions are are readily available, the idea being if you break something, it's trivial to roll back.
In a simple project, there is just one 'master' string of commits, or 'branch' to use the terminology. Projects normally use many branches with 'pull requests' to pull the changes from a branch back into the master branch.
It works like this:
1) An Issue is created, for example, "The colour of Hello should be changed to green". An issue can be anything that requires a change, so a new feature or a bug fix (and many other things).
2) It is assigned to a developer who will then create a new branch. She will call the branch 'change_hello_to_green'. She works away on this branch adding a private string of commits, not affecting anyone else until her update is tested and ready.
3) She then creates a 'pull request' letting the project leader know her change is ready to be pulled into the main branch.
4) The project leader tests it then merges it into the master branch for everyone to use.
Large projects will have many branches running in parallel. Sometimes this can become quite complex, needing to merge many updates back into the master in one go (a multi-way merge is not a lot of fun). The process flow is illustrated nicely by Github guides.
Bug and issue tracking quickly becomes a complex undertaking in a large project. It is more efficient (vital even) to use a tool to record, prioritise and monitor (ie track) the processing of issues. One example is JIRA, or for a more simplistic option, see Github Projects. Microsoft Azure Boards are popular too. Used correctly, these tools provide a clear 'dashboard' of project operations. Used incorrectly, they create a great deal of obfuscation and confusion.
There are two main approaches to running these tools known as Waterfall and Agile, here's an article explaining the differences. Which you choose depends on the technology and investment approach being used. Waterfall involves top down, up front planning. Agile is an adaptive, and structured prioritise-and-plan-as-you-go approach. Agile comes in two main forms, Kanban and Scrum, you can read more about them here or contact the author for more detail.
Specifications are important when building anything. Software is no exception. There are many different approaches to recording / generating them. One popular method is to use the user story process. Here's an example of a user story:
'as a user I would like to see Hello in green'
User stories may be very high level, or very low level, involving a lot of work or very little work. Turning the specification into a plan involves estimation, which one of the most error prone links in the software process chain. Often because it will depend on libraries or other systems that turn out to be poorly documented (anyone who has extended an old building will know the feeling).
A simple illustration of estimation error is the 'the LED will flash when a message is received' specification point where 'flash' turns out to be a 'sine wave variation in brightness' rather than on/off/on/off. On a resource constrained system, that's a big difference and very time consuming to pick up early.
Automated testing is very much a part of the modern software process. Tools like CircleCI (CI : continuous integration) are used to run a suite of tests every time the master branch is updated, or on a timer several times a day. These tools are hooked directly into the repository and run automatically detecting mistakes instantaneously.
While we are on the topic of automation. The final step of releasing the product is called deployment. Projects increasingly use auto-deployment pipelines. These should take human error out of the process of final release (and appropriate documentation). One example for Android development is this offering from Amazon Web Services .
We have touched on the basics of the tools and workflows used in software projects. We now move onto the process of locating people with the capabilities required to drive them.
Developing software is all about problem solving skills. Computing technology has mushroomed into many separate domains of knowledge and skill. If we take one of the oldest languages, 'C' (cue fond memories of poring over Kernighan and Ritchie's C reference book ) and one of the newest, 'Go', a C programmer can program in Go but will need extra time to learn the differences. On top of this, there are pre-packaged blocks of tools called frameworks. A good example is the Cocoa Touch framework used in iOS (Apple mobile) programming. It can take years to learn all of Cocoa Touch, and the framework changes significantly every year. Not only in features but also in size (and can even switch language from Objective C to Swift), so one developer could understand all of Cocoa Touch in 2011, but it's more common to specialise in a part of Cocoa Touch as time progresses.
To add more layers of complexity (literally), computer systems are built up in stacks. At the base is the hardware, so a CPU, RAM, hard disks, graphics cards etc. Next is the operating system (Linux, Windows, OSx etc). Then we have applications that run on top, like Excel or Word. In the web development world, there tend to be whole layered frameworks, with terminology like 'Laravel back end running on LEMP' with a 'VueJS/Bootstrap front end'. A programmer could specialise in any one of these layers. Or you could hire a 'full stack' developer who will have a reasonable amount of understanding in most of them.
Your team may have to start with a good full stack developer, and hire specialists as it grows. In order to scale, your full stack developer must be good at communication and delegation. So look for people who have been in growing teams. This is a great article detailing how to hire great people or 'A players'.
The final step is to find the team. There's no quick fix here. Typically only 10% of developers are looking for a job at any one time.
The options are: Word of mouth; Agencies; Direct application; Online communities; Freelance hiring platforms; Jobs boards; Offshore;
Word of Mouth works well, and is one reason for the rise of successful tech clusters (Silicon Valley, Cambridge, Shoreditch etc). With agencies, it's best to build up a relationship over many years. Direct applications are particularly good if your company is attracting great publicity (e.g. winning awards). Developers frequent sites like Hacker News, Stackoverflow, Reddit Developers, The Register and Kaggle (for data scientists) and many more. The right posting in these can work wonders.
Freelance hiring platforms work well for technical companies hiring in short term resource. Technical expertise is needed to specify/scope the task, then review the responses and project manage the chosen developer(s). Commonly used platforms include TopTal, UpWork, PeoplePerHour, Fiverr and Freelancer.
General purpose jobs boards like CVLibrary, Indeed, TotalJobs can generate much unnecessary work with poor quality responses.
Taking development offshore is a good long term option. There are many very good offshore development companies, but also many bad ones. Expect to have to try several before finding one that delivers, and manage that relationship actively. Delivering with an offshore team is not a foregone conclusion.
To sum up, we've taken a deeper look at how software is managed, specified, controlled and delivered followed by a whistle-stop tour of the various ways of finding and hiring developers.
If you have an existing project that needs management, are considering a new development, taking over a project from another organisation or have any more questions on building and running a great software team, please contact the author.
A guide for the non-techie tech entrepreneur.
In the 2013 ‘Project Oxygen’ study, Google found it's better to be more ’social’ than ‘rocket’ scientist when running technology projects. A point made time and again by the many successful non-techie tech entrepreneurs.
In the next two posts, we outline some of the more common bear traps that await the non-techie tech entrepreneur.
A rough table of contents is:
1/2  A look 'under the hood’ at what you need to know, plus what is ’source code’ and do I/should I own it ?
2/2  Common tools and ways of running tech projects, plus finding / managing techies.
So, on with part 1.
As a non techie tech entrepreneur, you will have delegated responsibility for your development to another person / organisation. You will watch with admiration as they tinker about under the hood to keep things ticking over smoothly. What exactly are they doing under there ?
If your company is pretty much a software only operation then your systems will be made out of source code . Quoting from Wikipedia, source code is
“.. a text file version of a computer program or software that contains instructions that the computer follows to do something".
So for example, the most basic HTML page would look as follows:
<body style=“color: red;">
Point your browser at this, and you will see just the ‘Hello World’ text in red (yes, much source code is in American spelling).
You may now be thinking, what’s all the fuss about, that looks trivial? So let’s take a look at the most commonly used website creation system, Wordpress. Under the hood, Wordpress is built using the PHP programming language. A lot of PHP. A quick and dirty way to measure the complexity of a software project is the ‘lines of code’ metric. Currently Wordpress has 690,000 lines of code. In May 2003, it had 11,000.
Wordpress is an 'Open Source’ project, so we have full access to the source code on Github. Github.com is a ‘source code repository’ service. Think of it as your own private 'Lock n Store' for your source code. There are many alternatives including BitBucket and GitLab.
The source code needs to be processed in some way to turn it into the deployed product. In the case of a mobile app, the developer loads it into a tool such as Xcode, builds it, tests it then uploads it to the App Store.
Without the source code, it is impossible to extend, maintain, replicate or update your product.
Don’t worry if this is news to you, you’re not alone, and it needn’t be a problem provided you stay with the same developers.
Where it does become an issue is when you need to in-source development or switch developers. No source code means starting again.
It is best to ensure you have source code access from the start. Do this by creating an account on Github (it’s free) and adding your developers to that account. Require them to upload any modifications they make as they go (at least daily). It is also a good idea to have an independent techie try and replicate the product. Source code is complex, so the developer will probably have missed out some parts, and the only way to find out is to try replicating it.
Often this kind of source code management arrangement hasn’t been put in place. So you will need to request the source code. This may cause the developer to fear they are about to be replaced. There are perfectly valid justifications for this request that should put their mind at ease. A good example is that you are creating a disaster recovery plan, and need all the source code to be securely backed up. Another is that a new customer requires ’source code escrow’ to guard against being locked out of your product should one of their competitors purchase you. There are many other good reasons for gaining source code access.
Once you have the source code, you may not have all the rights over it that you thought you had. The law states that the developer owns the copyright to their creation (as authors of it). Regardless of who paid for it. This is a great (US) article that sums up the problem. UK law is very similar. In summary, unless the development contract specifically assigns ownership to the client, the contractor retains ownership and associated copyright.
As in the linked article above, the problem may only become apparent when selling the company, transferring development in house or switching developers.
There are several strategies to mitigate copyright ownership, contact the author for more detail.
This post has explained what source code is, where it can be found and who owns it. In the next post we will cover the methodologies and tools that your techie staff should be using to manage and version your source code, plus a quick look at managing the techies themselves.
If you are concerned about any of the topics discussed, or would just like to know more, then please contact us for a free two hour review.
Posted: Wednesday 9th October 2019.
Author: Nick Thorne.
Also published on LinkedIn.
Money is worthless.
You can’t do a lot with that paper note or the figure on a banking app screen.
About as useful as the first telephone - who you gonna call ?
But others will exchange your note or 'app screen number' for stuff.
Quite useful after all.
But we can make money even more useful.
What if we can make our money into a tool to bring about change for good ?
This post is a technical thought experiment taking us one baby step towards that goal.
In February 2018, Yahoo finance started listing the ESG scores of companies in a range from 1 to 100.
At the time of writing, Marks and Spencer scores 75 (73, 67, 88) in total, which is above their peer group who are respectively at Tesco - 63, Asda (Walmart) - 59, Sainsbury’s - 67.
And if we want that coffee, MacDonalds - 58, Costa (Coca Cola) - 61, Cafe Nero - ?
So, we have a crude measure of ‘goodness’, how do we make use of this?
In February 2016, one of the challenger banks, Monzo published a brand new developer API.
An API is an ‘application programming interface' which means it’s like a socket that third parties can bolt things into.
In this case, there are two sockets of interest, the one that outputs details of your payment when you make a purchase, and another that lets you add an item into your Monzo app feed.
There is of course some processing that needs to happen behind the scenes.
One is cross referencing the merchant with their ESG score.
The other is to calculate the particular user’s cumulative ESG score. The diagram below shows the complete system.
And it works!!
However, there are some limitations. Firstly, do we trust the ESG scores? This agenda is being driven by and for the finance industry by large corporates like Sustainalytics. Some of us remember the credit rating agency conflicts of interest leading to the ‘great financial crash’. We must be cautious.
Then there is the issue of multiple item purchases. I might be in Tesco buying local in-season vegetables, or air freighted unsustainably produced asparagus. These individual items are not broken out into their respective ESG scores.
Small and micro businesses which are often local, independent and full and fair taxpayers will not have an ESG listing. We could find a way to crowd-source this data. Organisations like The Fair Tax Mark can help with this.
My first thoughts on this were posted on Twitter in early September. But the ideas stem from reading David Graeber's "Debt: The First 5000 Years" a few years ago, Eric Lonergan's Money, more recently Erik Thownsend's The Death of the Dollar and the Rise of Digital Currency and "Where Good Ideas Come From" by Steven Johnson.Simultaneously a closely related topic appeared on the Monzo forum.
This thought experiment is work in progress. We can go much much further with digital currencies. Suggestions welcome.
Can money evolve from a 'means of exchange' to a 'means of change' ?
Posted: Friday 26th September 2019.
Author: Nick Thorne.
Posted: Friday 26th September 2019.
Use the form below to contact us
Wessex House, Upper Market Street, Eastleigh. SO50 9FD