This article is aimed at the techy business owner who has a software product and hires a team, but is not particularly knowledgeable of softwre architectures and design processes, from the point of view of an external software team.
Not every client, product or solution requires the same design attention and not all software companies are the same. Some software applications require more design than others.
This article will attempt to explain the Design aspects of a software development project in an attempt to help demistyfy the processes.
This should help you understand more about the process, when you go to a software house and get them to build your dream application.
Remember, that not all software development companies are equal. You will get a different design at every single provider you go to. You must choose wisely and understand the trade-offs.
We will first look at some background, and then at the end, I will provide you with the guide.
What is design?
Software Design is a large multi-faceted area, with a vast array of definitions. It is also a completely vertical endeavour that stretches from the lowest of platforms and technologies to the top layer of application user interface and website look and feel. So let’s break it down:
- Branding (How it looks)
- User Interface (How it looks and feels)
- User Experience (How it works and feels)
- Architecture (How it defines itself within the world)
- Dependencies (What it requires to exist)
- Capabilities (What it can do now and what it may be able to do in the future)
Branding, User Interface and Experience
Some will disagree, but I believe this is also part of the software architecture.
Within this design area you must know how the user interface is constructed, the architecture of the processes, the nature of the workflow, all the way to the branding. There is a lot of design here. You would typically design software to have a look and feel. It may be in keeping with the look and feel of Windows (without your brand), or built extremely brand aware, with a complete custom look and feel that suits your business.
A software company that uses components or RAD (Rapid Application Development) tools and processes will create standard looking interfaces. It will look templated and resemble any Windows or iMac application. If they use WordPress, it may use a template. If they use components like those found here www.componentsource.com, it will have a definite common feel. Many software houses use these kinds of components to build your software, and therefore to brand-enable it, it may take longer.
You will get good features with using such components, but sometimes at the expense of ‘new ideas’, ‘branding’ and really custom software.
Keep in mind, it takes longer to build software with good branding and good simple interfaces.
A good brand will start with colours and fonts, logos and styles. A creative can be involved at everystep of the way, but be careful, because not everything is style, there are trade-offs for time, cost and performance.
Application Softare Architecture
For the purposes of this article and keeping it simple, let us create a vast umbrella term called architecture. If we were pedantic, we would split this further and separate, but we will join them here for simplicity.
In software, architecture is a term we use for the larger software design elements of a system. It is how pieces of software are broken up, connect and work together. We use terms like Service-Oriented Architecture for things like HTTP based API’s. We use architectures that use Design Patterns like Model-View-Controller or composite design patterns for smaller design elements.
Architecture is also about understanding the current and future requirements, the complexities of code changes, and decisions on what dependencies to use. It is so easy to over complicate a system with complicated features, that if some one is not actively saying no to things, you may be getting yourself into trouble.
Architecture even goes to the workflow and rules applied to developers as they code, to ensure they have a set of priorities and a set of principles that govern the standards of the code. A good architecture helps developers decide where code lives and how it interacts to keep a system clean and agile.
If your team, doesn’t have coding standards, a set of principles for the software’s design, you are not in control.
We use the term refactoring to describe a process of moving code from one state to another. If we have written code, and we can see that if the code would be more efficient or better if it was written in another way, we refactor the code to the new design.
Keep in mind that a software house that continuously refactors are possibly keeping your code in order by doing so, but there is also over-refactoring which can be negative.
How do you know you are in trouble?
If there is a lot of fire-fighting, repeatedly similar bugs appear, lots of barriers like late deployments or extra time is consistently needed. You need to refactor continiously.
So how much of what do you need to do?
Even though every project is different, there are key factors to consider. Being pragmatic and agile means that you can defer some design for later, but some design would be best up front.
Here are some important questions to ask.
- How important is your brand to the application now?
- How important is your brand to the application next year?
If you want to apply a look and feel later, require white-label or know that your brand is being developed, then you need to ensure your developers can change things easily. They must design with the capabilities to change it next year. If you don’t sort out early, your costs will increase tremendously as you strive to do this later.
- Who is going to use your software and how much UI design is needed?
If you and a staff member are the only users, perhaps a little design to make it usable, but if you are selling your software to users and expect sales and users to grow, you need to design now.
- Where is your software going? Are you expecting to add more features each year?
You need to ensure that your software provider can make changes and feature enhancements easily. You don’t want a project that takes 3 months of development, to have 10 days for a new feature. You want a good ratio of time and cost for every feature. Planning the kinds of new features you will include over the next year or so, will go a long way to helping your team design for the future.
If you spend very little time on design, you can expect lots of refactoring, lots of fire-fighting, resistance to adding new things and increasing costs.
- We use an agile methodology
If your service provider uses terms such as agile methods, scrum, refactoring, ensure that proper planning is being done to actually do the work later with little pain.
Changing a design, or adding complicated things to a design once its all deployed and used is not as trivial as designing it up front. Also, a good architectural design leaves space for future requirements. You save a lot of time in the future.
- We know we have problems, but we can’t do it now
You have to juggle new features with repairing problems that you already have. A good design always makes new features easier to add. There is a threshhold to look for. How long would it take to build this particular feature properly by itself versus how long to do it within your architecture. Just throwing more late nights is not an answer, you need a better approach.
Think about when you can make the design and restructing and put it into your plans.
The role of an Architect
The role of Architect differs from company to company, but essentially they should be responsible for:
- longevity of the application
- deals with rates of change
- looks for simple over complicated
- deals with dependency management
- creates the design and architecture
- the architecture must simplify areas of the application
- a good architecture has hotspots for easy enhancements later
- controls the neatness, robustness and goodness of the code
- thinks of both technical and business models
- the leader of the overall look, feel, workability and future proofing of the application
- reduces or limits increasing cost of ownership
If you do not have a dedicated person in the team for this, you are increasing your TechnicalDebt and cost of ownership.
See Effective Approach to Pragmatism in Software Design
Finally, you guide for decreasing Cost of Ownership
1. Design your overall architecture NOW
Don’t wait, even if you software is already in stores and used every day, don’t let that stop you. If you software looks tired and old, will you not hire a creative ui designer?
Then why do you ignore the ugly code and designs in the back-end?
Just as a creative UI, can boost sales and make you look modern, a good architectural design offers:
- faster user interface
- faster data load times
- less bugs and problems.
- reduces support and costs involved with customer issues
- makes it cheaper to make changes
- makes it trivial to make many types of changes
- a more robust and available system
- makes happier developers
- reduces friction in teams
- reduces deployment issues
- reduces dependency related problems
2. Design with Modularization
It’s very important to disconnect and draw partitions between logical areas of your systems. We accomplish this with a variety of designs, from queues, to long term transactional callbacks and other techniques. The important part is to ensure modular isolation, the art of making points of failure more diverse with less impact on core functions.
The benefits include:
- Not all services are down at once
- You can update and take a system offline without affecting another
- You can update code, fix bugs independently
- You can stagger releases and roll out change as you need to
- You reduce bugs affecting everything
- An increase in performance within each module
3. Design for Change
You need to look at your change areas. What is the most likely to change or be enhanced next month or for the next version of your software. What pivot points are driven by customers? Which areas are driven by technology? Creating a product that can roll with deployment options, or the punches thrown by the industry evolving, is a better product.
- minimizes the cost of changes
- reduces the nature of changes
- reduces bugs caused by change
- easier to deploy change
- easier to test for change
4. Document your important Architecture and guidelines
The architecture must be established within your team, and with new team members as they come on board. The architecture must be documented well. You don’t need to go overboard and document everything from code to database designs, but you need to have the overview and design principles in place. Create coding standards, list of dependencies allowed, make strict rules around bringing in new dependencies and platforms. Ensure you teams are all on the same page.
- creates consistency
- reduces learning curve for new developers
- reduces costs of learning and implementing
- reduces complications and refactoring