Technology Strategy

Outsourcing to the seven "C"'s

2024-12-13T05:46:00.000-08:00

Outsourcing software development has become a very effective way to get software projects delivered in the modern fast-paced business environment. Like any approach, it has potential benefits and things to take into consideration.

Some potential benefits:

separation of concerns : separate a development project from BAU activities or other projects.
hit the ground running: potentially access to "ready made" teams of developers.
visibility of cost: depending on contract, cost can be tied to outcomes
specialisation: outsourced organisations may have core competence in areas that you do not and do not wish to strategically attain.

Here are a few things I think are worth considering based on my experiences over the last 25 years.

Context

The context of why you are choosing to outsource development is fundamentally important as is the context of what you are trying to develop (in terms of complexity) and how that ties in to your long term strategic objectives. For example if in developing a software application, there are some skills and competences that the business will need later in it's evolution, this would need to be taken into consideration. Unfortunately, one does not always know the answers to this (and other) question(s) apriori.

Contract

I have seen and/or been involved in many outsourced contracts and contract negotiations. It is not possible to get the perfect contract in place (in my opinion), however it is vitally important to get some basic considerations clearly laid out depending on context. No-one wants to use the terms of a contract as a threat (if it comes to that point, things are not going well), however, the contract should clearly define roles, responsibilities, ownership, accountability and other factors that set the project up for success. Ideally, the contract should be balanced, it is unwise to have the balance of power highly in favour of one side or the other, this leads to an inequitable relationship from the outset. In my opinion the most successful outcomes have been when the contract and the relationship reflects a partnership rather than supplier/purchaser type relationship.

Code

I guess at some point we have to talk about the code itself. Software is made up of many artefacts, code, documentation, data etc. Even working code can have varying degrees of "quality". An organisation should consider the future maintainability, extensibility and reuse of the code. It is very difficult to measure some of these attributes of the code, but it is worthwhile at least trying to have some standards or measure in place to sense check, that overall quality is there.

On many occasions I have seen the quality sacrificed for time or cost. There is no getting away from the fact that speed, quality, cost are conflicting requirements as they are in most spheres of life. It is important to strike a balance and be conscious of those decisions. On many occasions I have seen for example quality sacrificed for speed, only for quality to resurface at a later time causing dispute and other problems in the organisation. If you were to hire someone to paint your house very quickly with cheap materials you would naturally expect a sloppy finish which would not last very long. There is no difference when it comes to software engineering.

Another ugly-headed-monster often raises it's head when it comes to code. I have seen it so many times that I thought it is worth noting here. Actually, there are two related points. Firstly, in a world of open sourced libraries and frameworks, which we all use. It is important to keep an eye or have some control on which of these components get pulled into our projects. Some open-source code is of poor quality, some are not well maintained, and very recently there have been numerous instances of serious security vulnerabilities found in some of these open-source components. Secondly, in a number of cases I have seen outsourced companies offer their platforms or components to the project as a way to speed things up. Conceptually this makes sense, however, if not managed cleanly, it can lead to various problems. For example who owns that code, is that code maintained, is it documented, will future updates to that code be available in perpetuity etc etc. Remember the world is moving, especially in software and things become out of date very quickly. Also as a side bar, ideally you don't want to be sponsoring the outsourced organisation to improve their generic components on your account - it's very hard to manage this cleanly.

Ideally code should always be hosted on some system or repository owned by the hiring organisation and there must be some checks and balances put in to ensure that every artefact needed to deploy a fully functioning system is there, this should be tested on a regular basis. Far too often, I have seen cases where at some point, someone from HQ tries to deploy the system and finds out that there are missing artefacts. Hopefully, there is still a good relationship with the outsourced team and this can be easily solved, but there in inherent risk here.

Culture

One thing that this very often overlooked, is culture. Both corporate culture and international culture. Depending on how tightly coupled the outsourced team will be with core members of your management, product or development teams, culture should be taken into consideration. I have worked on projects with very capable teams in over 15 countries, the differences in style, approach, communication, accountability, manner etc etc are numerous and have a significant impact on being able to deliver quality software in a timely manner.

On a number of occasions I have seen organisations either move from an outsourced model to opening up a local office in the region (usually to save on cost amongst other things). However, on numerous occasions the business then proceeded to treat this remote office differently than an outsourced relationship. This is erroneous in my opinion, the outsourced element still remains irrespective, this is because the balance of power invariably remains within the central HQ. In terms of software development and managing the relationship and projects, one still has to consider the same things as with a "pure" outsourced relationship.

Communication

Communication is fundamental to any software engineering project. Getting the lines of communication established from the outset is paramount. Organisations often ignore simple things like language skills. For example having maybe multiple development teams in different countries all communicating in English can be a bigger barrier to success than many realise or factor into their decision making. I was once involved in moving a project from one side of the world to a team on the other side of the world. Aside from the logistic issues, the communication challenges were substantial.

In software engineering, communication needs to be comprehensive whilst succinct. This is often not easy to achieve. We tend to either over elaborate or under-elaborate. Getting the right balance is a challenge which is exacerbated by language barriers. This is before one considers other issues like timezones, personalities etc.

Co-operation

Fundamental to any successful software engineering project is co-operation. When it comes to outsourced development, what is often overlooked is that the incentives and motivations of the hiring organisation and it's staff may be misaligned with the outsourced organisation. For example, the senior architects and developers in the hiring organisation may have bonuses or other incentives, whilst the outsourced organisation will invariably have incentives around billable hours (this is unavoidable). Unless this is managed correctly, this can lead to complications in delivery.

Country (Education)

I have written about culture and communication, but further to these very important considerations, there are other considerations that in my experience can impact more complex software development projects. I think we would all agree that different education institutions have varying quality of education, some countries have a very high standard school system and higher education, other countries do not have the same standards. This in no way means that there are not highly skilled capable individuals in every country on the planet, it does however mean that finding these people can become more of a challenge in situations where they are likely to be scarce or in high demand.

There are other factors relating to a country that do come into play, unfortunately, with the global turmoil, conflict and war can have an impact. Infrastructure like electricity, telecommunications and accommodation can also impact and should at least be considered as part of the evaluation.

The pitfalls of share options in the technology startup

2022-05-31T09:35:00.004-07:00

Draft 1

PLEASE NOTE: I am a simple engineer and this document should not be taken as legal advice in any way whatsoever.

Please feel free to comment or relate your stories here. All feedback is more than welcome

Over the last few weeks I have been involved in trying to get a fair outcome for some options that I have in one of the many startups I have worked with over the years. As I continue to push my case forward I thought I would write some thoughts whilst fresh in my mind.

Many of us are attracted to startups due to the promise of shares or share options in the company we are joining. Many people work at reduced rates or no pay in exchange for these contracts, with the hope that one day they will materialise into some value for us.

For startup companies, options are a vital currency. Initially cash is tight and using options is a means to attract the right people to help launch the company or take it to the next stage in it's evolution.

In recent weeks, I have received many messages of support in my endeavours, but worryingly many former classmates, colleges and other technologists have written to me with the most amazing tales of woes. Some of the stories are almost unbelievable, it seems as if the institution of "options" is more than broken and I will be campaigning in the future for this to change.

LESSON 1 : Not all option agreements are equal

I have recently learnt the hard way that there are many pitfalls in the option agreement which must be taken into account. Some founders are genuine and want those that helped form the company to benefit, if it has success. Some start out that way, but become greedy along the way, and yet other are sly and devious and know from the outset that they do not intend to pay. The founders sentiment will be reflected in the option contract.

