Innovation is a choice

There’s nothing like a week in another city to get the innovation juices flowing, and London Fintech Week was exactly that (thank you Luis and team for another week of great debate, networking and insights).


There’s nothing like a week in another city to get the innovation juices flowing, and London Fintech Week was exactly that (thank you Luis and team for another week of great debate, networking and insights).

So, what is new in the world of Fintech? Well, if the speakers and panelists are to believed, and the messages were far too similar and consistent for them not to be…

…AI is playing an increasingly important role in the world and indeed in the world of banks – …  . It is clear that to win in the investment banking game will still require smart people – but we must couple smart banker types with AIs and we must change our definition of “banker types” to include engineers and mathematical PHDs.

…Blockchain is here, and it’s all grown up. No longer a concept for alternative funding and the underworld, the cryptocurrency conversation is upping the volume at the highest levels with countries like Canada, the UK and Singapore all running projects, and banks of all sizes experimenting and building applications both in crypto-coins and blockchain technologies. Even the highly volatile crypto-currency prices over the week did nothing to dampen the enthusiasm. With the rise of open source, I expect we will see increasing opportunities to move from our existing centralized models to new blockchain enabled ones in many economies and industries.

…Trust is no longer about relationships, nor the strength of your brand. It’s about ease of use and, increasingly, peer review. Customers are no longer seeking a similar experience to the one they get from other banking brands, they’re looking for an experience like they get from the mega brands like Apple and Amazon. Banks are going to need to up their game – and quickly!

Clients know that if they are not paying, they are the product. Both banks and clients know the power of their data – what will this mean in the future? How will this change their expectations of service? Security now becomes as important as service; will clients demand due diligence of their service providers to ensure that their data is secure?

…Innovation is a choice – it doesn’t just happen. This is potentially the most important message of all. Entities that are leading in the start-up and innovation space are choosing to  – they are seeing the possibilities that innovators bring and are finding creative ways to enable them. The innovation choice is being made at the highest level – countries like India, Canada, the UK, Germany, the Netherlands, and China are all facilitating innovation communities and the start-ups and banks coming out of those countries are moving faster than others because of it. It is a choice because there are millions of reasons and costs involved with creating change, but forward-thinking leaders recognize the importance and their choice to enable, means they are leaping ahead.

…It’s organizational cultures that will make the space for innovation and those cultures look to leaders for the messages they need. Coincidentally, I just finished reading “Under the Hood” by Stan Slap where he describes how to maximise business performance. Culture understands leadership motivators beyond words and culture works exceptionally hard to protect its own existence – so innovation will simply not happen without leaders giving the right messages. Innovation is a choice leaders have to make and their actions will send the clear message.

Everything we know, the way we work and the way we behave was all once created as a leadership or cultural choice. In this exponential era, we will need to change the stories we tell, the way in which we work, the technologies we believe in. It’s ridiculously exciting – and it’s moving…well, exponentially! At last years’ event, there was talk of what blockchain is and what AI could conceivably do, this year it was all about what businesses are being built on these technologies. I can’t wait to see what the next year brings!

by Liesl Bebb-McKay


An Ode to the Weird, and how to manage them

Naked, he ran through the dark streets of Syracuse. His damp footfalls and shrill screams echoing off the Sicilian architecture. While the footfalls have been forgotten, Archimedes’ alleged cries of, “Eureka!”, are still synonymous with the theory of displacement nearly 2,500 years later. Wow, he must have been a weirdo to run screaming through the streets, but undoubtedly a genius weirdo.

Naked, he ran through the dark streets of Syracuse.  His damp footfalls and shrill screams echoing off the Sicilian architecture. While the footfalls have been forgotten, Archimedes’ alleged cries of, “Eureka!”, are still synonymous with the theory of displacement nearly 2,500 years later. Wow, he must have been a weirdo to run screaming through the streets, but undoubtedly a genius weirdo.

Henry Ford was renowned for his love of carrots and once sponsored a 14-course meal with every course containing carrots. Thomas Edison, once deliberately and macabrely electrocuted an elephant called Topsy, and let’s not even address Albert Einstein’s choice of hairstyle.

Aristotle once famously stated that, “there is no great genius without some touch of madness”.

But, if this is true, how can the madness/weirdness be appropriately ‘managed’ to benefit from those who are able to see the world through different eyes and bring innovation to the corporate space?

The first thing to note is that trying to overly control a creative genius, using the same rules and policies that have been applied to the rest of the corporation, is going to ensure that you stifle any potential for positive disruption. This is not to say that rules, policies, and that demonised word, ‘governance’ do not have a place, but rather that they should be appropriate for the required outcomes, not just a generic ‘one-size-fits-all’ approach. For example, if you expect your creative geniuses to deliver quickly and maintain momentum, don’t force them to use archaic procurement processes that require completion of forms, in triplicate, with 17 signatures each. Tell them what needs to be achieved, but don’t tell them how to do it.

Next, you need to make them feel valued. It is an unfortunate reality that creative geniuses often come with an oversized ego. But this should be acknowledged, rather than ignored in a vain attempt to contain that ego. If not, they will leave the organisation.

Arguably worse than that, they may stay, but their spirits will leave, which only results in a chair being occupied, but very little more than that. If you think a genius with a large ego is hard to manage, try managing a disengaged genius, or moreover a genius hell-bent on exacting revenge on an oppressive manager. Give them the freedom to experiment and the opportunity to truly see their ideas fly.

So, in summary, you need to control that which does not like to be controlled. Easy, right?

Actually, it can be, just ensure there is a clear vision of the end state and the bare minimum of rules to support that. After that, just let your creative geniuses feel valuable. And, let’s face it, if they are geniuses then they are indeed incredibly valuable to the future of your company.

by Brad Carter

A curriculum for growing your data science skills (almost) for free

With the plethora of free (or at least reasonably priced) high-quality massive open online courses (MOOCs), free online textbooks, tutorials, the tools available for aspirant data science apprentices are many and varied. From taking courses offered by Coursera to freely available eBooks and code examples to download from Github, there are many useful resources at our disposal.

I hear and I forget. I see and I remember. I do and I understand – Confucius

With the plethora of free (or at least reasonably priced) high-quality massive open online courses (MOOCs), free online textbooks, tutorials, the tools available for aspirant data science apprentices are many and varied. From taking courses offered by Coursera to freely available eBooks and code examples to download from Github, there are many useful resources at our disposal.

Demand for data science skills remains consistently high. IBM predicts that appetite for data scientists will grow 28% by 2020. Job postings for data science skills in South Africa are rising rapidly as companies begin to realise the true value of their data initiatives.

According to IBM, the current most desirable and lucrative skills include machine learning, data science, Hadoop, Hive, Pig and MapReduce. It is interesting to note just how many data engineering type skills are in demand. I recently started to set up a data lab at the Foundery based on the Hortonworks distribution of Hadoop, and I can understand why this is true – (big) data engineering is unnecessarily complicated!

Over the last few years, I have completed (and sometimes part-completed) some data science MOOCs and tutorials. I have downloaded free eBooks and textbooks – some good and some not so good. These, along with the MOOCs, have become my primary source of knowledge and skills development in the data science domain. I am finding this form of online learning to be a very efficient and effective way to grow my knowledge and expertise. However, my choice of which courses to do has been haphazard at best and having this much choice has also made it difficult to find the right courses to pursue, often leading to me abandoning classes or not learning as well as I should.

