tag:blogger.com,1999:blog-7895723737857164192024-03-14T09:02:44.650-07:00Technology StrategyEverything about technology - entrepreneurship, enterprise, organization and implementationAvronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.comBlogger60125tag:blogger.com,1999:blog-789572373785716419.post-68153751464664448772022-05-31T09:35:00.004-07:002022-05-31T12:09:53.189-07:00The pitfalls of share options in the technology startup<h3 style="text-align: left;">Draft 1</h3><h3 style="text-align: left;"><b><br /></b><b>PLEASE NOTE: I am a simple engineer and this document should not be taken as legal advice in any way whatsoever. </b></h3><div><b><br /></b></div><div><b>Please feel free to comment or relate your stories here. All feedback is more than welcome</b></div><p style="text-align: left;">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. </p><p>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.</p><p>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. </p><p>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. </p><p><b>LESSON 1 : Not all option agreements are equal</b></p><p>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. </p><p>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. </p><p>Below are some (not all important points to consider), this based on my recent experiences. </p><h4 style="text-align: left;">LESSON 2 : Notification</h4><p>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. </p><h3 style="text-align: left;">LESSON 3 : What is a Trigger Event ?</h3><div>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. </div><h3 style="text-align: left;">LESSON 4 : Directors discretion </h3><div>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. </div><div><br /></div><h3 style="text-align: left;">LESSON 5 : Leaving employment</h3><div><br /></div><div>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. </div><h4 style="text-align: left;">Further lessons</h4><div>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. </div><h4 style="text-align: left;">If things do go wrong</h4><div><br /></div><div>You want to make sure that you </div><div><br /></div><div><ul style="text-align: left;"><li>Inform all the directors of your situation, some may not be aware of the details. </li><li>Inform the buyers, if a deal is going ahead - again they may not be aware </li><li>Inform the shareholders</li><li>Any other stakeholders you can think of (without opening yourself up to liable claims). </li></ul><div>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.</div></div><div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com0tag:blogger.com,1999:blog-789572373785716419.post-44465782929563459702020-09-01T05:02:00.000-07:002020-09-01T05:02:44.738-07:00Insights & Suggestions For Effective Software development<br /><div style="text-align: left;">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.</div><div style="text-align: left;"><br /></div><h2 style="text-align: left;">Topics</h2><ol style="text-align: left;"><li>Data science needs systematic approach</li><li>Without Specification you are in trouble</li><li>Interview for excellence</li><li>Agile does not mean "do nothing"</li><li>Devops first is not always productive</li><li>Too many resources is as bad, or worse than too little</li><li>Design before Develop, before Deploy</li></ol><br /><h3 style="text-align: left;">1. Data Science needs a `Systematic Approach`</h3><br />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.<br />Here are some general rules-of-thumb I have noted down :<br /><ul style="text-align: left;"><li>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.</li><li>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.</li><li>Models work under certain conditions, you have to take the superset of possibilities into account as well.</li><li>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.</li></ul><h3 style="text-align: left;">2. Without Specification you are in trouble</h3><div><br /></div>Somehow the message behind the [Agile Manifesto](<a href="https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/">https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/</a>) 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. <br /><br /><b>You should always specify what you are doing, even if you are completely and utterly wrong !</b><br /><br />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.<br /><br />If you can't specify what you are doing, you <b>can't estimate</b> how long it will take and you therefore <b>can't tell what resources you will need</b>. 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. <br /><br />You have <b>no accountability</b> - without written definition, it is simply a `he/she said, he/she said match`. You also <b>cannot iterate effectively</b>, as there is no known starting point. You <b>cannot negotiate</b>, as nothing is defined and most importantly you <b>cannot design</b> !<br /><br />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. <br /><br />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. <br /><br />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.<br /><br />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. <br /><br /><h3 style="text-align: left;">3. Interview for Excellence</h3><br />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.<br /><br />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).<br /><br /><h3 style="text-align: left;">4. Agile does not mean `do nothing`</h3><br />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.<br /><br /><h3 style="text-align: left;">5. `Devops` first is not always productive (working code first, devops after)</h3><br />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. <br /><br />For a description of some potential issues see `Release It! 2nd Edition pg 46`.<br /><br />Buggy code can in some ways be compensated for by `autoscaling`, but beware of a large bill !<br /><br /><h3 style="text-align: left;">6. Too many resources is as bad, or worse than too little</h3><br />`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. <ul><li>* It takes time for new people to bond with a team </li><li>* It takes time for new people to understand complex problems and projects</li><li>* Each new person adds a management overhead</li><li>* Team which are too large are hard to manage</li></ul><br />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. <br /><br /><h3 style="text-align: left;">7. Design before Develop, before Deploy</h3><br />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. <br /><br />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.<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com0tag:blogger.com,1999:blog-789572373785716419.post-55103752206926093742019-06-30T12:18:00.001-07:002019-06-30T12:18:48.614-07:00Challenges Facing IoT Systems in 2019<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div>
<br /></div>
<h2 style="text-align: left;">
Challenges Facing IoT Systems in 2019</h2>
<div>
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 <a href="https://www.raspberrypi.org/" target="_blank">Raspberry Pi</a> 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. </div>
<div>
<br /></div>
<div>
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. </div>
<div>
<br /></div>
<div>
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. </div>
<div>
<br /></div>
<div>
The logistics of deploying large volumes of sensors is prohibitive and hence dynamic software updates are almost mandatory. </div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
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. </div>
<div>
<br /></div>
<div>
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. </div>
<div>
<br /></div>
<div>
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.<br />
<br />
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.<br />
<br />
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.</div>
</div>
<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com0tag:blogger.com,1999:blog-789572373785716419.post-82608463729783014012018-11-19T12:03:00.000-08:002018-11-19T12:03:09.506-08:00Developing on the Move<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
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.<br />
<br />
Computing power is such that AI now has practical applications, natural language processing, computer vision and other applications.<br />
<br />
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.<br />
<br />
Presumably, we would need to define a language of common constructs that is extensible. Something like :<br />
<br />
<br />
<ul style="text-align: left;">
<li><span style="font-family: monospace;">Project create</span></li>
<li><span style="font-family: monospace;">File create index javascript</span></li>
<li><span style="font-family: monospace;">Function create test</span></li>
<li><span style="font-family: monospace;">AWS Provision EC2</span></li>
</ul>
<div>
<span style="font-family: monospace;"><br /></span></div>
<div>
<span style="font-family: monospace;">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 </span></div>
<br />
Interested to hear the thoughts of others on this ...<br />
<br /></div>
<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com0tag:blogger.com,1999:blog-789572373785716419.post-52877518929558279712018-06-28T14:06:00.001-07:002018-06-28T14:12:01.118-07:00Caution: The DevOps explosion<div dir="ltr" style="text-align: left;" trbidi="on">
<b>Everything in moderation - Let's not overdo the DevOps !</b><br />
<br />
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.<br />
<br />
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.<br />
<br />
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 ?<br />
<br />
If you are not carefully managing this, DevOps can become more of a risk than a asset to the business.<br />
<br />
Sometimes, less is more. Everything in moderation - especially when it comes to software engineering. </div>
<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com0tag:blogger.com,1999:blog-789572373785716419.post-75988855027212305662018-06-02T16:06:00.000-07:002018-06-02T16:06:18.232-07:00Hire for Engineers not for Frameworks<div dir="ltr" style="text-align: left;" trbidi="on">
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. </div>
<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com1tag:blogger.com,1999:blog-789572373785716419.post-18979397230346420222018-05-16T03:23:00.000-07:002018-05-16T03:28:17.735-07:00The issues with GraphQL<div dir="ltr" style="text-align: left;" trbidi="on">
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.<br />
<br />
In the case of <a href="https://graphql.org/" target="_blank">GraphQL</a> the following is listed on their website:<br />
<br />
<br />
<ul style="text-align: left;">
<li>Ask for what you need get exactly that</li>
<li>Get many resources in a single request</li>
<li>Describe what is possible with a type system</li>
<li>Move faster with powerful developer tools</li>
<li>Evolve you API without versions</li>
<li>Bring your own data and code</li>
</ul>
<div>
The <a href="https://www.howtographql.com/basics/1-graphql-is-the-better-rest/" target="_blank">How to GraphQL</a> describes GraphQL as "the better REST"</div>
<div>
<br /></div>
<div>
<ul style="text-align: left;">
<li>No more Over and Under fetching</li>
<li>Rapid product iterations on the frontend</li>
<li>Insightful Analytics on the Backend</li>
<li>Benefits of a schema and type System</li>
</ul>
<div>
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.</div>
</div>
<div>
<br /></div>
<div>
<ol style="text-align: left;">
<li>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.</li>
<li>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).</li>
<li>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.</li>
<li>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.</li>
</ol>
<div>
In the How To Blog Post mentioned above:</div>
</div>
<div>
<br /></div>
<div>
<ol style="text-align: left;">
<li>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 !</li>
<li>Rapid Iterations: Yes, this is true - but the quality of the overall system is impacted.</li>
<li>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.</li>
</ol>
<div>
<br /></div>
</div>
<div>
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.</div>
<div>
<br /></div>
</div>
<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com0tag:blogger.com,1999:blog-789572373785716419.post-76351433618243490272016-11-15T03:52:00.000-08:002016-11-15T03:52:41.518-08:00The Myth of Machine Learning<div dir="ltr" style="text-align: left;" trbidi="on">
Recently there has been a surge in the number of companies claiming<a href="https://en.wikipedia.org/wiki/Machine_learning" target="_blank"> machine learning</a> 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 ?<br />
<br />
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.<br />
<br />
Fundamentally (despite outlandish claims by the media) , Neural Networks can be "trained" to classify sets of input data into categories. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi8QjNHQtEQ_wjysdSvp-1DYoT321wJghROnhHhQ5Qb8NEuAJcITYLUFrKJLmH0dxLKORAAdW_wk6oPZDh_hGczLPGudh8qv34TLqqmHDBgXjqk4ABaVoOdTa4KzrNzwSEKICnvrjy0xnE/s1600/3DPlane.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="285" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi8QjNHQtEQ_wjysdSvp-1DYoT321wJghROnhHhQ5Qb8NEuAJcITYLUFrKJLmH0dxLKORAAdW_wk6oPZDh_hGczLPGudh8qv34TLqqmHDBgXjqk4ABaVoOdTa4KzrNzwSEKICnvrjy0xnE/s320/3DPlane.png" width="320" /></a></div>
<br />
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.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhhFItc19EjESBTPCbBFKob1qzvfX7i9Rg8jHnksNzO4B5ndW2-r0uUjqHyocQI8YhbKL9TUUNwjnfpjhsndUsffPi2LZU_-r4EAxJ0TyOic4MU9h9sLF4vQa9cTEG-aNHYuH31UCUnoTk/s1600/non-linear-equasion.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="209" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhhFItc19EjESBTPCbBFKob1qzvfX7i9Rg8jHnksNzO4B5ndW2-r0uUjqHyocQI8YhbKL9TUUNwjnfpjhsndUsffPi2LZU_-r4EAxJ0TyOic4MU9h9sLF4vQa9cTEG-aNHYuH31UCUnoTk/s320/non-linear-equasion.png" width="320" /></a></div>
<br />
<br />
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 !<br />
<br />
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.<br />
<br />
<br />
<br /></div>
<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com0tag:blogger.com,1999:blog-789572373785716419.post-54886798829245030872016-06-16T08:26:00.004-07:002016-06-17T05:25:52.294-07:00The CTO journey: 5 Things I have learnt<div dir="ltr" style="text-align: left;" trbidi="on">
I remember hearing a quote from Herb Cohen, the respected US negotiator. It went something like <i>"I never get called when everything is going well, I dunno who get those calls, but it ain't me !".</i> 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.<br />
<br />
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 ....<br />
<br />
<br />
<ol style="text-align: left;">
<li><b>Focus on the core product:</b> 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 ...</li>
<li><b>Mostly use tried and tested technology:</b> 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. </li>
<li><b>Solve first - automate later:</b> 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. </li>
<li><b>Protect your developers:</b> 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. </li>
<li><b>Manage expectations:</b> 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.</li>
</ol>
<div>
<br /></div>
<div>
Writing this today, I feel as if yet another journey has been undertaken and I start the next phase with our team at <a href="http://boclips.com/" target="_blank">Knowledgemotion</a>. 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 !</div>
</div>
<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com0tag:blogger.com,1999:blog-789572373785716419.post-37749877251850589062016-05-15T12:54:00.001-07:002016-05-16T03:46:56.305-07:00Shold Cloud Computing Costs be Regulated ?<div dir="ltr" style="text-align: left;" trbidi="on">
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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 !<br />
<br />
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.<br />
<br />
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.<br />
<br />
The story ends well, AWS refunded the money. I have been slowly transferring my data ever since.</div>
<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com0tag:blogger.com,1999:blog-789572373785716419.post-86402104817725564672014-07-24T05:41:00.001-07:002014-07-24T05:47:05.493-07:00Implementing Product Development Methodologies across Cultures and Organizations<div dir="ltr" style="text-align: left;" trbidi="on">
<h2 style="text-align: left;">
Implementing Product Development Methodologies across Cultures and Organizations</h2>
<div>
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.</div>
<div>
<br /></div>
<div>
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. </div>
<h2 style="text-align: left;">
Communication</h2>
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.<br />
<br />
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.<br />
<br />
Key dimensions of communication:<br />
<br />
<ul style="text-align: left;">
<li>Open or closed communication</li>
<li>Inter departmental or organizational "translation" issues</li>
<li>Hierarchical communication path</li>
<li>Conflictual or Non-conflictual </li>
</ul>
<h2 style="text-align: left;">
Planning</h2>
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.<br />
<br />
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".<br />
<br />
Key dimensions of planning:<br />
<br />
<ul style="text-align: left;">
<li>Valued or Avoided ?</li>
<li>Loose guide or biblical ?</li>
<li>Rapid or slow ?</li>
</ul>
<h2 style="text-align: left;">
Decision Making</h2>
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.<br />
<br />
Key dimensions of decision making:<br />
<br />
<ul style="text-align: left;">
<li>Leader driven or consensus</li>
<li>Logical or political</li>
<li>Rapid or Slow</li>
</ul>
<h2 style="text-align: left;">
Summary</h2>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPi4QwngsFwOcZe_iyS-o8sCwWARmEFTo8pBVtNgo2S6MCgiMCRu6fZ8_LemyLYJ2hZQbCZrYDQZdFFACwwGoynOe4gr9WP4vsArCAw-F7vs2MwLTPaojZEU7CiVUZX0OjpfmfZ-bVZ4I/s1600/3+dimensions.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPi4QwngsFwOcZe_iyS-o8sCwWARmEFTo8pBVtNgo2S6MCgiMCRu6fZ8_LemyLYJ2hZQbCZrYDQZdFFACwwGoynOe4gr9WP4vsArCAw-F7vs2MwLTPaojZEU7CiVUZX0OjpfmfZ-bVZ4I/s1600/3+dimensions.png" height="640" title="Summary of Key Dimensions" width="491" /></a></div>
<div>
<br /></div>
</div>
<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com4tag:blogger.com,1999:blog-789572373785716419.post-59598301027574726552014-07-22T05:37:00.001-07:002014-07-23T01:49:08.546-07:00Agile and Lean thinking in Japan<div dir="ltr" style="text-align: left;" trbidi="on">
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.<br />
<br />
Japanese culture does not seem to be compatible with Lean or Agile approaches.<br />
<ul style="text-align: left;">
<li>Consensus is always needed</li>
<li>Time spent on a problem is the primary indicator of effort and success</li>
<li>All expressions of ideas need to be well thought out (brainstorming is not natural) </li>
<li>It is natural to delay the commitment of an idea or an approach, so decision making is delayed to the last moment</li>
</ul>
<div>
These observations are in total contrast to the Agile or Lean approaches, which value "efficient communication", "lists", "brainstorming" and rapid decision making. </div>
<div>
<br /></div>
<div>
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.<br />
<br />
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.<br />
<br />
Interestingly "ThoughWorks" recently published this article <a href="http://www.thoughtworks.com/radar/#/">http://www.thoughtworks.com/radar/#/</a><br />
In which they allude to an aspect of this issue:<br />
<i><br /></i>
<span style="color: #333333; font-family: 'Open Sans', 'Microsoft YaHei', 'Hiragino Sans GB', 'Hiragino Sans GB W3', 微软雅黑, 'Helvetica Neue', Arial, sans-serif; font-size: 18px; line-height: 28.799999237060547px;"><i>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.</i></span></div>
</div>
<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com0tag:blogger.com,1999:blog-789572373785716419.post-67321058444344099482013-10-02T04:13:00.000-07:002013-10-02T07:36:36.054-07:00WebSockets is the way forward<div dir="ltr" style="text-align: left;" trbidi="on">
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.</div>
<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com1tag:blogger.com,1999:blog-789572373785716419.post-29773928730105916062013-08-14T04:28:00.001-07:002013-08-14T04:31:22.823-07:00Client responsive design<div dir="ltr" style="text-align: left;" trbidi="on">
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.</div>
<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com0tag:blogger.com,1999:blog-789572373785716419.post-48017163028634323822013-08-09T12:01:00.001-07:002013-08-14T04:30:13.105-07:00Coming Soon ....<div dir="ltr" style="text-align: left;" trbidi="on">
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).<br />
<br />
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 <a href="http://www.digitaltrends.com/computing/dells-sub-100-project-ophelia-usb-sized-pc-ships-this-summer/" target="_blank">USB stick PC</a>, <a href="http://www.raspberrypi.org/" target="_blank">Rasberry Pi</a> or <a href="http://beagleboard.org/" target="_blank">BeagleBone Black</a>)<br />
<br />
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 <a href="http://www.webrtc.org/" target="_blank">WebRTC</a> 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 <a href="http://code.google.com/p/sipml5/wiki/Asterisk" target="_blank">SipML</a> and <a href="http://phono.com/webrtc" target="_blank">Phono</a>, built on WebRTC. So we are not far off making voice and video calls direct from our Internet enabled TV's.<br />
<br />
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.<br />
<br />
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 ...</div>
<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com0tag:blogger.com,1999:blog-789572373785716419.post-45279346592407358652012-10-02T13:50:00.003-07:002013-08-14T04:32:22.670-07:00Things Entrepeneurs should not pay for ...<div dir="ltr" style="text-align: left;" trbidi="on">
<b>Following my previous post, here are a few things that I don't think entrepreneurs should pay for.</b><br />
<br />
<ul style="text-align: left;">
<li><b>Networking</b></li>
</ul>
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.<br />
<b> </b><br />
<ul style="text-align: left;">
<li><b>Pitching</b></li>
</ul>
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. <br />
<div>
<br />
<ul style="text-align: left;">
<li><b>Business Plan Writing</b></li>
</ul>
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 ...<br />
<br />
<ul style="text-align: left;">
<li><b>Simple Websites </b></li>
</ul>
</div>
<div style="text-align: left;">
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). </div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
<ul style="text-align: left;">
<li><b>Search Engine Optimization (SEO)</b></li>
</ul>
</div>
<div style="text-align: left;">
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. </div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
<ul style="text-align: left;">
<li><b>Analytics</b></li>
</ul>
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. </div>
</div>
<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com1tag:blogger.com,1999:blog-789572373785716419.post-6416863810742491872012-09-28T06:46:00.000-07:002013-08-14T04:32:53.964-07:00Selling the Entrepreneurial Dream is not productive<div dir="ltr" style="text-align: left;" trbidi="on">
<b>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. </b><br />
<br />
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.<br />
<br />
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.<br />
<br />
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). <br />
<b> </b><br />
<b></b><br /></div>
<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com2tag:blogger.com,1999:blog-789572373785716419.post-34721001813515926252012-09-10T06:41:00.000-07:002012-09-10T06:41:35.809-07:00The road not taken and the death of traditional retail<div dir="ltr" style="text-align: left;" trbidi="on">
<h3 style="text-align: left;">
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. </h3>
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
I arrived home, went online, found more than 5 suppliers of the product, purchased it and it arrived the next morning.<br />
<br />
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.<br />
<br />
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 <a href="http://opencto.com/">OpenCTO</a> , in an attempt to improve the quality and dissemination of this information )<br />
<br />
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 ?<br />
<br />
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. <br />
<br />
PLEASE VISIT AND REGISTER AT <a href="http://opencto.com/">OPENCTO</a> - <span style="color: #e06666;"><i>To create, focused on start-up ideas, a standardized lean methodology
and process for the conception, design and development of Internet and
mobile technologies.
</i></span></div>
<div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com1tag:blogger.com,1999:blog-789572373785716419.post-46812627334450396172012-05-30T03:44:00.002-07:002012-05-30T03:48:28.124-07:00Define, Design, Develop, Operate<div dir="ltr" style="text-align: left;" trbidi="on">
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).<br />
<br />
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 ?<br />
<br />
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 ?<br />
<br />
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 :<br />
<br />
<br />
<ul style="text-align: left;">
<li>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.</li>
<li>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. </li>
<li>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. </li>
<li>Hardware design does not change significantly as compared to software, over time. The software eco-system is moving very quickly and this adds confusion. </li>
</ul>
<div>
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 ?<br />
<br />
<i>Please visit the <a href="http://opencto.com/">OpenCTO project</a> where we are trying to create better software development processes and methodology.</i></div>
</div><div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com0tag:blogger.com,1999:blog-789572373785716419.post-29304524098350713532012-04-20T03:55:00.000-07:002012-04-20T03:55:12.014-07:00Tech Entrepreneurs - Problem of the CTO<div dir="ltr" style="text-align: left;" trbidi="on">
<h2 class="item-title">
Focus on the development process</h2>
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.
<div id="gallery">
<div class="content-loader">
<div style="display: block;">
<img alt="Process Model" src="http://www.openideo.com/open/web-start-up/concepting/focus-on-the-development-process/gallery/model.png/" /></div>
</div>
<div class="enlarger">
</div>
<div class="caption">
<div>
Process Model</div>
</div>
</div>
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.<br />
<div>
<h4>
How will your concept support web entrepreneurship?</h4>
<div>
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. </div>
</div>
<div>
<h4>
What kinds of resources will be needed to get this concept off the ground and scale it?</h4>
<div>
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.
<br />
<br />Interested, register at <a href="http://opencto.com/">http://opencto.com</a></div>
</div>
<div>
<h4>
How could we get started?</h4>
<div>
A simple concept website (launched currently at <a href="http://opencto.com%29/">http://opencto.com)</a>
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. </div>
</div>
</div><div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com0tag:blogger.com,1999:blog-789572373785716419.post-57919022663745769702011-12-22T06:43:00.000-08:002011-12-22T06:43:53.062-08:00Software design vs Hardware design<div dir="ltr" style="text-align: left;" trbidi="on">
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.<br />
<br />
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. </div><div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com2tag:blogger.com,1999:blog-789572373785716419.post-62142874681741824572011-10-19T08:35:00.000-07:002011-10-19T08:35:45.859-07:00Does Entrepreneuship Stimulate Economic Growth ?<div dir="ltr" style="text-align: left;" trbidi="on">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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
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. <br />
<br />
<br />
<br />
</div><div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com2tag:blogger.com,1999:blog-789572373785716419.post-75928183876021865332011-08-05T05:18:00.000-07:002011-08-08T06:25:52.435-07:00Mobile, past, present and future<div dir="ltr" style="text-align: left;" trbidi="on">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. <br />
<br />
Thinking about my career working as an engineer with mobile technology, starting in 1997 with the Motorola M301<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhO6hhVFU9NfD8ss41ViLRsaVaf5uq96fQIBPvsqZuraAXFyhbgooOgL4b3FhwPwmtklfSAt5PvfHxP4lgG5IIi0e98j1P8eb1_hVlFtvOge4W3M_jkkaAs5A8MYloCIa3g-ocs3CsQ1sw/s1600/Motorola_301.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhO6hhVFU9NfD8ss41ViLRsaVaf5uq96fQIBPvsqZuraAXFyhbgooOgL4b3FhwPwmtklfSAt5PvfHxP4lgG5IIi0e98j1P8eb1_hVlFtvOge4W3M_jkkaAs5A8MYloCIa3g-ocs3CsQ1sw/s200/Motorola_301.jpg" width="200" /></a></div><br />
A number of key technological elements have improved significantly over the last 15 years:<br />
<br />
<br />
<b>Battery </b><br />
<br />
<div style="font-family: Arial,Helvetica,sans-serif; text-align: justify;"><span style="font-size: small;">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 "<i>Included NiCad battery gives 12 hours standby or 70 minutes talktime</i>". </span></div><div style="font-family: Arial,Helvetica,sans-serif; text-align: justify;"><br />
</div><div style="text-align: justify;"><span style="font-size: xx-small;"><span style="font-size: small;"><span style="font-family: Arial,Helvetica,sans-serif;">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. </span></span></span></div><br />
<b>Screen</b><br />
<div style="text-align: justify;"><br />
</div><div style="font-family: Arial,Helvetica,sans-serif; text-align: justify;"><span style="font-size: small;">The m301 is quoted as having "<i>LCD Screen including a 2 line backlit Information Display</i>", 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. </span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"> </span></div><br />
<b>Processing power</b><br />
<br />
<div style="text-align: justify;">Phones around 1997, used the Intel 386 chip with a processor clocked at about 20 MHz (see some specs <a href="http://en.wikipedia.org/wiki/Intel_80386#Models_and_variants">here</a> ) 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 <a href="http://www.tomshardware.com/news/apple-ipad-iphone-ipod,9522.html">report from Jan 2011</a>). </div><br />
<b>Component size </b><br />
<br />
<div style="text-align: justify;">Companies like <a href="http://www.mediatek.com/en/index.php">MediaTek</a> 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. </div><br />
<b>Data</b><br />
<br />
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. <br />
<br />
<b>The future </b><br />
<b><br />
</b><br />
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.<br />
<br />
Some things that we can expect:<br />
<br />
<ul style="text-align: left;"><li>Mobile devices become ever more integrated in our daily lives (join the debate <a href="http://androidgizmo.co.uk/">AndroidGizmo</a> )</li>
<li>Mobiles are used for payments (parking, supermarket, theater, cinema etc)</li>
<li> Gaming on the move become more mainstream </li>
<li>Continued advances in Location based services</li>
<li>Virtual reality browsing (things like <a href="http://www.layar.com/">Layer</a> )</li>
</ul>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).<br />
<br />
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. <br />
<br />
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. <b><br />
</b><br />
<b><br />
</b><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjYuI7p4xDeC2PYkXLZn8JfP-ORCQSUvZ3ylbZp4gc8A1e49lpa4wXqSioqERuFllgoXHG24L-15JwZyfaFkG9oddaJH7Tpwy2Zl3Z3_2LNmJvCiJzL_MAmDrWt-Ci4m0JgesYFtRJ3peU/s1600/componetized+Mobile+devices.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="182" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjYuI7p4xDeC2PYkXLZn8JfP-ORCQSUvZ3ylbZp4gc8A1e49lpa4wXqSioqERuFllgoXHG24L-15JwZyfaFkG9oddaJH7Tpwy2Zl3Z3_2LNmJvCiJzL_MAmDrWt-Ci4m0JgesYFtRJ3peU/s400/componetized+Mobile+devices.png" width="400" /></a></div><b><br />
</b><br />
<b><br />
</b><br />
<b><br />
</b><br />
<b> Other interesting links</b><br />
<br />
<a href="http://www.pcworld.com/article/173033/evolution_of_the_cell_phone.html">The History of the mobile</a><br />
<a href="http://en.wikipedia.org/wiki/4G">Wiki 4G</a><br />
<br />
<br />
<br />
<br />
<br />
</div><div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com2tag:blogger.com,1999:blog-789572373785716419.post-30173286670677064552011-08-03T02:59:00.000-07:002011-08-03T02:59:04.559-07:00Beware of the pivot<div dir="ltr" style="text-align: left;" trbidi="on">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.<br />
<br />
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 ! </div><div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com0tag:blogger.com,1999:blog-789572373785716419.post-83262718909270029632011-07-26T11:42:00.000-07:002011-07-26T11:43:33.484-07:00Monetising a website<div dir="ltr" style="text-align: left;" trbidi="on">The question of how to monetise a website often comes up. In most cases my clients have interesting content and have gained reasonable traffic in the order of 30 - 100 k unique visits a month. The issue then arises, how to take the next steps to monetize the website (generate revenue).<br />
<br />
I categorize monitization into a series of categories, each building on the previous in terms of time and complexity to achieve and manage:<br />
<br />
<b>Lazy day, dream away</b><br />
<div><br />
</div><div>Here one the website generates revenue simply by placing adverts from one affiliate network or something like Google AdSense. Once the correct code has been added to the website and the account set-up there is little or no work (aside from maintaining the content - and making sure one gets the traffic). The returns here are typically low. However, one can expect to generate 100`s of pounds a month, if not more.</div><div><br />
</div><div><b>Lazy day, optimize</b></div><div><br />
</div><div>With some work on making sure your adverts are as relevant as possible to your target audience, some additional revenue might be generated. This involves correctly setting up keyword triggers and possibly using multiple affiliate networks, constantly scouring for the best deals. I.e those clicks that would generate the most revenue for your website. This requires slightly more work and attention and some more in-depth research and experimentation. </div><div><br />
</div><div><b>Not so Lazy, Becoming a salesperson</b><br />
<br />
Next in the level of complexity and possible returns is to sell premium space on your website. Naturally there is a cost associated and one must be sure that the investment yields the corresponding required return. Naturally depending on the complexity, niche, reach etc of your site - you can structure your sales in a number of ways. In the simple case automated online advert placement - in the extreme a dedicated sales and after sales team. In this category you may mix affiliated networks with dedicated sales.<br />
<br />
<b>Even Less Lazy, Becoming Sales Focused</b><br />
<br />
Next up is becoming wholly sales focused, so all revenue from dedicated advertising sales.<br />
<br />
<b>Starting to Work, Adding value</b><br />
<br />
A further step would be to start officering value added services, the sky is the limit as to what these may be. But usually some kind of subscription in exchange for information or relevance. Most often you would still maintain sales of advertising space.<br />
<br />
<b>Working, Offering a product</b><br />
<br />
Here there is some value add to your advertisers and clients and furthermore you are offering a product. A physical product related to your website or a webservice of some kind. This requires that you develop or source the product, have a CRM system - possibly a way to ship and bill etc.<br />
<br />
<b>Back from the Virtual, going physical</b><br />
<br />
Lastly you not only are selling advertising space, some value added services and some products - but you also have a physical presence. I.e your business is not entirely on the Internet. Many traditional business start this way and later develop websites - few websites develop a physical presence. However, if done may add a competitive advantage and grow the brand.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
</div></div><div class="blogger-post-footer">http://www.avrono.co.uk</div>Avronohttp://www.blogger.com/profile/13737834104833447894noreply@blogger.com0