Whilst it may seem that you can use your judgement or a Lawyer friend to check through the contract, I would strongly advise that you seek an expert in the field. There are MANY pitfalls with option contracts and you want to make sure that someone with expertise in this particular area thoroughly reviews your option agreement.

Below are some (not all important points to consider), this based on my recent experiences.

LESSON 2 : Notification

Do make sure that the company is required to notify of a "Trigger Event" in good time before the event. If not you will be in a situation where a transaction is going ahead without your knowledge, and there is little you can do about it, if you don't know about it.

LESSON 3 : What is a Trigger Event ?

Make sure the contract clearly states what constitutes an event and under what conditions you will be able to participate in the transaction. Companies structure all kinds of transactions in convoluted ways, you want to ensure that you are able to participate irrespective.

LESSON 4 : Directors discretion

Leaving things at the discretion of anyone in a contract is good for the company and not so good for you. As much as possible you do not want to leave things to the discretion of the directors, if they are not sympathetic to you the outcome for you is unlikely to be a good one.

LESSON 5 : Leaving employment

Make sure that it is clear what will happen when you leave your employment, make sure when you leave you explicitly obtain confirmation of the number of vested options that you have. Also check the clauses that relate to the expiry of these vested shares. Many contracts will have a fixed time limit, some might try and put other clauses in that restrict you once you leave employment.

Further lessons

Option holders are not shareholders, in some companies they will be treated with a great deal of respect and will be informed and be kept up-to-date with developments in the company, however, in others they will be not. The company does not have a legal responsibility to update option holders as they do for shareholders. It is worthwhile maintaining good relations with former colleges and shareholders, who may be sympathetic to you should things go wrong. As an option holder, if you have a bad contract and have no relationship with the company you hold the options in, you may be in the dark and left out to dry. It is important to ensure your rights within the contract, but also maintain relationships.

If things do go wrong

You want to make sure that you

Inform all the directors of your situation, some may not be aware of the details.
Inform the buyers, if a deal is going ahead - again they may not be aware
Inform the shareholders
Any other stakeholders you can think of (without opening yourself up to liable claims).

When you contact anyone, stick to the facts ! Option contracts are a contract between an individual and a company. It has nothing to do with the amount of work or the quality of work, when things go wrong treat it unemotionally as a contract, an agreement, a promise. The circumstances surrounding that agreement are less important than the agreement itself.

Insights & Suggestions For Effective Software development

2020-09-01T05:02:00.000-07:00

I decided to note a few observations on software development based on my experiences with a number of clients over a long career, this is work in progress and would appreciate any further input or comments.

Topics

Data science needs systematic approach
Without Specification you are in trouble
Interview for excellence
Agile does not mean "do nothing"
Devops first is not always productive
Too many resources is as bad, or worse than too little
Design before Develop, before Deploy

1. Data Science needs a `Systematic Approach`

We live in a `Data Science` age, it's a buzz word. We have always had data science in some form or another, it's just that the availability, techniques, compute power and volume has exploded over the last few years. Principles are not new, they are standard engineering practises, however, in the new generation of `Data Science` these standard practises are often overlooked.
Here are some general rules-of-thumb I have noted down :

It makes no sense to use machine learning to correct bad data that can be corrected by improving the data sources themselves. Machine learning in general should be used to clasify data to gain insights.
Machine learning or other `learning` techniques are not guaranteed to converge, you should use these techniques with caution, certainly should not rely on them as a primary source of truth.
Models work under certain conditions, you have to take the superset of possibilities into account as well.
Developing an algorithm that works on a sample clean data set, is only the beginning of the problem. Running it in production with real data (maybe real-time data) is another matter all together.

2. Without Specification you are in trouble

Somehow the message behind the [Agile Manifesto](https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/) has been lost in translation. Most often I see organisations where the term `agile` is used to mean `no process`. This includes starting projects without any `specification` of what the project is or what is being built. It's `agile` and so it will be worked out as the project evolves. It's easy to reason away this lack of process, especially in an environment with rapidly changing or complex requirements. Further if you throw enough resources at something, you might even produce an output.

You should always specify what you are doing, even if you are completely and utterly wrong !

This seems to be the most obvious statement of all time, however, time and time again I find software projects without specification. This then leads to a host of secondary problems; poor or no estimation; arguments or organisational confusion; lack of accountability; poor performance and others.

If you can't specify what you are doing, you can't estimate how long it will take and you therefore can't tell what resources you will need. Your standard project management triangle (scope, time, resource) is thus broken and all the vertices are variable. Immediately the project is doomed to either fail or underperform.

You have no accountability - without written definition, it is simply a `he/she said, he/she said match`. You also cannot iterate effectively, as there is no known starting point. You cannot negotiate, as nothing is defined and most importantly you cannot design !

The entire software development process starts from definition, even if this is for small chunks of the entire system. `Agile` methodologies have various levels of abstractions, Epics, Stories, Releases etc. There is a reason for this, most methodologies focus on how to write definitions and how to thereafter, estimate and allocate.

Without estimation, you cannot allocate resources and therefore you cannot produce roadmaps, this means that the business has no visibility of what it is doing, this is a recipe for disaster.

Further without specification, organisations tend to skip the architecture step and then the outcome may or may not converge on something robust and efficient. In fact the likelihood of producing not only bad software, but software that cannot be maintained is very high.

A good test to determine how well your project is defined, is to monitor how long the development team can go without leadership interfering or answering questions about features. If the product owner is constantly having to have meetings to explain things then it is probably not very well specified.

3. Interview for Excellence

In an environment where skilled resources are hard to find, it is tempting to be more flexible on the requirements in order to get `bums on seats`. This is a very dangerous game, engineering excellence needs the right team, with the right skill set and the right attitude, anything less and you are setting up the organisation for `engineering non-excellence`. The interview process should be taken very seriously and be very systematic.

Software is built by people, and it is very important to get the right people and the right teams in place. Always favour quality over quantity (unless there is some other hidden motivation).

4. Agile does not mean `do nothing`

As previously mentioned, `agile` is not a synonym for `do nothing` or `leave it till later`. Effective agile development requires a significant amount of planning, domain knowledge and `hypothesis testing` (from the Lean methodologies). Do not allow projects to drift without direction, be systematic in your approach.

5. `Devops` first is not always productive (working code first, devops after)

We live in a world of `Devops`, cloud services, where servers can be spun up from the outset to compensate for poor quality engineering. If you can get software working without these services in a reliable manner they will no doubt work well with these services. However the opposite is not true. We often spend far too much time using the latest and greatest managed service without focusing on the core functionality and robustness of the software we are building. When things go wrong, they will go horribly wrong and best case have a much higher than needed operational cost. Don't let `Devops` be an excuse for poor engineering.

For a description of some potential issues see `Release It! 2nd Edition pg 46`.

Buggy code can in some ways be compensated for by `autoscaling`, but beware of a large bill !

6. Too many resources is as bad, or worse than too little

`The mythical man month` springs to mind, throwing resources at a problem is not always the best way to solve a problem. Often this leads to poor results, frustration and other organisational issues that are very hard to solve down the line. If you can effectively solve a problem with careful thought and limited resource, you are sure that that the problem solution has been thought through and is effective. Simply throwing more resources at a problem, does not mean that you will solve the problem quicker. In fact it might slow you down.