The purpose of this blog, therefore, is twofold: to create a thoughtful and considered curriculum that I can follow to elevate my data science mastery and to share with you some of the resources that I have collated in researching this proposed curricula. Whether you are a seasoned data science expert, or an absolute beginner in the field, I believe there is value from some, if not all, of the topics in the curriculum.

sourced from

The ultimate ambition of completing this proposed curriculum is to vastly (and more efficiently) improve my mathematical, statistics, algorithmic development, programming and data visualisation skills to go from a journeyman level understanding of data science to full-on mastery of advanced data science concepts.

I want to DO so that I can better UNDERSTAND. Eventually, I’d like to understand and implement advanced machine learning and deep learning concepts (both from a theoretical and practical perspective) as well as obtain more in-depth expertise in big data technology. I also aim to improve my data visualisation skills so that I can have more impactful, interesting and valuable discussions with our business stakeholders and clients.

The day that I can have a debate with my maths colleagues about advanced mathematical concepts, compete with the computer scientists on Hackerrank coding challenges, run my models on a big data platform that I have set up, create a beautiful and insightful visualizations AND make this all understandable to my wife and daughter is the day when I know I have been successful in this endeavour.

I proposed this curriculum based on the skills that are commonly acknowledged to be required for data science as well as on course ratings, popularity, participant reviews and cost. I have tried to be as focussed as possible and my thinking is that this is the most efficient plan to get deep data science skills.

This curriculum will be based on open-source programming languages only, namely Python and R. My initial focus will be on improving my Python skills where possible as I want to get this up to a level where I can implement Python-based machine learning models in NumPy/SciPy. I do acknowledge, however, that for many of the stats and maths related courses, R is often preferred and in that event, I will switch.

Given my work commitments and the fact that we have a new (and very loud) addition to our family, I think that I would likely only be able to devote 10 hours a week to this challenge. My proposed timetable will, therefore, be based on this estimate. The current estimate to fully complete the curriculum is at 110 weeks or just over 2 years! This is going to be a long journey…

I plan to update this blog periodically as and when I complete a course. My updates will include a more detailed summary of the course, an in-depth review and score, how much it cost me as well as tracking how long the course took to complete relative to the advised timeframe provided by the course facilitators. My time estimates will be slightly more conservative relative to the time estimates for each course as, in my experience, it always takes longer than suggested.

Thank you for reading this far. If you wish to join me in growing your data science skills (almost for free) and help keep me honest and accountable in completing this curriculum, then please do read on.

Data Science Curriculum

0. Supplementary resources and setup

Sticking to the blog’s theme of finding low-cost resources for this curriculum wherever possible, I have found a few high-quality free online maths and stats textbooks. These will serve as useful reference material for the bulk of the curriculum. They are:

  • Think Stats – a freely downloadable introductory book on Probability and Statistics for Python. Code examples and solutions are provided via the book’s Github repository.
  • An Introduction to Statistical Learning with Applications in R – another freely available book that is described as the “how to” manual for statistical learning. This textbook provides an introduction to machine learning and contains code examples written in R. There is online course material that accompany this book and this can be found here as well as here. I will use this manual and potentially their associated MOOCs as a reference when I begin the machine learning component of this curriculum.
  • Introduction to Linear Algebra is the accompanying linear algebra reference book for the MIT Open Courseware MOOC. This book will also have to be purchased should the MOOC require this.
  • Although not free, Python Machine Learning by Sebastian Rashka has good reviews as a reference book for machine learning applications in Python. The book also has an accompanying code repository on Github.

1.  start by focusing on maths and stats

The first section of the curriculum will allow us to concentrate on redeveloping fundamentals in mathematics and statistics as they relate to data science. University, over a decade ago now, was the last time I did any proper maths (yes, engineering maths is ‘proper mathematics’ to all you engineering-maths naysayers).

Regarding learning the mathematics and statistics required for data science and machine learning, I will focus on the following courses.

  • Statistics with R Specialisation – There were many courses available to improve my stats knowledge. Ultimately, I settled on this Coursera specialisation by Duke University as it seemed the most comprehensive and the textbook seems a good companion book. This specialisation comprises 5 courses – Introduction to Probability and Data, Inferential Statistics, Linear Regression and Modelling, Bayesian Statistics and a capstone project written in R. Each course will take 5 weeks and will require 5-7 hours of effort per week. I will use this set of courses to improve my R skills, and I will audit courses if possible or I may have to pay for the specialisation. [Total time estimate: 250 hours]
  • Multivariable Calculus – (Ohio State University) referencing the Multivariable calculus sections of the Khan Academy where required. This highly rated course (average rating of 4.8 out of 5 stars) will provide me with a refresher of calculus and will take approximately 25 hours to watch all the videos. I think I can safely add the same amount of time to go through all the tutorials and exercises putting the length of this study at 50 hours. [Total time estimate: 50 hours]
  • Linear Algebra – (MIT Open Courseware) referencing the Linear Algebra sections of the Khan Academy where required. I don’t know how long this should take to complete, so I will base my estimate on the previous courses estimate of 50 hours. I chose this course as the lecturer of the Linear Algebra textbook, MIT Professor Gilbert Strang, conducts this MOOC. [Total time estimate: 50 hours]

2.  Time to improve my management skills of data science projects, experiments and teams

A large part of work at my previous employer and at my current job at the Foundery is to manage various data science projects and teams. I have a lot of practical experience in this domain, but I don’t think it would hurt to go back and refresh some of the core concepts that relate to effective data science project management. To this end, I managed to find an appropriate Coursera specialisation that aims to help data science project managers “assemble the right team”, “ask the right questions”, and “avoid the mistakes that derail data science project”.

  • Executive Data Science Specialization – John Hopkins University. The entire specialisation is only 5 weeks long, and requires 4-6 hours a week of effort. The courses that are on offer are titled “A Crash Course in Data Science”, “Building a Data Science Team”, “Managing Data Analysis”, “Data Science in Real Life” and “Executive Data Science Capstone”. I wasn’t able to obtain rating information for this specialisation. [Total time estimate: 50 hours]

 3.  Improve my computer science and software engineering skills

When I first started out, I managed to pick up a few Unix skills (just enough to be dangerous as evidenced when I once took out a production server with an errant Unix command). Since then, and over time, I have lost the little that I knew (luckily for production support teams).

New and exciting software engineering paradigms have emerged, such as DevOps and code repository solutions like Github are now commonly used in both the data science and development industries. As such, I thought that some study in this domain would be useful in my journey.

I would also like to increase my knowledge of data structures and algorithms from both a practical and theoretical perspective. To this end, I have found an exciting and challenging University of California San Diego Coursera specialisation called “Master Algorithmic Programming Techniques”.

