Decision Making – Technique or Gut-feel

Lessons in live, just like opportunities, sometimes come from the strangest sources or situations.

As I was driving from London to Canterbury University to meet an old colleague and friend, I tuned in to the radio station ‘Magic’.  The presenter announced that it was time to give away some money to a lucky family for holiday spending money in a dial-in competition. The concept of the competition is that the presenter has a particular item in mind which the contestants must determine. The presenters provides a clue through asking a relevant question to which the answer is this particular item he has in mind. Contestants dial in and can ask two questions to determine what the item is the presenter has in mind, after which a final answer must be provided.

The relevant question was: “I am going to the beach to enjoy a lovely sunny day of sea and sand, what am I taking with me?” Now usually I would start solving a mystery question like this by means of elimination narrowing down the field of possibilities and thus zooming in onto the correct answer. For example asking an initial question like: “Do I use this item in the water or on the beach sand?” Dependent on the answer of either water or sand you’ll start narrowing things down by questioning if you use the item to play, can you eat or drink the item, etc. The catch is though that you can only ask two questions and then have to guess the correct answer. So you have to carefully think of which two questions to ask, while the clock is ticking…

An eleven-year-old boy won £1800 for his family in summer vacation spending money in playing the game? Instead of applying a problem solving technique like elimination, he went directly to obvious answers, which he phrased as questions. His first question was: “Is it a spade?” to which the presenter answered: “No, it is not a spade…”. His second question was: “Is it a bucket?” “Yes! It is a bucket, you just won your family £1800 in cash!” The presenter answered in delight.

This was making me think as I participated in my mind making up questions to determine the correct answer myself – by means of elimination… “Is it something that you use in the sea? No! Is it something you use on the sand? Yes, on the sand, right. Oh, my two questions are up, now I have to guess…”

What has just happened – the 11-year-old boy, who probably had no official training in problem solving techniques or skills, solved the mystery in two questions without having to guess an answer at the end.

As a director I am facing hundreds of questions and problems (sometimes mysteries) every day. Surely there is a lesson or two I could take away from this…?

Lesson 1 – go straight for the obvious, the chances are the answer is right in front of you and if you are right you save a lot of precious time.

Lesson 2 – sometimes you do not have to analyse the situation, applying sophisticated techniques and methodologies to make the right decision just go with your gut, take small steps, adapt as you go and recover quickly as needed. Almost like the Lean software development methodology that uses the concept “Fail Early, Fail Fast, Fail Often” to ensure measurable progress is rapidly delivered that aligns with end user expectation.

Now, you could argue that the boy was just lucky, which he was, but going for the obvious, keeping things simple, in most cases provides you with the right answer without spending wasted time and energy. If you tend to make things more complicated than they are, remember the old saying in engineering and development ring true, KISS – Keep It Simple Stupid!

Advertisement

How to choose a Tech Stack

WHITE PAPER – How to choose a Technology Stack

What is a Technology Stack?

A technology stack (Tech Stack) is a set of software code that is made up of modules used in software products and programming languages to build (develop/code) a software application.

The lower in a Tech Stack you go the closer you get to the hardware, for example a Operating System is the part of the tech stack that provide an interface between the computer user and the computer hardware, it communicates directly with the computer hardware. The higher you go in a Tech Stack the more specific and specialized the functionality becomes for example a DBMS (Database Management System) that provides the interface and platform to manipulate, store, manage and administrate data into databases.

Choosing a Primary Tech Stack usually involves the choice of the Operating System, programming languages, standard development libraries, frameworks, DBMS and a support community. The Primary Tech Stack will be used by most of the developers and software engineers in building the software product/application but several Secondary Tech Stacks may be used in support of the Primary Tech Stack to fulfill specific specialized requirements.

There are lots of different, competing technologies made up of different tech stacks, to build a website or software application with. A software application usually consist of the following main components: the Front End of the site/application (what the end users see on the screen and will be interacting with), the Admin Portal (that the application/program administrators or back office personal will use as an interface to administer and manage the application or site), the Middleware, Logical Layer or Application Layer (that performs all the ‘automatic’ actions and is the heart of the application doing all the calculations, processing and data manipulation), and the Database where all data used within the application or site is stored. Each of these components making up an application or website can be developed with a different software product or programming language but preferably within the same Tech Stack to reduce the complexity of supporting the application/site.

How do you choose a technology stack, what factors and key technical aspect should be considered to avoid the wrong choices?

When choosing your tech stack it is important to choose components that designed to easily integrate – the frontend technology must integrate with the admin, logic and database. The integration of the different application components is illustrated in the hand drawn diagram.