* It takes time for new people to bond with a team
* It takes time for new people to understand complex problems and projects
* Each new person adds a management overhead
* Team which are too large are hard to manage

The phrase `too many cooks in the kitchen` also comes to mind, you don't want a lot of people and personalities justling with each other, this is unproductive.

7. Design before Develop, before Deploy

Before one jumps in and starts developing, there must be an element of design. It is fine to prototype in order to inform design, but the prototypes cannot become the thing that is deployed. Too often proof-of-concept's somehow become the real thing and land up in production. For obvious reasons, this is a bad idea.

It is always a good idea to mock the UI, and use this to help the UI designers figure out how they are going to develop the application. However, it is not a good idea to use the UI mocks as the specification for the product, especially since it misses out all the backend considerations and the non-functional requirements - which in complex systems are vitally important.

Challenges Facing IoT Systems in 2019

2019-06-30T12:18:00.001-07:00

Challenges Facing IoT Systems in 2019

There is no doubt that we have made significant progress in many key components of IoT systems, in recent years. These developments have in fact made IoT possible. Computer hardware has come down in cost, size and price. For many the Raspberry Pi and other similar devices has facilitated the ability to experiment and innovate, this coupled with the huge open-source community that has provided operating systems and tools that unlock these devices.

Mobile and other communication networks have improved driven by the demand from initially mobile phone users. This has also driven the development of mobile devices, which has driven improvements in batteries, screens, sensors and the entire software eco-system that runs on these devices.

With all this development, there are still a number of significant challenges. In order to roll out significant quantities of IoT devices, there are opportunities to improve deployment solutions. we live in a world of orchestrated containers, whilst this has created significant progress in terms of continuous deployment these technologies are network intensive and will require further refinement to work in a performant way in an IoT context. Engineers in IoT face similar challenges to those who tackled the large data scale issues 10 years ago, however with more constraints.

The logistics of deploying large volumes of sensors is prohibitive and hence dynamic software updates are almost mandatory.

With the vast number of devices deployed, dynamic updates and the importance of the systems that become reliant on this data, security becomes a big concern. We need mechanisms that ensure data validity and authenticity in a way that is effective and performant.

Bandwidth is improving, but this is being consumed by the volume and the number of applications for IoT data. Hence bandwidth remains and will possibly always remain a constraint.

With the proliferation of devices, we have challenges around processing this data. Technology is emerging that can capture and process huge volumes of data, however, the technology and tooling around these technologies requires further development.

Hanging off all this data gathering, we are developing data models and machine learning models, there are significant challenges deploying these models. In many cases, we have sensor data, which need to be processed, this along with more static data, such as location, geographical, weather or other data.

Along with all of the above, we need systems to monitor the entire network. In many cases we cannot consider the IoT devices as "Edge" devices, rather they are becoming "part" of the network, and as such need a sufficient level of monitoring to ensure that the overall system remains reliable and stable.

Whilst IoT has certainly opened up the realms of possibility, it brings with it new challenges that we are yet to completely solve. We might look to how we solved similar problems in the past and apply some of that thinking to the new context, or we may have to look for new innovative approaches.

Developing on the Move

2018-11-19T12:03:00.000-08:00

I am constantly amazed at the rate of progress in Software Development. Years ago, I recall writing tedious scripts using PERL, TCL and EXPECT to log into Switches and issue commands to provision them. Today we have Docker, Ansible, Kubernetes and a host of other tools, we have advanced compilers, transpilers, linters, formatters and various other tools. We can provision infrastructure on the cloud in seconds and then build complex systems quickly and efficiently. Obviously this means that the systems themselves can become ever more complex.

Computing power is such that AI now has practical applications, natural language processing, computer vision and other applications.

It occurred to me on my lengthy, rainy bus journey home this evening that the next step in our development evolution might be the ability to develop software and systems on the fly. I would love to be able to develop systems whilst I walked in the park or sat observing a lovely view. Would it be possible to talk to an interpreter and then run some process on the output to generate the code and the systems I am developing.

Presumably, we would need to define a language of common constructs that is extensible. Something like :

Project create
File create index javascript
Function create test
AWS Provision EC2

Each developer could then using some "modules" that where kept in a open-source repository run some parser on these instructions and produce some output, which would include code, in a language of their choice and DevOps in the technology of their choice. The system would need a language definition that could easily be extended

Interested to hear the thoughts of others on this ...

Caution: The DevOps explosion

2018-06-28T14:06:00.001-07:00

Everything in moderation - Let's not overdo the DevOps !

Recently, working as a startup CTO and adviser, I have seen what I call a "DevOps" craze. Developers, especially younger ones seem totally swept up in the DevOps revolution. Continuous deployment, auto-scaling groups, hot back-ups, containers etc etc.

Many times these implementations, whilst impressive, are unnecessary for the stage of the company or the product development. Many times, they are difficult to document, relatively expensive, difficult to maintain and can be hard to debug. In many circumstances, it would be far easier to have some old-fashioned deployment or back-up scripts until the company or product has some traction in the market and there are the resources available to properly administer the complexity of the DevOps setup. This is somewhat of a paradox, initially it would seem that by automating many of the mundane operational tasks that the development team face, you would be saving not only time and resource but also money. However, this is not always the case. Like anything you should implement exactly what is needed and not more. Many service providers make some of these DevOps tasks almost trivial to implement (individually) that the temptation exists to over-engineer the DevOps. This should be avoided.

The main reason to avoid over-engineering of DevOps is not the potential to loose control of cost, it is not the risk of spending much needed development time on DevOps tasks. The main risk is creating an overall system that is reliant on a number of DevOps tool providers, which when used in conjunction create systems that are unnecessarily complex to understand and maintain. For example you push your code to source control, which integrates with another 3rd party, this runs some unit tests and pushes to production servers, these servers have a number of containers that are "networked" together and there servers themselves have various firewall rules and scaling rules etc etc. One can see that this can get very complex, very quickly. Yes, it's wonderful to have these tools and in principle it is wonderful conceptually. But is it really needed ? How often do you really need to deploy to production ? How difficult is the deployment ? How many people take the time to properly document the DevOps configuration and setup ? Is DevOps becoming a risk to your business ?

If you are not carefully managing this, DevOps can become more of a risk than a asset to the business.

Sometimes, less is more. Everything in moderation - especially when it comes to software engineering.

Hire for Engineers not for Frameworks

2018-06-02T16:06:00.000-07:00

I have been faced with hiring great engineering teams on a number of occasions, I am constantly amazed at home many hiring managers and recruiters seem to focus on particular technologies and experience in those technologies.

My experience has taught me to hire engineers and I have always viewed the technology as a secondary consideration. I always focuses on a grasp of engineering fundamentals and not on information about some current or past technology. In our current world these technologies are out of date by the time the ink on the contract is dry.

Recently, I was approached by a leading company for a very senior role. The in-house recruiter laid on his wonderful resume with world leading software companies before affording me the chance to explain my career-to-date. He then proceeded to ask me a number of questions on specific Java libraries and how they were used. This is all information that is readily available on reference sites and in API documentation and does not highlight any engineering ability whatsoever.

Unfortunately, this practice is common place. Hiring tests are geared to determining how good someone is with a particular language or technology and not how good they are at thinking or learning a new framework or technology.

I have never hired teams this way. The best engineering or software teams are made up of good solid engineers, who can solve problems and can adapt to a very fast paced and moving technological landscape.

The issues with GraphQL

2018-05-16T03:23:00.000-07:00