The courses that I am planning to complete to improve my computer science and software engineering skills are:

  • How to use Git and GitHub – a freely available course offered by Udacity with input from Github. This course is a 3-week MOOC and is rated 4.5 out of 5 stars out of 41 student reviews and will require 6 hours of commitment per week. This course introduces Git and GitHub and will help me to learn how to use better source control, which in turn will greatly assist with project delivery of medium to large sized data science projects. [Total time estimate: 30 hours]
  • Introduction to Linux – a freely available course from edX. This is an 8-week course rated 4 out of 5 stars by 118 student reviews with over 250 000+ students enrolled. Thoroughly covering this material will take between 40-60 hours per the course notes. Gaining a firm understanding of Linux will allow me more control when using the open source data science environments and tools. [Total time estimate: 60 hours]
  • Introduction to DevOpsUdacity. This free course introduces that concept of DevOps and explains how to implement continuous integration, continuous testing, continuous deployment and release management processes into your development workflow. I am very interested to see how this could be applied to the data science world. The course does not have a rating and is 3 weeks in length requiring 2-3 hours per week of effort. [Total time estimate: 10 hours]
  • Master Algorithmic Programming Techniques – This Coursera specialisation by the University of California San Diego comprises 6 courses —Algorithmic Toolbox, Data Structures, Algorithms on Graphs, Algorithms on Strings, Advanced Algorithms and Complexity, Genome Assembly Programming Challenge Each course is 4 weeks of study, 4-8 hours per week. The individual courses were rated between 3.5 – 4.5 stars.

What excited me about this specialisation is that I would get an opportunity to learn and implement over 100 algorithms in a programming language of my choice from the ground up. I think that this would certainly improve both my knowledge about algorithms as well as my programming skills.

After looking a bit deeper at the course structure, it seems as if this specialisation is paid for at $49 per month until you complete it. So, the faster I do this, the cheaper it’ll be – nice incentive! [Total time estimate: 235 hours]

4.  Improve my base data science skills and up my Python coding abilities

At this stage of the curriculum, I would have solidified my maths and stats skills, improved my computer science and software engineering skillset, and brushed up on some data science project management theory. Before embarking on intensive machine learning material, I think that it might be a good decision to get back to basics and look at improving my base data science and visualisation skills and upping my Python coding abilities while at it.

One of my goals for this curriculum was to improve my communication skills by becoming a real data story-teller. An effective way to do this is to learn how to visualise data in a more concise, meaningful and, I guess, beautiful manner. I say beautiful because of an amazing data visualisation website called Information is Beautiful. Check it out; you won’t regret it.

  • Learning Python for Data Analysis and Visualisation – Udemy. Jose Portilla’s Udemy course is highly rated at 4.6 stars out of 5 from over 4 220 student reviews. Over 47 812 students have enrolled in the course. The length of the videos on this course is 21 hours, so until I can estimate this better, I will add 100% to my time estimate for completing the course.  The course is focussed on Python and introduces topics such as Numpy, Pandas, manipulating data, data visualisation, machine learning, basic stats, SQL and web scraping. Udemy often run specials on their courses, so I expect to pick this one up between $10 and $20. [Total time estimate: 50 hours]
  • Data Visualization and D3.js – Communicating with DataUdacity. This free course is part of Udacity’s Data Analyst nanodegree programme. The course provides a background in visualisation fundamentals, data visualisation design principles and will teach you D3.js. It is an intermediate level course that will take approximately 7 weeks to complete at 4-6 hours per week. [Total time estimate: 50 hours]
  • HackerRank challenges – HackerRank is a website that provides a very entertaining, gamified way to learn how to code. HackerRank offers daily, weekly and monthly coding challenges that reward you for solving a problem. The difficulty of the questions ranges from “Easy’ to “Hard”, and I plan to use this to test my new-and-improved Python skills. Every now and then I will use this form of learning Python as a “break” from the academic slog. [Total time estimate: n/a]

5.  Learn the basics of machine learning from both a practical and theoretical perspective

The resurgence of machine learning (the science of “teaching” computers to act without explicitly being programmed) is one of the key factors in the popularity of data science and drives many of the biggest companies today including the likes of Google, Facebook and Amazon. Machine learning is used in many recent innovations including self-driving cars, natural language processing, advances in medical diagnoses to name a few. It is a fascinating field, and as such, I want to gain a solid foundational understanding of this topic. It will also lay the foundation to understand the more advanced machine learning theory such as deep learning, reinforcement learning and probabilistic graphical models.

Machine Learning – Stanford University. Taught by Andrew Ng, this 10-week course is one of Coursera’s most popular courses and is rated 4.9 out of 5 from 39 267 student reviews. A commitment of 4-6 hours per week will be required.

Andrew Ng provides a comprehensive and beginner-friendly introduction to machine learning, data mining and pattern recognition and is based on several case studies and real-world applications. Supervised and unsupervised learning algorithms are explained and implemented from first principles, and machine learning best practices are discussed.

This course is a rite of passage for all aspirant data scientists and is a must-do. If you are on a more advanced level of machine learning understanding, look for the handouts of the CS229 Machine Learning course taught at Stanford (also by Andrew Ng) for further material. [Total time estimate: 80 hours]

Machine Learning A-Z Hands-On Python & R In Data ScienceUdemy. This course is a highly rated, practical machine learning course on Coursera. It is rated 4.5 stars out of 5 based on 11 798 student reviews. 86 456 students had signed up to this course at the time of writing. The videos total 41 hours and as before I will double this for my effort estimate.

The course is very hands on, and comprehensively covers topics such as data pre-processing, regression, classification, clustering, association rule learning, reinforcement learning, natural language processing, deep learning, dimensionality reduction and model selection. It can be completed in either R or Python. Again, I will look to pick this one up on a special for between $10 – $20. [Total time estimate: 80 hours]

6.  Our capstone project – let’s dive into the deep learning end

We have finally made it to what I regard as the curriculum’s capstone project – a practical course on deep learning:

  • Practical Deep Learning For Coders, Part 1 – Out of all the courses that I have looked at, I am probably the most excited about this one.’s deep learning course is a very different MOOC to the rest in that the content is taught top down rather than bottom up. What this means is that you are taught how to use deep learning to solve a problem in week 1 but only taught why it works in week 2.

The course is run by Jeremy Howard who has won many Kaggle challenges and is an expert in this field. The problems solved and datasets used in this course comes from previously run Kaggle challenges, which allows you to easily benchmark your solution to the best submitted entries.

A significant time commitment is required for this course – 10 hours a week for 7 weeks. The course teaches you some cool stuff such as such as how to set up a GPU server in the cloud using Amazon Web Services, and how to use the Python Keras library. As per the homepage for Keras, “Keras is a high-level neural networks AP developed with a focus on enabling fast experimentation. It is written in Python and is capable of running on top of either TensorFlow, CNTK or Theano.

As Jeremy Howard says, all you need to succeed in this course is pragmatic programming, tenacity, an open mind and high school math so good luck and well done on getting to this stage! [Total time estimate: 100 hours]

7.  Conclusion

So, we have finally made it to the end – well done! I have reviewed countless number courses in compiling this curriculum, and there were so many more that I wanted to add, including these more advanced topics:

I have also not touched on related topics such as big data, data engineering, data management, data modelling nor database theory of structured and unstructured sets of data. An understanding of these topics is nonetheless vital to understand the end-end spectrum that makes up the data analytics continuum. Nor have I chatted about the myriad data science tutorials and Kaggle-like data science challenges out there.

I intend to look at relevant tutorials and Kaggle problems where they relate to parts of this curriculum and where possible I will try implement some of these solutions on a big-data platform. While discussing this topic with one of my colleagues, he suggested also trying to build something big enough that encompasses all the above so that I can have an end-target in mind, don’t get bored and implement something that I am passionate about from the ground up. This is certainly something that I will also consider.

