Has your organizational ever asked some of the following questions when it comes to IT related projects?
- Why does it take so long to add a few features?
- Is this app going to take another 5 months to build? If so, we’ll just find another solution or outsource it.
- This app is too slow.
- Why are there so many bugs/errors in the software.
At the same time your IT organization has the following problems:
- The developer who originally built an application is no longer with the organization.
- Poorly written or outdated documentation, if any at all.
- A developer is scrambling to add new features to one application while fixing a bug in another..
It’s very easy for non IT related departments to get frustrated and have a lack of confidence when it comes to dealing with the IT department.
In this article, my focus will be towards “custom designed” software related projects. This means your organization has a software development team building a part or even the software application. Usually custom built applications are a critical part of daily business operations.
Lets talk about how we can mitigate some of these frustrations. Before we start, if you are one of the folks that has gotten burnt. I want you to relax and smile now 🙂
OK, now that we are heading towards a more positive vibe. Let’s discuss what we can do about this.
Even if you are not a software engineer yourself.
It can’t hurt to ask your development team two easy questions.
Do you following any coding standards or use any design patterns?
Is our software a SOA design?
So let’s exam why these are important.
Coding Standards / Design Patterns
One of the biggest reasons why bugs occur in software are that obvious to someone who is not on the development team. As a person who has written a lot of code throughout my career. Let me offer you this thought. There are many ways to solve the same problem. That’s the issue here. We all think just a little different. One software engineer might solve a problem in a way that another engineer might have not seen before. So if the second engineer has a task to fix a bug caused by the first engineer. The chances of other bugs occurring will now be increased. This is because the first engineer wrote the code in a way that the is foreign to the second engineer.
This is why it’s important for every software development team to have coding standards and use design patterns to solve problems. I won’t discuss in detail about coding standards in this article. I would rather focus talking about the importance of using design patterns.
Design patterns such as “Command, Strategy, Builder, Factory, Singleton” are good starting points for most development teams. So what exactly are design patterns and why use them?
A good example:
A bike rider notices his hands are cold. Being a smart person he decides to come up with a solution to keep his hands warm while riding his bike. He spends lots of time and effort coming up with his “hand warming system” which does keep his hands warm.
Confident, he shows up to the next ride ready to show all his friends his new “hand warming system”. When he arrives, he notices his friends all have something on their hands. When he asks he friends what they are and they respond: “They are gloves, for keeping your hands warm.” So, even though his “hand warming system” worked, he wasted a lot time and effort because there was already a proven solution available.
This is a good explanation of what design patterns are. They are proven pieces of logic that works to solve a certain problem the exact way. This means that if a team learns a design pattern. It allows the team to solve a problem in a way that everyone already understands. Then means that two different engineers could change each others code easily. This greatly reduces the chance of bugs. This is how teams can increase the quality of their software.
SOA (Service Oriented Architecture)
Once your organization can get the software development team to code in similar styles using design patterns. The next step it all about “Code Reuse”. This simply means writes once and use everywhere.
As the title of this article. This is where having a service oriented architecture design is critical. SOA simply means writing a piece of software that does not care about a user interface. It’s only main job to handle a business function.
For example: A team could write a service called “Customers”.
This service might do the following.
- Create New Customer
- Read Customer
- Read List of Customers
- Update Customer
- Delete Customer
This isn’t user interface specific. So this means that now a software development team could write a web, desktop and mobile app all calling the same service.
All of the business logic will be handled by the service. A user interface job is to just talk to the service. So the idea here is once the service works, no more modified and let it do it’s job.
Here’s a diagram for a visual