I recently wrote a little about some of the issues with a technology like GraphQL. Whenever a new technology emerges that claims to solve age old problems, one has to look closely at the assertions made.

In the case of GraphQL the following is listed on their website:

Ask for what you need get exactly that
Get many resources in a single request
Describe what is possible with a type system
Move faster with powerful developer tools
Evolve you API without versions
Bring your own data and code

The How to GraphQL describes GraphQL as "the better REST"

No more Over and Under fetching
Rapid product iterations on the frontend
Insightful Analytics on the Backend
Benefits of a schema and type System

Whilst many of these assertions may be true, the reality is that they also can cause significant problems. Like anything in engineering, there are always trade-offs.

Asking for what you need : The backend or API has to be able to generate the queries that will give back the data as requested. As your project grows, if not carefully managed, the queries get bigger and more convoluted - eventually slowing performance and becoming unmanageable.
Getting many resources in a single request: Produces similar issues to the above, furthermore if not managed, can yield a system with many points of failure. If for example one of the sub-queries is not returning valid results or performing - the entire system can suffer (unlike REST).
Evolve your API without versions: Whilst this would seem like a great idea, the reality is that in a complex graphQL implementation, if something goes wrong on the backend - it is much more difficult to debug and has the potential to significantly impact the system. You have to ensure that any changes to the API are backward compatible and don't break the system. You might once again revert to having versions.
Bring your own data and code: This alludes to the fact that the caller is oblivious to the backend data-source. No different to REST.

In the How To Blog Post mentioned above:

No more Over and Underfetching: This is simply not true, front-end developers will always take the path of least resistance - often not considering performance. In a REST world they may have had to make multiple queries to populate a web page (for example). Since you are now providing a mechanism where this can be done all at once, it will happen. Over-fetching is a big problem in GraphQL implementations !
Rapid Iterations: Yes, this is true - but the quality of the overall system is impacted.
Insightful analytics: I found it much harder to measure the API performance in a GrpahQL world than in a REST world. Afterall, in a REST world one can simple analyse each route and easily find bottlenecks. This is not the case when there is single end-point.

In summary, whilst GraphQL is another tool in an engineering toolbox, it is not a miracle solution. If not managed carefully, it can become a problem in complex projects for the reasons mentioned above. Claims that are made by the creators of new technology must always be evaluated and not taken an face value.

The Myth of Machine Learning

2016-11-15T03:52:00.000-08:00

Recently there has been a surge in the number of companies claiming machine learning capabilities, from startups to large organisations. The media is full of "machine learning" claims, investors seem to be dropping large amounts into startups claiming to have "machine learning" or "artificial intelligence" capabilities. From Logo design companies to delivery companies, they all claim to have implemented "machine learning". I recently saw a press release for a US based app development company that had raised a significant 7 figure sum, claiming they had developed "Human assisted machine learning" ! One has to ask, what is that ? Any machine "learning" has to be assisted by humans anyway, who would configure the algorithms, applications and hardware, not to mention the training ?

Neural Networks and AI genetic algorithms have been around for a long time. So why now ? The answer is data (and to some extent computing power). In order to even attempt to do anything smart with "learning algorithms" one must have large sets of data. Since "Analytics" we have that data, sensors and devices connected to the Internet and mini-computers in our pockets, always connected. So gathering data is not a problem. The problem is what to do with the data.

Fundamentally (despite outlandish claims by the media) , Neural Networks can be "trained" to classify sets of input data into categories.

The diagram above shows a plane in 3D space that separates two sets of data (classification). If we project that plane into 2D space we have a non-linear equation.

If there is a means of determining if the classification was successful or not the classification can "learn" as the input evolves. Most current claims of "machine learning" are really simple rules that are able to cluster input data, there is nothing much too these claims. These are more like the old "expert systems" which have a pre-programmed set of rules that help the computation determine some output result. You can imagine this as a large set of IF THEN statements. It is a myth that these systems can learn or that there is any form of "intelligence" in these systems. Somehow we have jumped from these very limited capabilities to machines running the Earth. I guess the one thing we can learn from the media of late (BREXIT and Trump) is that you can't believe what you read !

Whilst I am positive that there are some very clever people out there working on all sorts of clever algorithms, I feel that propelled by media hype there is a big myth surrounding Machine Learning. In some ways it is in the interests of academics, business leaders, marketeers ect. to promote this myth as this fuels their funding.

The CTO journey: 5 Things I have learnt

2016-06-16T08:26:00.004-07:00

I remember hearing a quote from Herb Cohen, the respected US negotiator. It went something like "I never get called when everything is going well, I dunno who get those calls, but it ain't me !". This is true of many startup CTO's. Usually there is some failed outsourced relationship, or a technical co-founder who takes the product to a point and then gets stuck.

I have received many calls over the years and the problems are usually similar. This was indeed the case at my current position. Here are some things I have learnt ....

Focus on the core product: There will be a lot of noise around the product, features that are not essential, wish lists, dreams. Stick to the basics ! Unless you get the fundamentals sorted out there is no future for the product. This requires single-mindedness, and possible a few "debates", the founders will want to get as many features in the product as possible. Don't give in ! The main role initially is knowing what NOT to do ...
Mostly use tried and tested technology: When you are launching an MVP, or you have to deliver a core product quickly. Use technology that is well established and well documented. The experimental innovative stuff can come later. There is still plenty of room for innovation withing the confines of established technology.
Solve first - automate later: Often there are great ideas/features that will automate some process or some workflow. Often these can be done manually or can be done for example by writing some simple scripts that aid the process. Get these "manual" or "semi-automated" ways of doing things done first before jumping in and automating. Initially, there is often no need, no scale and within a changing environment it does not make sense to automate processes that are constantly changing or evolving. This can come later.
Protect your developers: whether you have an outsourced relationship or an in-house development team. Developers, designers etc get fatigued by uncoordinated feedback. Make sure that feedback (bug reports etc.) are handled in a coordinated fashion. The quickest way to destroy job satisfaction is by allowing everyone in the team to point out deficiencies. Also if you are outsourcing development, you want to keep the relationship sound. Protect this relationship.
Manage expectations: It is always good to over-deliver and under promise. Be realistic and communicate this at all times. So many times problems are caused by engineers saying what they think they should, as opposed to what they know they should.

Writing this today, I feel as if yet another journey has been undertaken and I start the next phase with our team at Knowledgemotion. We have secured investment from Ingram and signed a major deal with Pearson. They next phase will be taking the core product further, and hopefully beyond and expectation !

Shold Cloud Computing Costs be Regulated ?

2016-05-15T12:54:00.001-07:00

I am not one for bureaucracy, in fact the contrary. I cringe at unnecessary bureaucracy and regulation. The face is that we are becoming a more highly regulated society, that being stated, I do feel there are some areas where we need regulation to protect the consumer. One such area is the regulation of costs by commodity suppliers, telecommunications, energy, fuel etc.

As CTO of a emerging start-up I am responsible for ensuring that our systems run on the latest and most secure technology. Cloud services provide that scalable infrastructure and so naturally I use them extensively. However, let me tell you a story of one warm Friday night last July.

I was just about to go on paternity leave and settling down in my lovely new bath for a Friday night soak, when the phone rang. A chap was phoning from Amazon Web Services (AWS). He politely enquired if I was aware that our company had just incurred over $20 000 dollars of charges transferring some data from Glacier to S3 storage. My heart skipped a few beats, at that stage in our companies life the $20K would almost certainly bankrupt us and leave me without a job on the eve of the birth of my son ! Needless to say, I expressed my horrer at this news and began the long-winded process of composing various emails to Amazon to recoup the money.