This challenge will start on 10 July 2017. According to my estimate, this curriculum will take 110 weeks or just over 2 years!! As daunting as this sounds, I take heart from Andrew Ng, the machine learning expert, when he said the following in an interview with Forbes magazine:

In addition to work ethic, learning continuously and working very hard to keep on learning is essential. One of the challenges of learning is that it has almost no short-term rewards. You can spend all weekend studying, and then on Monday your boss does not know you worked so hard. Also, you are not that much better at your job because you only studied hard for one or two days. The secret to learning is to not do it only for a weekend, but week after week for a year, or week after week for a decade. The time scale is measured in months or years, not in weeks. I believe in building organizations that invest in every employee. If someone joins us, I can look them in the eye and say, “If you come work with me, I promise that in six months you will know a lot more and you will be much better at doing this type of work than you are today

I hope that this quote resonates with you too and that the blog has helped or motivated you to improve your data science skills. Thank you for reading this and please keep me honest in terms of completing this challenge. Please post a comment if you think I should add to or change the curriculum in any way, and post your own course reviews — let me know if there are any other books and textbooks that I should consider. Expect updates soon!

by Nicholas Simigiannis



Extreme programming practices that mitigate Technical Debt

Technical debt, first coined by Ward Cunningham(TD) [1, 2], can be described as the dichotomy between the best design that takes longer to implement and a quick design and implementation for short-term gain. The technical compromise between these two designs and extra development effort needed to make changes to the latter software system represents debt.

1.   What is Technical Debt?

Technical debt, first coined by Ward Cunningham(TD) [1, 2], can be described as the dichotomy between the best design that takes longer to implement and a quick design and implementation for short-term gain. The technical compromise between these two designs and extra development effort needed to make changes to the latter software system represents debt.

A popular metaphor is that of monetary debt. If TD is not repaid as soon as possible, “interest” is incurred — this relates to the effort needed to implement changes in the future. When TD is not addressed and systems are patched with functional and bug fixes, it leads to an increase of software entropy [3, 4], a condition that deteriorates over time. In some situations, when creating a proof-of-concept (POC), it is acceptable to incur some degree of TD. This, however, is known at design time and should be addressed when the POC evolves into an official project.

Another symptom of TD can be compared to the law of unintended consequences. More often than not, poorly designed systems have longer release cycles and have higher resistance to change. This is due to the fact that when necessary code changes are made to one part of the system, unintended changes occur and have to be addressed. This increases the time of the delivery cycle and drives the cost of change higher, often leading to more pressure, which in turn creates more TD.

Some causes of TD:

  1. Last minute emergency additions or omissions of functionality;
  2. Incompetent technical leadership and bad systems architecture;
  3. Efforts to minimize startup capital;
  4. Outsourced software engineering;
  5. Ignoring industry standards;
  6. Building tightly coupled code with modularity Loosely coupled code is easy to modify or change; and
  7. Non-existent test suite, continuous integration and deployment


TD manifests itself in the following examples:

  1. Countless branches of same code base, often for single customer releases;
  2. Database SQL stored procedure spanning a 1000 lines of code (LOC);
  3. Continuous version releases to fix bugs;
  4. Frequent patching of a legacy system; and
  5. Very large methods within

Figure 1: The author’s depiction of technical debt

2.    What is extreme programming?

Kent Beck [5] is widely considered as the creator of the XP software development methodology. XP is a frontrunner to many of today’s more modern software development methodologies. It is a lightweight, practical methodology with a focus on software quality and responsiveness to stakeholder requirements and change.

Intensive requirement analysis and extensive documentation are omitted from the process. Teams are small and focused, with a heavy emphasis placed on simplicity and short development cycles. User stories are a core doctrine of XP. Projects are initiated by the final users creating user stories describing the behaviour and functionality of the software system. Before any coding begins, functional testing of the requirements is conducted, with automated testing throughout the lifecycle of the project. Code is constantly refactored to reduce complexity, drive efficiency and adhere to standards. The result is extensible and maintainable code.

Good relationships between software engineers and stakeholders are also considered a cornerstone of XP as defined in the XP value system: communication, simplicity, feedback, courage and respect.

A software engineering team does not necessarily follow every XP practice. Self-organizing teams use and follow the XP practices that suit them at a point in time. As the software engineering team grows in maturity, so more XP practices are incorporated or omitted.

Given that most software systems are in a state of flux, XP adapts with the software system without being a technical barrier. XP manages this by having both technical and management practices. There are several XP practices, but for the purposes of this blog, the primary practices of XP are broken down in Table 1.

Table 1: Primary extreme programming practices

2.1  Modularity violations as a cause of technical debt

When code follows a good design and strictly adheres to standards such as the SOLID principals [6], changes to one module do not affect another module. A module can be described as a “unit whose structural elements are powerfully connected among themselves and relatively weakly connected to elements in other units.” [7]. This inherently creates an orthogonal design.

“Orthogonal design is the union of two principles, cohesion and coupling [8]”. To be more specific, loosely coupled code creates high cohesion, which makes responding to changes very easy and predictable. Positive side-effects of orthogonal design lead to clear and logical structure of relationships and create significant reuse.

Modularity violations occur when changes to one module unexpectedly induces changes to another module. This is not orthogonal design and a key indicator of TD. Changes to the code are not easily made and time estimation becomes inaccurate.

These violations must be identified and rectified by relentless refactoring, a cornerstone practice of XP. Strict and comprehensive coding standards must underpin the refactoring efforts of code, another important XP practice. The two XP practices complement one another and when used together lead to a direct and significant decrease in TD.

In the research paper Comparing Four Approaches for Technical Debt Identification, substantive findings are made by Zazworka et al. A very high correlation exists between Modularity violations and change prone classes, so much as 85% as shown in Table 2 below.

Table 2: Correlation between Modularity Violations and change prone classes [9]

2.2  Technical debt estimation variance

An integral function of software engineering is estimate development time for maintenance and new components. TD can have a significant impact on such estimations. Variances in estimation are depicted by the Cone of Uncertainty. Instead of being certain of the estimations given, TD creates increased uncertainty at the later stages of the lifecycle, where estimates should be more accurate (shown in Figure 2). This negatively impacts cost, productivity and project schedules.

Figure 2: Adapted Cone of Uncertainty impacted by technical debt [10]

Deadlines frequently being missed and so-called unforeseen changes to the code during the development cycle are indicative of time estimation variance due to TD. Accurately predicting development duration is not an easy task, TD makes this exponentially more difficult. Most estimates are given at the start of the phase, when TD is encountered estimates become inaccurate due to the extra work effort involved.

2.3  Measurement of Technical Debt

In the research recorded in Measuring Architectural Technical Debt [11], Kuznetcov defines TD as follows:

[TD] Principal – cost of eliminating TD (Code Debt, Design Debt etc.).

[TD] Interest probability – the probability that the type of TD will have an impact on the system (likelihood of imminent refactoring).

[TD] Interest amount – the extra cost incurred for addressing the TD (cost of modifying a module earmarked for refactoring as opposed to the cost of modifying after refactoring).

TD : { TDprincipal, TDinterest }

           man hours           work incurred           loss of productivity

TD can be expressed as an array where TDprincipal is independent of TDinterest. In keeping with the debt metaphor, the principal debt can be higher that the interest incurred or vice versa.

