Our Approach
Our approach to bespoke Software Development is unique. For one, we don’t attempt any form of development up until we fully understand the business problem and secondly we treat software development in the same way as a manufacturing process. Let’s explore each of these 2 points further.
Background Information
Its easier for someone to appreciate our approach after having knowing the problems of the industry. Let us and chat about these issues.
Software Engineering is one of the most sort after skills currently in the world. There is an extremely high demand for good Software Engineering skills. The Software Engineering industry has almost no barriers for entry. This is a good and a bad thing. The good is that there is enough training material available online to attract talent to the industry and reduce the shortages. The bad thing is that a little knowledge can be a dangerous thing. Another problem is that the Software Engineering discipline is in its infancy compared to the other engineering disciplines. This means that the Software Engineering discipline is not well defined and regulated as let’s say the Civil Engineering or Aeronautical Engineering fields.
Example ?
Let’s maybe try to draw an example from the statement above. If I wanted a to build a block of residential houses and looked for a Civil Engineer to assist me, he would only be able to work within the confines of regulation. His designs will only be approved and we would only be able to build if the design met a certain standard. Even if we were to proceed without the design approved, we risk being ask by the council to demolish what has been built.
We build systems that fulfils your
business needs and improves productivity
Software Development
From a Software development point of view, you could theoretically get a person who has no experience at all build for you a web application that could fulfil a particular business need. On face value it would seems that you have a great system but under the covers you could be haemorrhaging business and client information in open sight, the application could be unstable if put under load and worst of all the system might not even be able to scale. From a Software Engineering point of view, this could be seen as breaking all of the fundamental principals of the discipline yet, there is no organisation to prevent these sort of problems.
The other big problem with Software is that it is abstract. Only a very skilled eye can identify whats good and what is awful. The analogy I can use here is a log-cabin infested with termites. On the surface it seems to be perfect but under the covers its a disaster waiting to happen.
Lastly the discipline has too many options. If you google “How many programming languages?“, you should get an answer of in access of 700. These 700 languages have their own libraries, in-turn these libraries are contains in many frameworks and these frameworks are built upon a variety of platforms. Its impossible for the even the best Software Engineers to know and understand all variations of languages, libraries, frameworks and platforms.
Let me play out an extremely scary yet common situation that we come across quite often.
A company realises that they need a system to fulfil a particular business function. The company decides to do it themselves or outsources to an individual, most of the time because these are the cheapest options. The company is able to release a Proof of Concept or Minimal Viable Product without breaking a sweat or breaking the bank. Things are cheap and easy. Weeks turn into months, months turn into years and the business has grown. The problem now is that the system is no longer stable. The developer is no longer as productive as he used to be. Functionality takes the back seat because the system keeps crashing. The Developer eventually decides to follow a different path. Now the organisation is in a pickle.
A technical audit has revealed that the code is spaghetti code (unstructured and difficult to maintain). The frameworks or libraries are obsolete. The developer used a platform that was not licensed and to make things worse, there are no skills in the country for the programming language.
Software Engineer Development Process
Analysis
Design
Development
Testing
Support
What is the difference ?
Let’s start off by explaining the difference between a Software Engineer and a Software Developer. Software Developers are able to translate a formalised business requirement into working Software. A Software Engineer works in all areas in the development process ie. Analysis → Design → Development → Testing → Support.
Failing projects are projects that are running late and over budget. The reason for this is rework.
How does this scenario come about?
Someone provides the Software Developer with a document of what the system needs to do. The developer goes off and builds his interpretation of the requirement. Little to no communication means that whenever the developer is unsure of a scenario that is not documented, the developer either omits it or makes his own decision. Eventually there is a system that matches more closely what the developer believes is the solution to the business problem rather than the actual business problem. This process repeats itself with the hope that the business problem will eventually be solved. This hardly ever happens.
Our approach is for our Software Engineers to become subject matter experts. Read books, online material and most importantly speak to the business team. The business team has all the clues and answers to solve the business problem. We will never offer business advise. We are there to learn from the business team.
Our expertise is technology. Learning the business is more than just understanding. It’s about speaking the language and knowing the politics. The reason that we need to know of this is because the more we know, the less likely we are to fall into an uncomfortable situation later. The right systems are built when the technical team and business teams collaborate.
The better the collaboration the higher the trust levels. The higher the trust levels the stronger the team (business and technical is the team). The stronger the team the more successful the team. Only and only when the team collectively understands the business problem and the intended solution will we start writing code. Code is easy. Understanding the problem is the difficult part for us.
Software development as a manufacturing line
The manufacturing process is around for much longer than the Software Engineering process. The Software industry has much to learn from best practises and the mistakes made in the manufacturing industry. In fact, the agile methodology actually lends many of its key principals from the manufacturing process.
How do we turn Software Development into a manufacturing line?
Firstly; the programming language, frameworks, libraries, platforms and tooling are the same that are used across all of our projects. This way we understand the limitations of our toolset as well as its strengths.
The project structure and application architecture is standardised. The disadvantage of this is that we cant offer a solution to every type of problem. There are some problems that require a different architecture and toolset. Our niche is not this. If our project structure and application architecture is consistent, we can guarantee we solve problems once and benefit from this learning in all projects. If a particular developer is stuck, there are other teams that can help out because of the common landscape.
The architecture is broken up into the Front End, Back end, Integration and Database layers. Ideally we want a developer to only operate in one area. This way we build experts in a particular area. Within a development area, we standardise the files structures, naming conventions and coding standards. The idea is to remove all technical decision making during a project.
So does this mean that we use old technologies and are stuck in the past?
No, not at all. Our research and development is continuously ongoing. We are a tech firm always looking for better and quicker ways to achieve our tasks. We also recognise that if we keep changing any of the components in our technology stack, we risk not being experts. We then move into R & D during development which will cost our clients time and money. During R&D we find a new technology that we could use, we incorporate it into our architecture at the closest opportunity.
We also value knowledge transfer amongst our Software Engineers. The evolution of learning follows a pattern something like: awareness → investigation → implementation → mastery → teach
A Software Engineer first become aware of a technology by reading or hearing about it. There is almost always a level of investigation once the Software Engineer is interested. This investigation can be theoretical and or practical. At this point the Software Engineer starts implementing this new technology into the development process making more team members aware of it. The other team members look up to this Software Engineer as an expert for this technology. The Software Engineer masters the technology so that that he understands as much as possible. The expert transfers knowledge throughout this cycle but the formal process of teaching only happens after mastery.