Earlier in the day, I had read the AWS pricing guides relating to Glacier. I found them to be rather complex but I ploughed through. I have some ability in mathematics and two engineering degrees, I thought might assist me in understanding how to calculate the cost of transferring some data. I took out a pen and paper and after a long-winded calculation came up with a figure of around $300. I double checked this and when I was certain instructed my team to make the transfer. Obviously I got the calculation slightly wrong, by a factor of about 100 !

This is not an isolated case, I have heard of many very qualified engineers tripping up at computing cloud computing costs. This is because the pricing always involves a number of very elusive quantities, data transfer per unit of time. CPU minutes used etc etc. These quantities are very hard to calculate a-priori and have never previously formed part of and computational analysis.

I think it is time that our regulators take a look at these "Cloud services" and set some guideline on fair and understandable pricing. Afterall Cloud computing services are just another commodity supply that is crutial to the way we live and do business. We cannot be (a) held to ransom and (b) confused to the point where we are unable to accurately calculate the future costs.

The story ends well, AWS refunded the money. I have been slowly transferring my data ever since.

Implementing Product Development Methodologies across Cultures and Organizations

2014-07-24T05:41:00.001-07:00

Implementing Product Development Methodologies across Cultures and Organizations

After experience at trying to bring various methodologies and ways of approaching product development to different types of organizations in different countries, and often not succeeding as well as I would like, I thought I would attempt at finding some explanations.

I currently think of 3 dimensions that are the most important in terms of how they impact a generic methodology or approach. This is not an exhaustive list, however, after much thought these are what I feel are the key contributors to success or failure of putting an effective methodology or approach in place within an organization.

Communication

The way that people communicate within the organization or team significantly affects the process of product or service development. Different cultures communicate in different ways, some more "open" others more "closed". Some "hierarchical" others less so.

Language can also be a problem, often nuisances are lost in translation. The same holds true when communication is between differing teams within an organization, i.e between the technical staff and the marketing department.

Key dimensions of communication:

Open or closed communication
Inter departmental or organizational "translation" issues
Hierarchical communication path
Conflictual or Non-conflictual

Planning

Planning is related to communication, but the way in which planning is conducted and the hierarchy of stakeholders, how they get involved and who has the final say, differ. Also the way in which different cultures follow a plan differ, some might use it as a "loose" guide and others might use it almost in a "biblical" fashion.

Some organizations skip the planning stage or do not believe that it is needed or productive. Others won't do anything without a comprehensive plan, they may be paralysed by "not knowing".

Key dimensions of planning:

Valued or Avoided ?
Loose guide or biblical ?
Rapid or slow ?

Decision Making

Who makes the decisions is very important, in some cultures the leaders has the final say and is not argued with, in others he is guided by staff. In some cultures even if an idea comes from a team and is well thought out, any idea that comes from senior staff is immediately seen to be superior (observations in Brazil). Other cultures need consensus (observations in Japan) and things cannot progress until the entire team is convinced of the idea.

Key dimensions of decision making:

Leader driven or consensus
Logical or political
Rapid or Slow

Summary

Agile and Lean thinking in Japan

2014-07-22T05:37:00.001-07:00

I have just returned from Japan, where I was involved in leading a workshop on Agile and Lean thinking. Being back in the UK, I am reflecting on how things went, what worked and what did not. The whole experience proved to be much more difficult than I could have imagined.

Japanese culture does not seem to be compatible with Lean or Agile approaches.

Consensus is always needed
Time spent on a problem is the primary indicator of effort and success
All expressions of ideas need to be well thought out (brainstorming is not natural)
It is natural to delay the commitment of an idea or an approach, so decision making is delayed to the last moment

These observations are in total contrast to the Agile or Lean approaches, which value "efficient communication", "lists", "brainstorming" and rapid decision making.

This is probably why these Technics have not much of an adoption in the Japanese business world. If I were to revisit this market, in terms of helping with my consulting efforts, it seems as if I would need to tailor my methods to work within the Japanese context or I would have be very confrontational to get the desired outcomes. I plan to write more on this topic in the coming weeks.

When we apply our methods and methodologies in different cultures we should be aware of the context. Business methods and techniques are inherently centred around communication, decision making and planning. However in different cultures, communication, decision making and planning are conducted in very different ways. This could possibly be an explanation for why many methods don't work well across borders or regions, furthermore it could explain why internationalization remains difficult. It is not only about the product, but the process of bringing the product to market.

Interestingly "ThoughWorks" recently published this article http://www.thoughtworks.com/radar/#/
In which they allude to an aspect of this issue:

Conway's Law, that states that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations", keeps appearing in unexpected places. One of the key tenets of the Agile Manifesto is "People over Processes and Tools", and we see Conway's Law reinforcing this idea both negatively and positively. Some companies are mired in siloed structures that add needless friction to engineering efforts, while more enlightened companies use team organization to drive the kinds of architectures they want. We're learning the peril of ignoring Conway's Law and the benefits of leveraging it.

WebSockets is the way forward

2013-10-02T04:13:00.000-07:00

One of the great frustrations of developing any Web based software system is the request driven paradigm that the HTTP protocol demands. The user sends a request and the server responds, based on some further user interaction further requests are sent and responded to. There are clever ways of circumventing this behaviour, but they have all been rather messy.

One big problem is that a request is generated on the client side either in HTML code or in some Javascript and then handed off to a handler on the server, there maybe many such handlers for different types of request. The response is then handled on the client side somewhere. It all get`s rather messy keeping track of where the request responses are handled and maintaining state. It reminds me of the bad old days of BASIC, where the GOTO command caused execution of the program to jump around. As code grew in complexity it became very difficult to track or debug. Developers were always discouraged from using GOTO unless absolutely necessary. The current web architecture is effectively a mesh of such GOTO statements.

WebSockets re-introduce a much more logical networking paradigm. A connection is opened, where two-way communication can take place. It is much easier to maintain state between the client and server and the resulting code is much more logical in it`s flow. Effectively a client browser session becomes a two-way messaging session, where either side can request and respond. Not only does it open up new possibilities, in terms of functionality but it also makes the resulting code much more intuitive and maintainable. A standard client-server architecture can now be applied to Web applications.