Various approaches are available to calculate the TD principal. Curtis et al. describes the TD principal value as a function of must-fix problems, the time required to fix, and the cost of the fix. Source code analysis provides actual counts and values calculated against input variables and the code itself. In the code, structural problems, modularity violations, LOC and duplication (to name but a few) all provide input for this analysis. TD can then be expressed as a product of this source code analysis. The principal amount of TD can be calculated using the high-level formula:

TDprincipal = Nmust-fix issues x Ttime required x Ccost incurred

2.4  Technical debt mapped to XP practices

All software systems develop some pain points over time. These pain points are based on the ISO 9126 [12] standard. (This standard has been revised by the ISO/IEC 25010 [13] standard.) A generic indicator of software quality can be defined by six characteristics: functionality, reliability, usability, efficiency, maintainability, portability [12].

These points are dealt with as they arise, and they are also indicators of TD. In Figure 3,  the author adapted the original diagram by Zazworka et al. [14] to reflect a mapping with the relevant mitigating XP practices.

By analysing the characteristics of each XP practice and variants of TD, a mapping can be made of the XP practices that effectively reduce the relevant form of TD.

Figure 3: Adapted Technical Debt landscape [14]

2.4.1  Coding standards – Directly influence the actual structure, composition and interaction of a software system at its lowest level. This can include guidelines and rules that the software engineer has to follow when writing code. This important practice touches on every part of the design, writing and testing of code.

2.4.2  Continuous integration – Facilitates in the feedback of system health and interaction in a continuous and predictable manner. As code is written and checked into version control, an extensive process of compiling, testing and deploying is started. Feedback is provided from all these sub-processes. Processes fail fast and provide immediate information.

2.4.3  Incremental design – Allows for the evolution and advancement of the software system in small manageable and measurable increments. Small releases are easy to scrutinize for TD. Also, small frequent releases are highly productive and stakeholders perceive a growing healthy software system.

2.4.4  Refactoring – Allows for the evolution and advancement of the software system on a code level and keeps the system at an optimal level of engineering excellence. If the code is frequently refactored, it becomes familiar to the software engineering team and TD is dealt with proactively.

2.4.5  Test-first programming – Software defects are kept at a minimum. The addition of new functionality is made simpler and more visible due to observable and trackable test results. As all the tests pass, the software system’s integrity is maintained and confirmed. As the system grows, the test suite grows too.

3.      Findings

Research indicates that there are various approaches to measure and indicate the extent of TD. This applies to both TDprincipal and TDinterest as described in Section 2.3. Only once there is a manifestation of a standard approach, can tools like SonarQube [15] come to fruition and be more scientific [11]. The SQALE[16] method has been widely adopted as a standard way of measuring and expressing TD. The adoption allows for increased feedback and evolution of the method.

Apart from the common causes of TD discussed in this paper, disconnect between technical staff and management is a major cause of project overrun and subsequently TD. This is exacerbated by the lack of further learning by middle management. Middle management also influences technology decisions and lack of understanding technology leads to an increase in TD.

When XP is implemented effective mitigation of TD occurs naturally. XP has had a significant impact on software engineering in the last decade. CI, Refactoring and Test-first programming have been instrumental in this, especially in the management of TD [17].

Each practice addresses one or more forms of TD [18]. Coding standards combined with refactoring and static code analysis directly increases code quality. Refactoring also aids in the writing of unit tests. Further, if done correctly, code will always be in a better state than before refactoring took place. Every new feature is built off a better base than the previous feature — this is true continued improvement. CI reduces the cost of integration and provides continuous feedback, and mitigates operational debt. Incremental design allows for the focus to be on functionality needed now, small increments and modularity counter design debt. Effective use of Test-first programming dramatically reduces defects and increases code quality, this mitigates code and test debt [19, 20].

In previous research [21] conclusive empirical evidence was provided in the written responses of interviewed software engineers. Applying a points system to the ranked XP practices provides a clear hierarchy of effective- ness. The Coding Standards XP practice is ranked first by a substantial margin. Refactoring and incremental design follows in rank respectively. Lastly, test-first Programming and continuous integration occupies the last two positions respectively.

Table 3: XP practices ranking

4.      Conclusion

The five XP practices are intrinsically linked in their ability and effectiveness in the mitigating of TD. The effect of following all these practices drastically reduces levels of TD. The power of these XP [22] practices lie in fact that they complement and follow on from each other. Most modern agile methodologies heavily incorporate these five practices, a testament to their importance.

In its simplest form: “Technical debt is the difference between what was promised and what was actually delivered” [23]. This difference can not only be very difficult to measure, but also difficult to find the root cause for the difference. TD will always be incurred at varying degrees of cost. An argument must be made that a software system is born from the code itself, not the idea of a software system. The code captures not only the core business idea or solution to the problem, but the reasoning and cognitive ability of a group of people, an amalgamation of intellect. Code must be guarded, maintained, optimized and treated with a level of respect. The empirical evidence presented substantiates that the five XP practices aid in this.

With time the measurement of TD and tools reporting on TD will increase in sophistication. There is no single solution to measure, report and reduce TD but rather a combination of measures and practices. The astonishing amount of research papers and commercial literature on the subject is proof of this.

Adapting to change is crucial to any software system evolving over time. Empirical evidence shows that this evolution can have negative consequences, but the practices we use to measure and mitigate the impact are also evolving in their effectiveness.


[1]  W.Cunningham. “The WyCash portfolio management system.” ACM SIGPLAN OOPS Messenger , vol. 4, pp. 29–30, 1993.

[2]  Debt Metaphor – Ward Cunningham. URL Last accessed: 1 October 2016.

[3]  Software Entropy. URL Last accessed: 1 October 2016.

[4]  N. Ford. Evolutionary architecture and emergent design: Investigating architecture and design. IBM developerWorks. URL  Last accessed: 1 October 2016.

[5]  K. Beck and C. Andres. Extreme Programming Explained: Embrace Change, 2nd Edition. Addison Wesley, 2005.

[6]  Solid principles. URL Last accessed: 1 October 2016.

[7]  C. Y. Baldwin and K. B. Clark. Design Rules: The power of modularity. The MIT Press, 1999.

[8]  J. Coffin. Cohesion and Coupling: Principles of Orthogonal, Object-Oriented Programming. URL http:// Last accessed: 1 October 2016.

[9]  N. Zazworka, A. Vetro, C. Izurieta, S. Wong, Y. Cai, C. Seaman, and F. Shull. “Comparing Four Approaches for Technical Debt Identification.” Tech. rep., 2016. URL courses/esof522/handouts_papers/TDLandscape.pdf.

[10]  B. W. Boehm. Software Engineering Economics. 1981.

[11]  M. Kuznetcov. Measuring Architectural Technical Debt. Master’s thesis. URL 769526/z-mscis-s4340132-mkuznetcov-2014-08-28.pdf.

[12]  ISO 9126 standard. URL Last accessed: 1 October 2016.

[13]  ISO/IEC 25010 standard.     URL detail_ics.htm?csnumber=35733. Last accessed: 1 October 2016.

[14]  N. Zazworka. Technical Debt. URL Last accessed: 1 October 2016.

[15]  SonarQube. URL Last accessed: 1 October 2016.

[16]  SQALE. URL Last accessed: 1 October 2016.

[17]  N. Brown, Y. Cai, Y. Guo, R. Kazman, M. Kim, P. Kruchten, E. Lim, A. MacCormack, R. Nord, I. Ozkaya, R. Sangwan, C. Seaman, K. Sullivan, and N. Zazworka. “Managing Techni- cal Debt in Software-Reliant Systems.” Tech. rep. URL db80f0e465cfcad4077c5703ff1cdfd8e902.pdf.

[18]  J. Holvitie, V. L. nen, and S. Hyrynsalmi. “Technical Debt and the Effect of Agile Software Development Practices on It – An Industry Practitioner Survey.” Tech. rep. URL mtd/2014/papers/6791a035.pdf.

[19]  C. Sterling. Managing Software Debt – Building for Inevitable Change. Addison Wesley, 2010.

[20]  J. C. Sanchez, L. Williams, and E. M. Maximilien. On the Sustained Use of a Test- Driven Development Practice at IBM. URL 61b77e2df21b43d5e500341d5efec286c195.pdf. Last accessed: 1 October 2016.

[21]  C. Fourie. “EXTREME PROGRAMMING PRACTICES THAT MITIGATE TECHNICAL DEBT.” Tech. rep., School of Electrical and Information Engineering, University of the Witwatersrand, 2016.

[22]  Extreme Programming . URL Last accessed: 1 October 2016.

[23]  Escaping the black hole of technical debt. URL Last accessed: 1 October 2016.

by Carel Fourie

Finding your True North

In RMB’s world, and indeed in corporate and investment banking in South Africa, the Foundery is an unusual paradigm. On the one hand, the Foundery is a fintech, aiming to disrupt the financial services industry with innovative and novel products and services, but on the other hand, the Foundery is very much rooted as the digital innovation unit of RMB — one of the very incumbents which stand to be disrupted by the fintechs.

In RMB’s world, and indeed in corporate and investment banking in South Africa, the Foundery is an unusual paradigm. On the one hand, the Foundery is a fintech, aiming to disrupt the financial services industry with innovative and novel products and services, but on the other hand, the Foundery is very much rooted as the digital innovation unit of RMB — one of the very incumbents which stand to be disrupted by the fintechs.

There are many things that are unique about the Foundery, not least of which is its position at the intersection between fintech startup and banking incumbent, but most pertinently is its mission to completely change and reimagine the corporate and investment bank of the future.

This is a monumental goal and certainly not something that can be achieved without great effort. It may be worth asking, why not go for something smaller or easier? Why not chase the untapped profits or go after the opportune inefficiencies in traditional banking

The Foundery’s mission is what we call its True North. This is what gives the Foundery its identity and guides its actions. Without it, the Foundery would be another player in the fintech space, but with our True North, the Foundery is a fintech with purpose.

Earth’s geographic North Pole


In astronomy, True North is the direction along the earth’s surface which points towards the geographic North Pole of the earth. This seems reasonable as geographic north is the northernmost point of the earth, so why call it True North when it is already north? Why the extra qualification?

The reason is that compasses and maps point to a slightly different north pole, what we call magnetic north and grid north respectively. These differences arise out of the slightly irregular shape and magnetic distribution of planet Earth.

The difference between the true north and the magnetic north

True North is important in astronomy because it serves as a reference by which we can measure the position of every object in the universe relative to its point of observation on Earth. This takes us back to the analogy of the Foundery’s True North and what we mean by the concept of True North:

Your True North can be thought of as your fundamental purpose that guides everything you do.

Just like the Earth’s True North is used by astronomers to map the night sky, your True North is what informs your goals and your decisions. It is the guiding principles by which you can make your biggest and most impactful choices.


The concept of your own True North is something which is quite abstract and extremely daunting. What does it mean to have a fundamental purpose? Where does it come from? What am I meant to do with it? How do I know if I even have one? These questions are all relevant and aren’t easy to answer. In fact, there are no obvious or immediate answers — it’s up to you to decide what they are.

The good news is that we can learn from the geographic North Pole and extend the analogy. In practice, while we can’t rely on compasses or maps to navigate to the Earth’s True North, astronomers have been using the North Star, also known as Polaris, to mark the location of true north since the time of the Ancient Greeks. The North Star lies almost exactly “above” the geographic North Pole. Furthermore, the North Star is visible throughout the year (as long as you’re in the northern hemisphere*) and is therefore a reliable, although ancient, method of navigating to true north.

The North Star: a time lapse image shows how the North Star rotates tightly around the celestial North Pole (in line with True North), while other stars rotate with a much wider radius.

Extending this analogy to your own True North, the challenge then becomes to find your North Star. What is that thing, whether it is abstract or tangible, that points to your True North? This could be a person, it could be your family, it could be your talents, it could be your hobbies or whatever it is that affirms that you doing what you love and that gives you a sense of purpose.

In the Foundery’s case, True North is our mission to change the world of banking, and the North Star is the people who have stepped up to the challenge to make this mission possible. Without the North Star, the Foundery would never be able to find its True North. Now the challenge is up to you — go out there and find your own North Star and, ultimately, your True North.

* Unfortunately there is no equivalent star in the southern hemisphere

by Jonathan Sinai

The Evolution of Money – Part 3

Currently, government money (e.g., USD, ZAR, GBP) can only be held in two forms: physical cash (physical bearer instrument) or digital money in a bank account (digital registered instrument). Crypto currency is a new form of money that can be offered as a third form of central bank issued money. It is only a matter of time before central banks issue their own crypto instruments in the form of central bank issued crypto currencies (CBCCs).

(This is a continuation of my earlier blogs “The Evolution of Money – Part 1 ” and “Part 2 ”)

Currently, government money (e.g., USD, ZAR, GBP) can only be held in two forms: physical cash (physical bearer instrument) or digital money in a bank account (digital registered instrument). Crypto currency is a new form of money that can be offered as a third form of central bank issued money. It is only a matter of time before central banks issue their own crypto instruments in the form of central bank issued crypto currencies (CBCCs).

While the term CBCC may scare some in the regulated space as “crypto currencies” have become associated with unregulated tokens of value, the term merely differentiates it from the digital money that sits on commercial banks’ balance sheets as liabilities. Its name is derived from the cryptography that allows it to be a crypto instrument.

Just as no distinction is made between the value of a physical $100 bill and $100 in digital money that appears in an online bank account, so too would the value of $100 in CBCC be the same as the first two forms of money. The currency would remain the same. Only the form would change. The emergence of CBCC would not change the money supply[i] in an economy.

The introduction of a third form of regulated money, CBCC, would replace another form of money to keep the money supply constant ceteris paribus. Just as one deposits a $50 note at the bank which gets replaced by $50 in an online bank account, so too would $50 in CBCC have to replace some other form of money already in circulation. A central bank could easily set up a trust account to receive digital money (which it could take out of circulation) and issue a corresponding amount of CBCC to be sent to a wallet address of the digital money sender. In this way, the form of money as we know it could migrate from digital money to CBCC.

By migrating the predominant form of money in an economy to CBCC on a sovereign blockchain (a shared ledger under the jurisdiction of a central bank), a central bank could observe real time transactions in an economy to better understand the velocity of money and gauge the health of the economy on a daily or even hourly basis. Once a sovereign blockchain is created with a CBCC, other financial instruments such as bonds, equities, derivatives and even land and car registries could migrate to the same sovereign blockchain. This would allow the central bank to conceivably see the creation of all commercial bank assets in an economy in real-time, including the categorisation of those assets (e.g., collateralised loans vs. unsecured loans). Such transparency is invaluable to any central bank and would make decision-making more informed, timely and effective.

With a view of all transactions in an economy, anti-money laundering initiatives would be greatly enhanced. As it stands, payments from customers at a single bank are not always seen by the regulator as they are updates to that particular bank’s ledger and do not get processed through a national payments system, making the historical flow of money difficult to track. In contrast, a sovereign blockchain would allow the movement of money to be traced through a historical path of transactions on a single decentralised ledger.

Tax collection could be revolutionised through the use of smart contracts on a blockchain. Tax could be collected at the point of transaction in real time, changing the entire system of tax collection from “after-the-fact collection” to “in-the-moment payment”. Imagine every payment to a retailer being automatically split at the time of payment so that 10% (a sales tax for example) would be paid directly to a government address with no inconvenience or cost to the customer or merchant. This would significantly reduce the burden and cost of tax compliance for the merchant (as they would be paying their taxes automatically throughout the year) and improve collections for the tax authority.

This is just one example of how tax could be streamlined, but other examples abound – automated Capital Gains Tax when a vanilla asset is sold (the blockchain would have the history of what the asset was initially bought for and a smart contract could calculate the tax owed and pay both the seller and the tax authority in a single transaction); automated transfer duty on property sales; automated income tax payments when salaries are paid etc. The very notion of a withholding tax could become obsolete.

The blockchain would also allow the “codification of money”. Imagine a world in which the money paid into the account of the Department of Education could only be disbursed to accounts associated with schools or where money sitting in the government’s social grant account could only be paid to accounts of individuals flagged as eligible to receive those grants. The combination of the codification of money and the transparency that the blockchain allows would go a long way in combatting corruption.

[i] Money supply is defined as the total amount of monetary assets in an economy’s currency, the summation of physical notes and coins as well as digital money (the nuances of narrow and broad money definitions of M0, M1, M2 and M3 are not pertinent to the point at hand).

by Farzam Ehsani

Human-centered design

Gone are the days when design used to be about aesthetic execution, when the main focus was to get as much work out the door as possible so that there was more time for more work — when brands spoke down to their consumers instead of speaking to them.

Gone are the days when design used to be about aesthetic execution, when the main focus was to get as much work out the door as possible so that there was more time for more work — when brands spoke down to their consumers instead of speaking to them.

Now most brands are waking up to the fact that we are living in an ever-changing, ever-growing, fast-paced world where the consumer has access to all kinds of information literally at their fingertips. And design plays a crucial part in the world we live in today. From the food we eat to the information we choose to consume online, design is everywhere.

Brands are cottoning on to the fact that their customers are more informed than ever before, and so big brands like Apple, Google, Uber, Airbnb, Facebook etc. are placing the consumer at the core of everything they do. This means that brands are now allowing their customers to decide on the type of content they want to consume and then designing for that. In the product design space this is so important — keeping the consumer at the center of everything that you do for a better experience.

Human-centered design is all about developing good relationships with your customer by delivering a high quality product that through prototyping and testing results in an emotional connection between the customer and the product.

                              Fig. 1 The human centered design pyramid (source: Giacomin, 2014)

Good design needs to be able to answer a set of key questions to facilitate this connection.

  • Who is the consumer?  Does the design reflect the user characteristics?
  • What are the consumers’ goals when using the product?
  • What is their experience when using the product?
  • What are the goals of using this specific product or service?
  • When and how does the consumer interact with the product design?
  • What do consumers think about the product or the design?
  • Why does the consumer want to use this product or design?


Consumer feedback is key in ensuring that the design continually improves. And so, unlike before, the design process is never complete. Especially in the product design space, it is very important to keep iterating and making your product better with each iteration. Part of achieving that emotional connection with the product is about designing experiences as opposed to designing products.

The commonly used tools in building a human-centered approach are:

  • Personas;
  • Scenarios; and
  • Use cases.


Persona: This refers to creating fictional character that could potentially interact with your product. This usually includes their age, race, gender, location etc. Basically, it’s the target audience.

Scenarios: This would be the possible scenario of the persona using your product.

Use cases: This refers to the feedback gathered from the Persona through the Scenarios

It’s time that brands start immersing themselves in the worlds of their consumers if they want to remain relevant.

by James Mokhasi

Proliferation of cryptocurrencies: which currencies should you invest in?

Most people in the banking world today are familiar with the term blockchain. The first thing that springs to mind when blockchain is mentioned is Bitcoin. It is the cryptocurrency and digital payment system created by the mysterious Satoshi Nakamoto, which has grown exponentially since its inception in 2009.

Most people in the banking world today are familiar with the term blockchain. The first thing that springs to mind when blockchain is mentioned is Bitcoin. It is the cryptocurrency and digital payment system created by the mysterious Satoshi Nakamoto, which has grown exponentially since its inception in 2009.

The value of Bitcoin has grown from around USD 2/Bitcoin in December 2011 to above USD 2,300/Bitcoin this year. Investment in Bitcoin sky-rocketed after a surge in traded volumes and increased Bitcoin prices in the Asian Market.

Investors are opening up Bitcoin wallets in the fear of missing out. As investors rush to ride the wave, not only has investment in Bitcoin spiked, but so too has the investment in “altcoins” (the cryptocurrency alternatives to Bitcoin). Some of the largest and most dominant of these are, inter alia, Litecoin, Ethereum, Ripple and Monero. Each cryptocurrency offers something different, and if deciding to invest in these long-term, it would only be prudent to understand more about what they do.

Let’s start with the world’s leading cryptocurrency, Bitcoin. In addition to boosting financial inclusion, Bitcoin aims to make near real-time cross-border transactions possible on a global scale. In South Africa there are already online merchants that are accepting Bitcoin payments. Some of them are well known brands: BidorBuy, Takealot, Superbalist, Runwaysale, Raru and Appliance Online. Additionally, all merchants on the platform (30 000 websites), accept Bitcoin.

Ethereum differs slightly from Bitcoin, with more focus on technical blockchain development. It is an open source platform used to build decentralised applications. Examples of Ethereum applications include self-executing smart contracts and native tokens. A number of interesting developments on the Ethereum blockchain are emerging. WeiFund, a crowdfunding solution, operates similarly to conventional crowdfunding platforms such as GoFundMe and Kickstarter. However, instead of using fiat currency, WeiFund raises funds using the Ether cryptocurrency. Users can contribute and manage crowdfunding campaigns with the use of smart contracts to turn donations into complex agreements.

Litecoin was created by Charles Lee, a former engineer at Google, with the intention of becoming the second most valuable cryptocurrency. When it was written, it was the second biggest cryptocurrency by market capitalization, but has since fallen to the 6th largest as it has yet to see much more investment. Litecoin is similar to the Bitcoin. The main difference is that it takes an average of two and a half minutes to generate a block, contrast to an average of ten minutes that Bitcoin takes to generate a block. This means that Litecoin can confirm transactions at a faster speed than Bitcoin. However, it is important to note that transactions occur instantly, whilst confirmation of transactions occur as the blockchain propagates.

Monero is attempting to take on Bitcoin by providing greater transaction anonymity. Bitcoin is known for supporting anonymous transactions; however, each transaction has a sender, receiver and amount recorded on the blockchain. Each wallet has an address which can be traced back to the owner through IP addresses and service providers. To combat this, Monero makes use of a ring signature to provide for more privacy.