TechStack_Integration

The challenge today is choosing a Tech Stack, which supports current trends, and also future proofs your technology solution for the future. You can only focus your choice towards the Tech Stack that will be appropriate and the best fit for your business today and with that realize that the Tech Stack might change in the future as technology evolves – in other words there is no such thing as a fully future proof tech stack.

Considerations and Factors to keep in mind when choosing your Tech Stack

    • Development Lapse Time / Time to Market: How long will it take to develop an application in one tech stack vs the other. If the tech stack give you access to frameworks and platforms it will reduce the development lapse time and hence your time to market (in other word the application can be developed quicker).
    • Compatibility: Will the new technology work with exiting tools and software used within the business? Can you reuse previous developed software code in the new tech stack? Integrating the new tech stack into your existing environment, will it cause disruption or large quantities of rework of existing systems and infrastructure?
    • Cutting Edge: The more cutting edge the technology the more bumps their will be on the road ahead as the cutting edge still has some way to go to maturity and stability.
    • Productivity: If you already have a development team in-house, are they qualified to work with the tech stack? DO the developers have any issues with the new tech stack? What issues and pain did you and your development team have with the previous tech stack – are those addressed in the new?
    • Engineering Talent Availability: Is the right people available to support the tech stack you intend to use? The right people will be across the board including, architects, tech leads, senior developers, developers, database developers / administrators, etc. Will it be easy to find these people? This is linked to the popularity of the tech stack – the more popular the more talent will be available. Where (in which location) will you need the talent – what is the availability of the talent in your preferred location, the location where you want to build you in-house and offshore teams?
    • Recruitment and Retention: How ill you recruit the talent for the tech stack? Will what you have to offer (salary, working environment, training, personal growth, business prospects and growth, etc.) be attractive to the market of professional knowledge workers (technologist)? Make sure that can recruit and retain your technology staff to support your tech stack, otherwise it might be an expensive choice.
    • Expertise: What level of expertise on the new tech stack do you have within your (in-house or outsourced, on-shore, near-shore or off-shore). Make sure that you have staff that are well experienced with the tech stack and ensure that they understand your business drivers and your requirements. Ensure that within your team you enough experts (at the right levels i.e. Tech Leads & Snr Developers) that thoroughly understand the tech stack intrinsically.
    • Maintenance & Support: Different programming languages promote different style for example Object Oriented (OO), Strongly Type (Functional) and Dynamic styles. As the complexity and the magnitude of the technology solution increase and/or the team that develop the solution is large then OO style programming languages bring a lot of value. Strongly typed languages and their frameworks like C++, C#, Java and Scala support better tools while Dynamic one like PHP, Pyhton, Ruby, Javascript take less development time. The trends based on the above is that strongly type OO languages are mainly used in enterprise solutions where code base size, team size and maintenance matters. Another factor to consider is the standards and methodology followed by developers in writing the code. Some software development methodologies introduce very robust quality assurance and code validation that delivers a very superior, bug free solutions that are easier to support. A well-written technology solution is also adequately documented to ensure maintainability and supportability. Other factors like team knowledge, expertise and the availability of resources/talent (as mentioned in other points in this section) to form a solution support team must also be kept in the equation.
    • Scalable: Scalability refers to the ability of a solution to easily adapt to service more users, process more data within a specific timeframe without increasing the overall software and development cost. Hardware is mostly directly related to the scalability for example the more the solution scale the more hardware might be needed to support the technology solution. Scaling can take place horizontally – that is adding more hardware (servers) to the overall solution or vertically which increases the ability to process more data and/or request/users on a particular server. Will the tech stack scale to meet your requirements in performance? How easy is it to scale the solution horizontally? How does the tech stack compare with others in vertical scaling? If you know your solution will be receiving high traffic (lots of users) or will be processing loads of data the choice of your tech stack becomes very important. The difference in the scalability of two tech stack can be seen in timing and compairing the systems’ response in processing the same about of user requests or data for example:
      • Ruby is 30 x slower than C
      • PHP is only 8 x slower than C
      • Java is a mere 2 x slower than C
    • Community: How strong is the community for your selected tech stack? A strong community is a key factor is selecting a tech stack as an active and devoted community ensures the following:
      • Availability of Documentation
      • Fast response to bugs, issues and problems. Response and support to resolution of issues that might appear to be specific to your solution
      • Availability of issue and problem solutions and the source code to copy/paste speeds up the resolution
      • Continuous updating of the basic framework, increasing the availability modules and libraries, producing new releases that results in a more stable tech stack
      • Availability of resources/talent understanding the tech stack
    • Quality of Tools: Ensure the tech stack provide adequate tools to the development and support teams to use for example IDEs (Integrated Development Environment), Debuggers, Build Tools, etc. Adequate tools will ensure you have an empowered and engaged development team that can get the job done.
    • Licensing: Tech stacks are licensed differently – either Open Source or Commercial licensing applies. Open Source tech stack has grown tremendously over the past view years. Statistics show that on the internet, more open source tech stack driven solutions (solutions based on the LAMP stack consisting of Linux, Apache, MySQL and PHP) are present than commercial tech stack based solutions like Microsoft consisting of Windows server, IIS, SQL Server and .NET. When deciding on a tech stack it is important to understand the different licensing types and the associated cost to the license to use the software not just for development but commercially in the mainstream production environments of your business. Open Source licenses are usually cheaper than commercial licenses. Make sure that you understand the type of license the tech stack components are under and that you have the associated budget.
    • Hardware Resource Hungry: What level (quantity and specification) of hardware will the tech stack require to run your application effectively according to expectations and requirements? Some tech stacks require several different servers to run a single application dependent on the complexity. This should be taken into consideration especially in conjunction with the budget constraints. Tech stack and Hardware requirements are dependent on the performance and uptime requirements of the operational technology solution. A solution that needs to be up and running every second of the every day and/or are procession large volumes of data in the shortest possible time, will have a higher dependency on the hardware with infrastructure design incorporating the resilience against hardware and connectivity failures. Hardware is not directly dependent on the tech stack for redundancy but some tech stacks are better suited for high availability with build in capabilities, than others.
    • Popularity: See point on Talent Availability and Documentation
    • Future Proof: This is a relative concept because none of us have a crystal ball to gage exactly what the future will hold in order to choose our tech stack accordingly. How long into the future are you looking to proof your application, recognizing that technology is rapidly changing and no single tech stack has ever been and will ever be available and around for ever. Even tech stacks like Microsoft that has been around for twenty plus years has changed within and the older tech stacks from Microsoft are absolute while newer options are introduced every two to three years – sometimes without appropriate backwards compatibility. Your tech stack must be agile (adapt to change), backwards compatible, scalable (to accommodate your business and market growth), from a reputable supplier (a supplier that is credit worthy and likely to be around for the future) and popular. Popularity is very important and the community following, embracing and developing a tech stack will ensure the availability of talent and support resources to ensure your application build in a particular tech stack can be supported long into the future.
    • Documentation: Are the appropriate documentation available for the tech stack to completely enable your team to utilize the power of the tech stack? Documentation includes printed manuals, internet information resources, sample code, module and libraries, community forums where issues and problems are discussed and resolved with solution code that can easily be copied/pasted.
    • Maturity/Stability: What is the latest released version of the tech stack. A mature tech stack with release versions will be much more stable than a version 1 release, for example.
  • Company Constraints: Is your tech stack choice affected by certain constraint within your business i.e. if you are looking to develop a native mobile application for iPhone or iPad who have no other choice but Objective C for your programming language. Do you have access to a DevOps team (operations team ensuring the software development and operational infrastructure seamlessly integrate)? If not you might want to consider a PaaS option and use the stack it supports. Other constraints can be: legal requirements like PCI DSS (Credit Card and Personal Information security legislation and requirements), budget and operational costs.

 

What are the popular choices in Tech Stacks?

Operating Systems
·       Microsoft Windows

·       Apple OS X

·       Linux

·       Mobile

·       iOS

·       Android

 

Programming Language Associated Web Framework
Java ·       Spring/Hibernate

·       Struts

·       Tapestry

·       Play! (Scala)

Javascript ·       JQuery

·       Sencha

·       YUI

·       Dojo

PHP ·       CodeIgniter

·       Zend

·       Cake

·       Symfony

Python ·       Django

·       web2py

·       TurboGears

·       Zope

Ruby ·       Rails

·       Sinatra

C# ·       ASP.NET

 

Web/Application Servers
·       Apache

·       Tomcat

·       Netty

·       Ngnix

·       Unicorn

·       Passenger

·       IIS

·       Microsoft Windows

 

Databases
·       Microsoft SQL Server

·       MySQL

·       Postgres

·       Oracle

 

Cloud PaaS (Platform as a Service)
·       Heroku

·       CloudFoundry

·       Microsoft Azure

·       Redhat Openshift

·       EngineYard

 

Let’s Talk – Are you looking to achieve your goals faster? Create better business value? Build strategies to improve growth? We can help – make contact!

 

Source & Reference List: