Now is the ideal time to build software.
The tools have improved, the frameworks are more capable, cloud infrastructure is easier to access, APIs nowadays allow systems to be connected in the way that would have required a great deal of work a few years ago and AI can now assist with some of the development tasks which used to take hours.
Yet it is still difficult to create software that lasts.
The hardest aspect isn't actually writing the code; it's working out what should be built, why it should exist, how it should function, and what will happen when the product changes.
It is there that engineering begins to involve itself with more than just implementation.
The problem comes first
Starting a project by deciding which framework to use is easy.
Whether it should be mobile or web? Which database should we select? Is it necessary to use a specific cloud provider? Should we incorporate AI? What architecture pattern would be most appropriate?
Those questions are important, but people do not usually ask them first.
The first question should be simpler:
What problem are we aiming to solve?
The answer changes everything.
The correct solution can be a mobile application or it can be a web platform or it might be an internal tool, an API, an automated workflow, a desktop application, or a combination of multiple systems.
A prize is not awarded for picking the most complicated solution.
The technology must be suited to the problem.
A feature can be easy to build and difficult to live with
A lesson you acquire when working on actual software is that the time it takes to carry out the implementation doesn't give the full picture.
It can take two hours to develop a feature and this will cause problems for the following two years.
With a product that is small, almost all technical decisions appear reasonable since there hasn't yet been enough complexity to reveal any weaknesses.
Then the product grows.
There are more users, more data, more integrations, and more requirements, along with more people involved in coding.
What might have been entirely acceptable at the start can in the end end up being the thing that slows everybody down.
It doesn't follow that the original decision was incorrect.
The circumstances changed.
Good engineering also involves realizing that the system has grown beyond the assumptions on which it was based.
Software is not finished when it ships
Although launch is a significant milestone, it does not mark the end of software development.
People who are actual users will carry out actions that you never anticipated. Requirements will be altered. Third-party services will change as well. Dependencies will be updated and performance problems will show up in areas that were not obvious when development was taking place.
The direction of the product itself could also be altered.
That's why maintainability is important.
Focusing on getting the first version to work is simple, but making decisions that will keep the second, third, and tenth versions under control is more difficult.
It doesn't mean that we should build everything with an imaginary future in mind.
That involves steering clear of making ordinary changes unnecessarily difficult.
Architecture should help, not impress
Architecture doesn't have to become complicated.
There is always another pattern to present, another level to include, and another abstraction to come up with.
It is necessary in some cases and not necessary in others.
Architecture is not about making a project appear sophisticated.
It should make the system simpler to understand, modify, test, operate and maintain.
A minor product will require only a small amount of structure.
A bigger product might require a great deal more.
What's interesting is determining whether or not the extra structure is actually justified.
That is one reason why I have grown more interested in architecture as a way of responding to change than in seeing it as a set of patterns.
Good architectural design provides a team with a course of action when changes to the requirements inevitably arise.
The newest technology is not always the right technology
There's always something new one can attempt.
Here is a new framework, together with a new programming language, a new cloud service, and a new database as well as a new AI model.
A number of these technologies are truly useful. Some of them deal with problems that we in fact have. The rest are interesting but not necessary for the product we are considering.
It is entirely acceptable to make use of new technology.
It is also perfectly all right to use something dull if it serves the purpose.
In actual software, it is usually the reliability and maintainability that are more important than novelty.
It is not always the case that the most technically sound choice results in the most interesting architecture.
It is the element which enables the product to have what is required without causing the product to have anything it does not need.
The product is bigger than the interface
With software, people usually concentrate on what the users can see.
The screens, the buttons, the animations, and the interactions.
However, the product is greater in size than its interface.
It could include authentication, databases, APIs, payments, notifications, analytics, background processes, integrations, infrastructure, deployment pipelines, monitoring, caching, security, and a number of other issues.
A product may appear to be simple even if it has a complicated system underlying it.
Which is why creating software involves more than just getting the interface to work.
The experience of users is affected even though they never see these parts.
Technology should create something useful
In the end, the software must accomplish something useful.
It ought to simplify the process.
Help someone finish a task.
Provide a business with an improved method of operating.
Connect people.
Reduce unnecessary work.
Make it easier for people to get information.
Make something that could not be done previously.
The outcome is not the technology itself.
What is important is the result.
That is the reason why we do not want Kenresoft to be associated with a specific framework, platform, or present trend.
Those things will change.
The particular problems that we are dealing with will also change.
What we should have left behind is the manner in which we tackle the work.
What we are trying to build at Kenresoft
We at Kenresoft develop software, digital products, systems, developer tools, and all other kinds of technological solutions for a variety of platforms and fields.
The work isn't always identical.
A single project could involve a mobile application, another might call for a web platform or an internal business system, and another could be primarily concerned with the backend and infrastructure. In some cases the challenging issue is architectural in nature, while in other cases it consists of finding a simpler method for doing something that has become unnecessarily complicated.
What brings the work together is not the technology.
It is the way engineers think.
Understand the problem.
Make sensible decisions.
Build it properly.
Look at what takes place after it is shipped.
Improve it whenever the situation changes.
It is the aspect of software development which proves most important in the long term.
Describing the process of building software is easy.
The actual effort lies in creating the right software and making sure that it remains useful.