Ripple’s digital currency XRP is similar to Bitcoin as they are both digital currencies that can be mined and sent from peer-to-peer without an intermediary. Ripple is used as a currency agnostic value exchange. It is a real-time gross settlement system enabling real-time global payments anywhere in the world. The advantage of this is that it can be in any form of currency (Dollars, Yen, Euros, etc.). Ripple enables secure, instant and inexpensive global financial transactions and may assist Bitcoin in accessing the rest of the financial world.

There are over 700 different cryptocurrencies currently in issue which opens up a broad investment base. Hopefully some of these points spark your interest to delve deeper into each cryptocurrency’s ambition and that the summary above has given you a starting point for further research.

by Matthew Shaw


With the ubiquity of electronics, going from an idea to a working prototype has become cheaper and easier than ever before. The biggest problem with ideas is that everyone has them but most people do not have the drive and persistence needed in order to turn their ideas into a reality. To add further insult to injury it is also a challenge ensuring that the ideas one has chosen are good and not just a waste of time and money.


With the ubiquity of electronics, going from an idea to a working prototype has become cheaper and easier than ever before. The biggest problem with ideas is that everyone has them but most people do not have the drive and persistence needed in order to turn their ideas into a reality. To add further insult to injury it is also a challenge ensuring that the ideas one has chosen are good and not just a waste of time and money.

Idea selection

In terms of selecting an idea it is worth taking a step back and examining examples of good ideas and what made them so successful. Throughout history man has not changed too much from an evolutionary perspective. As a result, man’s desires and needs have also not changed too much either. The key thing that has changed is the technology available that that has enabled us to implement concepts to fulfill these needs and desires in different ways. Fiat money was first developed not because it was a good idea but rather because it became impractical to carry heavy goods and gold around to barter with. Another more recent example would be the development of Google and Wikipedia. Prior to the internet people would have used encyclopedias and libraries to research anything they needed, but the advent of the internet has allowed Google and Wikipedia to be developed to more efficiently and broadly spread this knowledge. With this observation in mind, that an idea can be successful if people find it useful, we get a tool we can use to help sift through our ideas. To use this we can just check if an idea we have will be useful to enough people, and if so, see how technology can help us pull this off to great effect.


Once an idea has been selected the execution stage can begin. Many methodologies have arisen to make the process of building ideas more scientific. Lean startup methodologies are one of the popular approaches in the startup space while agile provides similar concepts for software development. No matter the approach generally they encourage people to come up with a hypothesis and decide on the smallest possible chunk of this hypothesis they need in order to make what is known as the MVP or minimum viable product. All bloat is removed in favour of the smallest possible grain of the idea that we can build so that we can get it into the hands of customers as fast as possible. Small development cycles are advocated so that we can get feedback on the idea quickly and based on the feedback validate our hypothesis, and tweak it a bit more or completely change direction by pivoting.

One story that illustrates the power of small iterations comes from a book called: “Art & Fear: Observations on the Perils (and Rewards) of Artmaking” by David Bayles and Ted Orland:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an “A”. Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

What we can infer from this is that the faster we can test more ideas, the faster we can start perfecting our process and in so doing eventually hit upon the best ideas.


When building something it is very valuable to draw a line in the sand in terms of both time and money. If we have no deadline we may never finish, so putting a firm deadline in the sand helps us weed out unnecessary features to end up with our MVP and pushes us to make our development cycles as short as possible. Y Combinator (a company that provides early stage funding and assistance to startups) for example gives companies they fund just enough money to act as seed funding and 10 weeks to build a working prototype after which they present it to potential investors and acquirers. With unlimited funds and time, we are more likely to keep adding unnecessary features and deviate away from the MVP we decided upfront.

On a much smaller scale and from a personal perspective I decided I wanted to start building up an online presence with my own personal blog. I wasted time getting lost in the details and the technologies available without writing a single article. In the end I gave myself a deadline of two weeks from that point and decided my main aim was about the articles I wanted to start writing and not so much about the technology behind it. So I ended up using the cloud computing provider DigitalOcean and used one of their pre-built vanilla Ghost blogging platform deployments to get up and running ASAP. In the end putting this time constraint in place forced me to get on the right track.

Coming up with good ideas is tougher than it may seem. Many people have ideas but not all that many can go from idea to finished product. By looking at existing ideas one can get a feel for what makes a good idea — generally it is something that people really need as they find it useful. A number of methodologies have come to light which guide in validating an idea as fast as possible. Giving ourselves constraints helps keeps us honest and working towards a reasonable deadline. In the end if we can iterate through our ideas and validate them as fast as possible we are more likely to come upon a successful one. Thomas Edison sums it up best in his response to a reporter on their jeering comment about the number of times he failed: “I have not failed. I’ve just found 10,000 ways that won’t work.”


by  Yair Mark

A Blockchain Problem

Blockchain has been hailed as the next ‘big thing’, a term thrown around in social gatherings with the likes of ‘big data’, ‘cloud computing’ and ‘Internet of Things’. A crucial understanding of the true value of blockchain is sorely lacking in many minds, leading to wasted resources by some of the world’s top banks and tech firms.


Blockchain has been hailed as the next ‘big thing’, a term thrown around in social gatherings with the likes of ‘big data’, ‘cloud computing’ and ‘Internet of Things’. A crucial understanding of the true value of blockchain is sorely lacking in many minds, leading to wasted resources by some of the world’s top banks and tech firms.

Having been dubbed another ‘solution without a problem’ by some of its critics, the hype surrounding blockchain appears to oscillate between inflated expectations, and the trough of disillusionment, never quite hitting the slope of enlightenment, and thus never approaching anything quite like a product.

So what good is it really?

If you’re not familiar with the Byzantine Generals problem, here’s a quick overview:

Nine Byzantine Generals are entrenched around a city. They are divided upon their current course of action: do they attack, or do they retreat? Failing to reach consensus, they decide to cast votes, each general sending a messenger to relay their choice to the other generals, where the majority decision will be the action to take.

Four of the generals vote to attack and four vote to retreat. The group is split in two: those in favour of retreating, who begin to strike down their tents, and those in favour of attacking, who gather on the frontlines. What of the last general? Well, he’s been bribed by the city’s leaders*. Rather than vote one way or the other, he dispatches two messengers; the first states that he will attack, the second states that he will retreat.

Four of the generals thus lead their troops into battle and suffer a stunning defeat. The other four generals retreat, dishonoured, with a significantly weakened army.

This story is an allegory of a concept we have come to know as double-spending. In traditional markets, every merchant keeps their own ledger of all transactions. This is also true in the world of digital payments. Some clever customers have been known to make multiple transactions to different vendors, essentially issuing IOUs without the actual means to make good on every transaction. Come time for settlement, vendors have delivered their items, banks are short and the clever customer has high-tailed it through a proxy**.

This is the main problem Blockchain is intended solve: a distributed ledger network in which all vendors and customers share the same record of transactions and balances. Incentivised ‘miners’ add new transactions to the pool, where only one block of transactions is accepted at a time, based on mutual consensus by other parties, effectively solving the double-spend issue.

Too bad the Byzantines didn’t have blockchain.

Perhaps we need to go back to basics and focus on utilizing blockchain for its original intended purpose. All the pieces are set for us to begin digitizing financial instruments, ushering in a new era of trusted peer-to-peer transacting. The only question remains; what happened to the early adopters?

by Stuart Allen