Technology Strategy

I decided to note a few observations on software development based on my experiences with a number of clients over a long career, this is work in progress and would appreciate any further input or comments. Topics Data science needs systematic approach Without Specification you are in trouble Interview for excellence Agile does not mean "do nothing" Devops first is not always productive Too many resources is as bad, or worse than too little Design before Develop, before Deploy 1. Data Science needs a `Systematic Approach` We live in a `Data Science` age, it's a buzz word. We have always had data science in some form or another, it's just that the availability, techniques, compute power and volume has exploded over the last few years. Principles are not new, they are standard engineering practises, however, in the new generation of `Data Science` these standard practises are often overlooked. Here are some general rules-of-thumb I have noted down : It makes no sense to

Challenges Facing IoT Systems in 2019 There is no doubt that we have made significant progress in many key components of IoT systems, in recent years. These developments have in fact made IoT possible. Computer hardware has come down in cost, size and price. For many the  Raspberry Pi  and other similar devices has facilitated the ability to experiment and innovate, this coupled with the huge open-source community that has provided operating systems and tools that unlock these devices.   Mobile and other communication networks have improved driven by the demand from initially mobile phone users. This has also driven the development of mobile devices, which has driven improvements in batteries, screens, sensors and the entire software eco-system that runs on these devices.  With all this development, there are still a number of significant challenges. In order to roll out significant quantities of IoT devices, there are opportunities to improve deployment solutions. we li

I am constantly amazed at the rate of progress in Software Development. Years ago, I recall writing tedious scripts using PERL, TCL and EXPECT to log into Switches and issue commands to provision them. Today we have Docker, Ansible, Kubernetes and a host of other tools, we have advanced compilers, transpilers, linters, formatters and various other tools. We can provision infrastructure on the cloud in seconds and then build complex systems quickly and efficiently. Obviously this means that the systems themselves can become ever more complex. Computing power is such that AI now has practical applications, natural language processing, computer vision and other applications. It occurred to me on my lengthy, rainy bus journey home this evening that the next step in our development evolution might be the ability to develop software and systems on the fly. I would love to be able to develop systems whilst I walked in the park or sat observing a lovely view. Would it be possible to talk

Everything in moderation - Let's not overdo the DevOps ! Recently, working as a startup CTO and adviser, I have seen what I call a "DevOps" craze. Developers, especially younger ones seem totally swept up in the DevOps revolution. Continuous deployment, auto-scaling groups, hot back-ups, containers etc etc. Many times these implementations, whilst impressive, are unnecessary for the stage of the company or the product development. Many times, they are difficult to document, relatively expensive, difficult to maintain and can be hard to debug. In many circumstances, it would be far easier to have some old-fashioned deployment or back-up scripts until the company or product has some traction in the market and there are the resources available to properly administer the complexity of the DevOps setup.  This is somewhat of a paradox, initially it would seem that by automating many of the mundane operational tasks that the development team face, you would be saving not 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. My experience has taught me to hire engineers and I have always viewed the technology as a secondary consideration. I always focuses on a grasp of engineering fundamentals and not on information about some current or past technology. In our current world these technologies are out of date by the time the ink on the contract is dry. Recently, I was approached by a leading company for a very senior role. The in-house recruiter laid on his wonderful resume with world leading software companies before affording me the chance to explain my career-to-date. He then proceeded to ask me a number of questions on specific Java libraries and how they were used. This is all information that is readily available on reference sites and in API documentation and does not  hig

I recently wrote a little about some of the issues with a technology like GraphQL. Whenever a new technology emerges that claims to solve age old problems, one has to look closely at the assertions made. In the case of GraphQL  the following is listed on their website: Ask for what you need get exactly that Get many resources in a single request Describe what is possible with a type system Move faster with powerful developer tools Evolve you API without versions Bring your own data and code The How to GraphQL  describes GraphQL as "the better REST" No more Over and Under fetching Rapid product iterations on the frontend Insightful Analytics on the Backend Benefits of a schema and type System Whilst many of these assertions may be true, the reality is that they also can cause significant problems. Like anything in engineering, there are always trade-offs. Asking for what you need : The backend or API has to be able to generate the queries that w