I have recently started learning Node.js and Socket.io which has the added advantage of being almost entirely Javascript based. This has the added advantage of not having to switch between client and server side languages. Whilst Javascript is no doubt "quirky" (Closures, Callbacks and Functions passed around like potato's) , the consistency gained from sticking to one language is in itself very valuable. For one thing developers don`t have to master two or more languages. Furthermore patterns used on the server side can be reused on the client side which creates a far more homogeneous code base.

Another interesting effect, is in the design phase. Whereas previously web application design involved a seemingly complex set of interactions (depending on your design methodology), it now boils down to designing a messaging protocol. For example a standard POST (sending back form data) would involve creating an HTML form with some action (a URL) and on the server side a handler to process the data and send back a response (which may have been a new HTML page or something simpler). Over a WebSocket the same form data can just be sent as a message to the server and the server can respond (or not) as defined. The actual coding although arguably slightly neater, is not the main consideration here, rather the concept, which becomes much simpler to understand and hence design.

I am very excited to see where we can take WebSockets and the effect that it will have on development time, functionality and maintainability of Web applications.

Client responsive design

2013-08-14T04:28:00.001-07:00

We are no longer in control of the devices on which our media and services are being consumed. They are becoming more varied and numerous in their differences. This is not a new problem, we have been faced with this issue for some time. Previous best solutions revolved around detecting the device capabilities at the server side and making intelligent choices to render the appropriate, fit-for-purpose content on the user device.

This solution requires constant updating of the server side logic to account for all the new devices, this is a complex activity, prone to error and cannot possibly account for all the possible variations. Most recently there have been changes in the capabilities of most modern devices. (1) They have sufficient computing power to work out how to render their own content (ignoring legacy devices for now) (2) Most modern devices can run client side scripts to interpret data and render this data appropriately (3) We can define all web applications as services that create update or delete data based on some user action.

As computing power increases, the solution to the problem of an eco-system of differently capable devices is to develop the rendering technology that allows the device to render the multi-media content based on it`s capabilities. This removes the complexity of having to make smart choices on the server-side and having to maintain such heuristic information. We are certainly not there yet. Many, many companies face the burdon of having to develop their Internet/Mobile offering a number of times to meet the demands of the current devices on the market. Often they can only target those devices that are most popular and have to ignore those that have less market share. This has the unintended consequence of further marginalizing the small players in the market, since their users cannot consume the media that users of the more popular devices can.

Although it is not in the best interest of the major players to do so, I believe that we will move to a more "open" system where media will be delivered and interpreted and finally rendered by the device. This requires some significant work in defining standards and frameworks that will allow this to happen.

Coming Soon ....

2013-08-09T12:01:00.001-07:00

It's all about data ! Bandwidth will become more freely available at lower cost. Mobile Bandwidth will increase also with cost reduction as technology scales (4G, WiMax etc).

As this is all happening the Mobile device, Tablet, Laptop, PC and TV are converging. They are currently different devices, however the operating systems (e.g Android) and the user interfaces are going to continue to converge. Cloud (or remote) storage and services will mean that devices are less dependent on physical hardware on-site and almost entirely dependent on the Internet connection and local processor (see for example Dell's USB stick PC, Rasberry Pi or BeagleBone Black)

As the operating systems converge and thus the user experiences, developers will have more incentive to develop frameworks that work across all devices. Already technologies like WebRTC are being developed to allow complete media transfer between browsers on any device. This means file sharing, video, photo's without any special plugin software or application. Furthermore the possibility of phone calls direct from the browser (goodbye Skype ?) with technologies like SipML and Phono, built on WebRTC. So we are not far off making voice and video calls direct from our Internet enabled TV's.

The standard house or office phone is not going to be with us for much longer and the trend for telecommunications companies to handle more data rather than voice is going to accelerate. There will be a tipping point when the browser and device support is good enough to mean most households and businesses will be changing their telecommunication systems to be purely Internet (VoIP) based. How long after will most mobile calls also be delivered over IP ? Eventually new mobile specifications will be purely data based, i.e there will be no signalling and protocol for standard voice calls as there is today.

Touchscreens, gesture sensitive devices, voice recognition will integrate these new user experiences further into our daily lives, less typing and more speaking, moving ? Nod to call mother, cough to see webcam of the garden etc ...

Things Entrepeneurs should not pay for ...

2012-10-02T13:50:00.003-07:00

Following my previous post, here are a few things that I don't think entrepreneurs should pay for.

Networking

I do not believe that paid networking events are necessary. There are many very good, free networking opportunities, especially in big cities. There are meetups, forums and many avenues to try before one needs to pay for a networking event. It might be worthwhile joining a long term group, but my experience of one-off paid events has always been a poor one.

Pitching

You should never pay to learn how to pitch, there is a world of information, examples and resources for free out there. You should use your family and friends as soundboards for your pitches. There is absolutely no reason to pay to learn how to pitch. For that matter, I don't believe you should have to pay to pitch to investors (for example). Investors struggle more to find good opportunties than entrepreneurs struggle to find investment. As an entrepreneur you need to target the right person or people to pitch too and not have someone else organize this for you.

Business Plan Writing

You should never pay anyone to write a business plan for you. It is the process of writting a business plan that is important and not the plan. Most sensible people soon realize that the business plan is mostly conjecture and not really a plan at all, at least not one that conforms to reality. Wirte the plan yourself, in so doing you will be learning. Don't pay someone to write it for you. It simply does not make sense to do so ! By the way the endless and boring debate over what should go into a business plan is a waste of time. Depending on the context of who the business plan is going to, it needs to be good enough to get their interest. Don't waste valuable time fretting over what should and should not go into the plan. Should it be a pitch deck, should it be 50 pages, should it be double spaced. Who cares ! There are great books that are short, others that are long, so what ? Great is great ...

Simple Websites

Don't pay anyone to develop a simple website, there are many ways of doing this for little or no money. Don't waste your money. You are going to pay way more than you need to and not get what you want. At first use the free stuff out there, does your blog work for purpose, can you use Facebook or similar, is there some free template you can use, is there some cheap template off-the-shelf. Far too many people waste time and money worrying about their initial website. More important is to prove the concept and get the business model behind it solid (ignoring the cases where your entire business is hinged on the web technology in question).

Search Engine Optimization (SEO)

Don't pay anyone to do SEO, it's a buzz word and very simple to learn the principles yourself. In fact it is so important that you might as well learn something about it on the job, without relying on someone else. Also, it is not a science, so don't be fooled. Certainly early on, you want to be innovative in promoting your online existence, assuming you are interested in that. Learn how to be creative here and use the tools out that are out there, will put you in a good/better position going forward.

Analytics

Another buzz word. All someone can do with software is interact by clicking or entering data etc. This can easily be measured and the data anayzed. Don't be fooled into paying large sums for something that you can easliy do. Secondly, if you are not careful you land up with stats that you cannot process or make meaning of.

Selling the Entrepreneurial Dream is not productive

2012-09-28T06:46:00.000-07:00

There is a growing industry of consultants, incubators, accelerators, books and courses centered around the "dream" of being a successful entrepreneur. The reality is that most of the individuals or organizations making money in this space are useless. This is a sector of the economy that is unproductive and for the most part does not add economic value.

The resources that any country has can be put to use in a number of ways. If these resources are applied in a productive manner, economic growth will ensue. However, misapplying these resources can generate no growth or contraction for the economy.

In a situation where young graduates are encouraged to innovate, to become entrepreneurs without the proper support, this is an un-productive use of resources. These graduates might be better used in an existing organization (be it at a reduced rate of pay). Fueling this misappropriation of resources are a host of organizations, who make their livelihood by selling a dream, appealing to emotion rather than economic sense. All too often I hear of events entitled "Master Class" or "Pitching superclass" etc. There is no quick fix to innovation or entrepreneurship and I shudder even at the names of these events. The participants in this industry are focused on "quick" courses, quick fixes with unrealistic claims. Education and support is not a quick fix and there are no quick solutions or methodologies that will make it work. If there were, we soon would reach a saturation point, where everyone would be successful and innovating quickly (unlikely to be sustainable). However, with proper and well considered education there would be some success and at least a number of well or more educated individuals and organizations.

Today, the focus is often on raising funds, pitching creating business plans. These things, however, are secondary to developing an idea into a business. Funding, pitching and planning comes after the development of the idea which is aided by some fundamental business and economic skills. Resources would far better be utilized investigating market opportunities, teaching individuals how to validate a market and helping with process development (how to develop business, software and other processes).

The road not taken and the death of traditional retail

2012-09-10T06:41:00.000-07:00

Fuel prices are increasing and they are unlikely to decrease in the near future. Time is valuable, in our fast paced lives it is a valuable commodity. Moreover, the amount of specialized products is also increasing and this trend is likely to continue.

The true experience below illustrates why traditional retail is dying and why data overload and inaccuracy is also going to become ever more costly. We will all need to use technology in more productive ways and once implemented to maintain the data which is an integral part of digital technology.

My grape vine arrived overnight in the post, ordered online and delivered by a courier company. The online instruction video insisted on planting quickly and using a "friendly" fungi applied to the roots, called "Mycorrhizal Fungi". I hopped into the car and headed down to the huge home superstore 7km from my house.

Once there I headed for the gardening section and scoured the huge isle for the Fungi. There are hundreds of fertilizer and other products in this section and despite taking my time, I was unable to locate the product. I was also unable to locate a staff member sufficiently experienced to know what this product was. The first few sent me on a wild goose chase around the building. Finally, I went to information and we were able to ascertain that the product does exist, but was out of stock.

I then did a search on Google for a nearby garden center and headed to the car. I followed directions, through heavy traffic, only to discover that the Garden center had become a garden training center and did not sell products to the general public. The data online was out-of-date and inaccurate. This episode took me 3-4 hours and I was unable to locate the product.

I arrived home, went online, found more than 5 suppliers of the product, purchased it and it arrived the next morning.

There is nothing very profound about this experience, however, it highlights the deficiencies of traditional retail. It also highlights the fact that generalist data sources will be hard to maintain and always develop inaccuracies. There will always be opportunity for niche databases that are limited in scope, but well maintained and accurate.

Traditional business will certainly continue to need to update their information infra-structure and online presence, meaning they will undoubtedly need to contract-in or develop competence in new technology areas. The ability to do effectively do so relies on human resources who are well versed in the application of this technology. This is an area which I feel has lagged behind the technology itself. There is little information, on how to evolve a business in this way and put more simply there are not very many good resources which deal with the process of software creation, whether it be a database, website or system of bespoke software ( this is the reason we created OpenCTO , in an attempt to improve the quality and dissemination of this information )

If, as trends suggest, we are heading to an ever more technology orientated economy, we should logically apply significant effort to ensure that this technology is produced and maintained efficiently and effectively. This would suggest that we invest significant effort in the processes needed to apply and later maintain this technology. Is this the case at present ?

I have spoken to hundreds of entrepreneurs who still struggle with relatively simple issues, getting online, developing websites and e-commerce solutions. Ensuring that what is purchased is delivered and correctly hosted. I have heard of numerous situation in large multi-nationals of the incorrect specification and application of technology, lack of redundancy, back-up, data integrity etc. The ability to deliver this aspect of business is only going to become more essential in the coming years.

PLEASE VISIT AND REGISTER AT OPENCTO - To create, focused on start-up ideas, a standardized lean methodology and process for the conception, design and development of Internet and mobile technologies.

Define, Design, Develop, Operate

2012-05-30T03:44:00.002-07:00

Over the last five years I have met, talked too and worked with hundreds of technology entrepreneurs. Looking back I am horrified at the number of failed software projects I have encountered. From the now ex-wife, I heard about an entrepreneur who sank the family fortune into an ill-fated software project, outsourced to India. I met with the entrepreneur who had developed a web application without ever specifying it, naturally it never worked. I consulted with the astute businessman who after eight years was still nowhere near developing his software idea, due to a lack to sound technical knowledge, a lack of specification and software developers with no methodology. Moreover, I have received more calls than I can remember from disillusioned entrepreneurs who have fallen out with software developers, have systems that they want fixed or simply cannot get their vision implemented (in software).

In my view, these failed software projects are a very unproductive use of valuable resources, which, could be used for far more productive activities. Why do so many technology entrepreneurs fail ? Most of the cases above might very well have failed from a business perspective, however, most of them will never get to test their business models, as they will have failed way before they get to that stage. Why is this ?

If I were having a house built for my family, would I do so without specifying what it is I wanted ? Would I do so without sitting down with a professional and writing or drawing a specification, architecting my home ? Would I commit my money and time without seeing a viable plan and understanding the method by which the construction of my home would be created ? Would I not have a budget ? And finally, once my home is built, would I move in without making sure it is as I wanted and safe for me and my family to habitate ?

Why then do entrepreneurs, software engineers, project managers and technology developers undertake projects without following common sense practises that we see all around us in other disciplines ? This is a rhetorical question, but I would like to put down some of my thoughts on this :

Although software is used, it is not physical. Being an abstract thing, it is often treated that way. Abstract things are harder to imagine, harder to measure and generally harder to deal with.
Unlike hardware, the physical constraints imposed on software are very weak. This is especially true as speed and space become much less of an issue.
The seemingly endless availability of software frameworks, libraries and technologies makes the software development eco-system a very confusing place. There is too much choice ! This choice is hard to manage.
Hardware design does not change significantly as compared to software, over time. The software eco-system is moving very quickly and this adds confusion.

In order to ground software engineering, we need to impose self-constraint. The more self-constraint we impose the easier the problem space. Contrary to what is practised in the world at the moment, we need more design discipline than for physical design, not less. If we stick to the fundamental basics of specifying what we want, designing the system, implementing the system with a consistent method and then testing and measuring what we have built, surely we can increase the rate of successful software projects ?

Please visit the OpenCTO project where we are trying to create better software development processes and methodology.

Tech Entrepreneurs - Problem of the CTO

2012-04-20T03:55:00.000-07:00

Focus on the development process

The biggest problem is not money or resources, it is lack of knowledge in undertaking the development process. Effort should be focused on creating an "open-source" development process for web-start-ups with a complete series of artifacts for them.

Process Model

Most web-start-ups that get past the concept phase, fail not due to lack of resources, rather they are unable to use the resources they have effectively. Most software projects are problematic, and for start-ups the problem of getting software developed in a efficient, painless way is a major problem. Little time or effort is spent in the specification phase and hence what is developed is often not what is required. We should develop an open-source framework which guides the development process.

How will your concept support web entrepreneurship?

Entrepreneurs will have a proven process to follow, which will allow them to reliably take thier concept through to creation. This will allow them to focus more on the business and remove uncertainty and risk from the "creation" phase.

What kinds of resources will be needed to get this concept off the ground and scale it?

WIll need expereinced consultants and entrepreneurs who have worked with the software and business development processes. Large technology consultancies compaines like IBM, Accenture etc might want to collaborate as they have already a large library of artifacts that would be very useful to the entrepreneur. These large organizations might also fund such an innitiative as it gives them credibility in the market and brings them very close to the "innovation" happening in the UK and elsewhere.

Interested, register at http://opencto.com

How could we get started?

A simple concept website (launched currently at http://opencto.com) and the structure of an open-source project would be needed and a comitte of credible industry leaders who could apprach other thought leaders and eperienced entrepreneurs. This committe with thier advisors would need to establish a roadmap and in a co-ordinated fashion start the collation of information, which will lead to the establishment of a number of artifacts and processes that entrepreneurs can later leverage. The goal is to create a standardized set of development processes and documents for all to share.

Software design vs Hardware design

2011-12-22T06:43:00.000-08:00

Recently, I designed a circuit for a home project. It got me thinking about the differences between circuit design and hardware design. In hardware design, we operate with a set of discrete components, furthermore our design is constrained by: time, money, space, availability and power. Based on these constraints we would find well defined functional building block (components) and function by function construct a device that produces the desired output, given a particular set of inputs. This process is iterative, the design of the system follows the same process and any of the sub-systems. In some ways the constraints and the fact that inputs and outputs are well defined (making system design the same as that for sub-systems) makes the design process uniform and relatively easy. I was amazed at how deterministic my circuit design was as compared to software design.

In software design, we have become overwhelmed by the number of components, the complexity of the inputs and outputs, computing power is not and issue and time and money are not that easily measured a-priori (as they are in circuit design). The effect is that software projects are often not well constrained, can explode in complexity and the system design process may differ from the sub-system design process. Initially computer scientists tried to solve this project by creating objects, that were meant to be functional units that had inputs, outputs and state (thus mimicking electronic components). In reality they are more complex than discrete components, as anyone can design them, they take any number of inputs, they have an infinite possibility of states and have very complex outputs. It requires a great deal of discipline to constrain a software project in the way that a circuit hardware design project is constrained.

Does Entrepreneuship Stimulate Economic Growth ?

2011-10-19T08:35:00.000-07:00

Most people I speak to, seem to think that it is obvious that entrepreneurship is one key to economic growth. This is a very modern view-point in that the entrepreneur was never really considered in neo-classical economic theory. I don't however believe that the answer to this question is as obvious as most people may think.

Economic growth is measured by a nations Gross domestic Product (GDP) which as the name suggests measures the economic output of the nation. So there must be some production or output for this domestic product to grow, this implies that the workers of the nation are adding value to some resource which previously had a lesser value (if any). This might be digging a huge whole and extracting diamonds, which are then polished and sold, or it might be using intellect and some intellectual property which is then sold around the world. Either way, no matter how you look at it, something has to be created or some value added.

If a nation has a large percentage of entrepreneurs who are not especially productive or successful, there will not be much economic growth. In fact they may be using important human and other resources in a very unproductive manner and ultimately do more harm than good. For one thing, unsuccessful entrepreneurs place a burden on the administration system (processing bankruptcy for example) they also eat up valuable opportunity cost (they could have been doing something productive in the meantime). Furthermore in nations where entrepreneurs are not especially innovative, i.e they simply replicate what already exists, they simply saturate the market with more of the same - which is not sustainable in the long run.

For entrepreneurs to contribute to sustained economic growth, they need to be more successful than not and produce a some kind of "net productivity". The role of good government is thus not only to stimulate entrepreneurs, but also to help them be successful. So some co-ordination and collaboration is essential for this to happen.

Mobile, past, present and future

2011-08-05T05:18:00.000-07:00

There is always a debate whether one can predict the future looking at the past or whether the past simply constrains our future thinking. I think both future looking and analyzing the past are useful activities in prediction.

Thinking about my career working as an engineer with mobile technology, starting in 1997 with the Motorola M301

A number of key technological elements have improved significantly over the last 15 years:

Battery

The m301 had a stand-by time of a few hours and talk time of about 20 min, the battery was large and heavy and had memory - charging a not-fully-discharged battery would lead to loss of performance. The official specs quoted the battery as "Included NiCad battery gives 12 hours standby or 70 minutes talktime".

NiCad batteries soon gave way to NiMh which had twice the capacity of the Nicad. Then came the Lithium-ion which produced the same capacity with about 30% less weight. These technologies all served to increase the battery performance and reduce the size and weight of the battery.

Screen

The m301 is quoted as having "LCD Screen including a 2 line backlit Information Display", these limited character black and white displays have given way to high resolution color touch screens. The 1997 Motorola StarTac had a 4 x 15 monochrome display.

Processing power

Phones around 1997, used the Intel 386 chip with a processor clocked at about 20 MHz (see some specs here ) of course importantly, vast improvements have been made in power management and consumption which means that modern processors are not only smaller and faster, but also use less power than those of 1997. The apple iphone 4 uses a 1Ghz A4 processor which can run HD video for 10 hours (as a comparison - see this report from Jan 2011).

Component size

Companies like MediaTek are developing mobile chipsets which integrate many modern mobile functionality (wifi, bluetooth, duel/tri band, edge etc) into one chipset and furthermore are designed to easily run modern OS's like Android. This is not only bringing down the component size of mobile devices, but also reducing power consumption and cost.

Data

Data is the key to offering a wide variety of applications to the consumer. A number of aspects are important, the storage capacity of the device (to store files) and the bandwidth available for download. Since the m301 networks began by adding GPRS which provided download data rates of 56-114 kbit/second, later Edge (max 473.6 kbit/s) and Evolved Edge (1 Mbit/s) where replaced by the roll-out for 3G technology which had data at the core of the protocol design. Modern HSPDA provides data rates of up to 42 Mbit/s. Thus mobile data rates start to rival previous generation ADSL. Moving forward 4G technology offers 100Mbit/s up to 4 Gbit/s for low mobility users.

The future

The big question is where do we go from here ? It is quite evident that R&D organizations will continue to improve battery capacity vs size and weight. Components will continue the trend to offer more processing power for less circuit board real-estate. Screen technology will continue to improve offering enhanced user experience. Mobile networks will continue to offer higher data rates (subject to capacity and investment) . All this means that increasingly we will access the Internet from our mobile devices.

Some things that we can expect:

Mobile devices become ever more integrated in our daily lives (join the debate AndroidGizmo )
Mobiles are used for payments (parking, supermarket, theater, cinema etc)
Gaming on the move become more mainstream
Continued advances in Location based services
Virtual reality browsing (things like Layer )

As the mobile devices becomes more powerful, it is conceivable that it becomes our primary electronic device, slowing replacing the PC, TV , Sat Nav and Gaming console. Plug in a keyboard and monitor (you have a PC), connect a screen and satellite decoder (your TV) or you charger in your car (satnav).

Beyond that, as form factors become smaller and more powerful there is no reason why mobile devices will not become integrated into standard items of clothing and fashion. Sunglasses for example or some device that clips onto a part of the body. GPS in combination with motion detection would make the user interface easily controlled by the body as opposed to the keypad for many applications. We could expect to see the mobile being split into units. One purchases a controller unit, a separate screen (which may be in you glasses), Separate GPS or multimedia modules. In some ways this what happened with the original home computer prior to IBM compatible PC's. Initially everything was integrated, later the marker demanded configurable peripherals - a centralized unit with many add-on's.

If we think of the next generation mobile device as a Controller unit with a number of interconnected modules, delivering differing services (e.g screen, gps, gaming options etc), we can start prediction developments in software applications to take advantage of these more specialized connected modules.

Other interesting links

The History of the mobile
Wiki 4G

Beware of the pivot

2011-08-03T02:59:00.000-07:00

A new term that is bouncing around the start-up world, is the term "pivot" which basically means to change direction or concept. Most entrepreneurs will change their initial ideas in some way at some time - this is in general part of the process of realising an opportunity. As one starts in the quest to develop a business, all the answers cannot be known prior to starting, for if they were known it would be easy - like following a recipe. Alas for most of us this is not the case, we have some notion of what things will look like and then embark, perhaps with a degree of ignorance on a journey.

Lately, I have had a number of clients or colleagues ring me up and exclaim with great exuberance, " we have pivoted !". I must say that this alarms and surprises me, changing direction should be part of the entrepreneurial process, but not an end in itself. The goal is not to pivot, the goal is to make your business a reality and if you should have to change direction along the way, so be it. But to exclaim and rejoice about the act of changing direction is not something in itself to rejoice about !