“He who moves not forward, goes backward”. When Goethe said those words, he had no idea, how telling they will be a few ages later. Of course he couldn’t know what an Internet is, but - for the record - it didn’t stop him to phrase one of the most essential commandments of an IT world. So, if Goethe was kind enough to share his wisdom with us, than why not to take it into consideration?
“He who moves not forward, goes backward”
Johann Wolfgang von Goethe
Ok, so what exactly this “moving forward” is? Especially in IT world and in Tech Leader’s eyes? Even if just the meaning of “moving forward” as “development” is pretty clear, then it’s interpretation in particular aspects is not necessarily the perfect obvious. To get near to the subject I will talk about first sort aspects.
Services are created using various elements, such as:
- programming languages (e.g. .NET, Ruby, PHP)
- technologies (e.g. HTML5, CSS3, Apache, Haproxy)
- libraries (e.g. jQuery, Ruby gems)
- frameworks (e.g. Rails, UiKit, Bootstrap)
- API (REST, JS, SOAP, everything in different implementations and versions) and much more components. So much, that it would be a shame to use wood (or electricity - it’s online after all), to write them down.
Groups of smart people decided to create tools and disclose them to us, so that we don’t have to create a hammer to make a chair. Those people often take care of advancement of this tools and from time to time deliver upgraded and more secured versions of them.
It’s worth to update them in our server (who would like to hammer nails using stone when there’s perfectly balanced, metal hammer in just a reach of your hand?).
Here’s some of the most crucial causes:
- it enhances security, because newer versions often have their security gaps patched and new security systems introduced (it means we are not going to hurt ourselves with stone or nobody is going to mess our project up)
- it increases performance, because with every version goes optimization and faster solution (e.g. our hammer has larger surface, so our hits are more accurate)
- possibilities are broadened and possible further works on software may progress faster (so our hammer can have another ending to extract crooked nail and additionally rubber handle)
- following versions often have bugs removed (so our hammer won’t have it’s handle falling off anymore)
Of course it happens that actualization introduces so many changes that it requires a lot of alterations and adaptations on side of remaining elements. It is the time to balance our decisions between needs, commons sense, abilities and processing forces. To sum up - let’s actualize as much as we can, but within reason.
Code development and improvement
If libraries’, frameworks’ and technologies’ and another greatnesses’ authors can actualize and upgrades their works why wouldn’t we do something with our application? Here’s the deal - we can and we should.
Let’s imagine: our service gains on popularity and our clients, hungry for our products, will be crowding in on our webpage. Just like Black Friday and zombie clients :). Just yesterday our page worked fast and efficient and today? It’s not rushing into anything and every question is responded with 502 error. It’s not the prettiest scenario.
Service’s code is worth to be optimized, because it allows him to act quickly in case of sudden bigger traffic (it can be increase in number of visits caused by mailing or marketing strategy). It will accelerate operations that may be vital from the point of view of time performance and response awaiting (e.g. often administrative works, shopping process, periodic data generating for external tools). Besides - fast acting service means less rejections and bigger conversion factor.
Patches and corrections
Patching the service is the most important thing. Wait a minute? What do you mean by patching? My web service is faultless! There’s the thing - it’s not. Every application had, has and will have loops and errors. It’s inevitable. Even empires such as Windows or uncle Google release patches to their softwares long after their premiere. And I can assure you - they could do it endlessly (if it was profitable). What’s more - gaps can occur in hardware (something more can be said by e.g. Intel guys when you ask them about Meltdown and Spectre). To make a long story short - one who does not make mistakes, does nothing.
So, when we already know that bugs and errors happen, the more important question is: what to do with them? If they are security gaps, then the answer is only one: Path it up Mr, patch it up! To be honest - in any other case the perfectly good solution is also patching, but the urgency depends on the specificity of the exact error. However sooner or later - this bug should also be patched and not - as it happens often - forgotten. Service correction will allow us to:
- preserve user’s security and more (what in face of RODO is really important)
- correct realization of functionalities (e.g. eliminating problems that occur in particular cases)
- increase efficiency (some mistakes can cause decrease in performance)
Ok, We’ve optimized and patched. What else? Yes, there’s something more. Our code should be refactored. What does it mean? It means that part of code that realizes some functionality can be written more briefly, readable and shorter. What for? So that expanding this functionality could be done faster and more efficiently without wasting time on straitened code analysis. Faster will also be debugging and evaluating possible alterations and in some cases refactoring opens new possibilities in particular functionality development (e.g. after refactoring adding results’ pagination is much easier)
Let’s look up on life’s example. Back in the day if you wanted to get an ID you have to go to the first counter to report a request, than with a proper document go to the second counter upstairs, where you have to submit a document and make payment, and after this you have to get to the last counter to hand in payment confirmation, to finally get the confirmation of ID request. And the ID itself would be ready to reclaim later.
Let’s assume that for any reason it has to be transacted it 3 different counters. Why not to do each counter next to each other with an information above that leads us one step at the time. Let’s go further - why not exchange payments counter with machine? In scenario before we would have to find proper counter and then exchange it for the machine. In improved scenario finding out what to do is much simpler - we know where is the exact counter and if our machine is going to fit in (and maybe it would be good to put not 1 but 2 machines there) That’s just one of many ideas to refactoring and optimizing of this case.
As you can see (refactoring, optimizing, alterations) often connected to each other. If we take care of our code now (by optimizing, patching and refactoring) then every necessary action in the future (patches, implementations, analysis) will be faster, programmers will make less mistakes and estimation and implementation pricing will be more accurate. It’s a life worth living!
Wait a minute! What kind of servicing? Shouldn’t computers and technology and all of the black-magic that programmers do, be self-sufficient? Yes, but not literally. Someone has to have the automatics set and supervised. Because our service is changing so should automation adapt to it. Besides not everything is worth automating. Let’s look at cars. They contain self-oiling, self-diagnosing computers and accessories and still from time to time Mr John has to exchange the oil, clean some filters and nozzles. It’s the same with services.
Occasionally applications require servicing: file control, needless temporary files or database inscriptions removal, event log archiving or cleaning after quick and urgent alterations, malfunctions etc.
If our client chose premium option, the service is created in a way that part of diagnosing and servicing is being done automatically. But it is worth investing in the beginning.
Code’s condition at this moment is kept in so called repository (e.g. SVN, Git). The way our application (it’s code to be exact) is changing is contained in repository in form of branches, that include records of every alteration from the very beginning (so called: commity). Thanks to that every work on this application is concluded from certain code’s condition and changes are attached to the known state. It causes all work cycle to be well-organised and readable.
Repository management, such as:
- alterations review,
- needles branches removal,
- changes attachment,
- informations updates,
- connecting points with alterations and commissions description
may not be connected directly to the application but is a vital element.
Hygiene of work with repository has its influence on:
- developer’s work speed,
- alterations implementation speed,
- alterations operation,
- debugging (helps to narrow changes area to check),
- changes adaptation between services,
- documents creation.
It’s a natural thing that while service operation can happen problems caused by:
- system malfunctions,
- hosting companies malfunctions,
- web malfunctions,
- increase in efficiency requirements.
Reacting to these situations, changing hosting parameters, designing or changing the architecture on our server (whether is the database, the service or other microservices redundant or not) is an element requiring being switched on.
For example if any service (e.g. API of our service) creates permanent periodic increase in strain, then to make other services (e.g. client’s panel) not get strained too much, it’s worth to isolate API work from the panel. Another possible benefit is redundant system of virtual machines, thanks to which if any of the machines goes down, the user won’t see the difference. There are a lot of possibilities and they should be adapted to the constant changes and tailored for the case - and the tailor should be a service administrator.
With time the new more effective and more accessible ways to communicate with user occur. There are new solutions and forms of content marketing and new visual standards. Constant following with this changing can reassure us that we won't be left behind, and our web page will seem professional and will respond well.
Services which appearance and functions don’t change over the course of years make an impression that their authors forgot about them. About them and their users. It gives the feeling that the owner’s business is not profitable and the company and its products/services start to appear less sure and set on the market.
“Today’s technology and solutions, tomorrow are no longer up-to-date.”
Constant service development, well-thought functional changes, interface and UX upgrading, creating new tools for the clients and responding to their needs and signals, are crucial elements of running the business. If we forget about it, our clients will go to the competition that keeps everything on track. Additionally: increase of foreign services and lack of barriers in Internet, enhances competition and speeds up the flow of new solutions on the market. If we want to be competitive, we have to be up to date and set out new standards. From the other hand people like what they are used to. Balancing between those two states (new solutions vs old habits) can be a real challenge. That’s why searching for ner solutions should be backed up by environmental studies and well-thought strategy and not an art for itself.
When planning changes you have to get perspective. “Good enough” can be viable for just this moment. Saving up on changes today, may significantly make implementing changes difficult (and increase costs), and in some extreme cases even make changes impossible to implement. That’s why consultations with IT division and finding solution optimize for the technical and business side, are so important.
Reactions to the different changes
Services often require changes from other reasons than written before, e.g. legal (like cookies notice) or business (marketing expansion) cases. Software modification is then essential and worth planning it over time, not for the last minute. The moment we expect changes to happen, we should think and discuss it with IT. Thanks to that we will be able to design other scheduled alterations the way, they won’t be in conflict with the one expected after and the implementation itself won’t be introduced in a hurry.
Now when we know on how many levels we can develop and maintain our service, we have to gather it up and plan. Not one and not twice but permanently because working on a service is a long ang constant cruise. It’s important for every work on development to be regular and well-organized and long planned. It will allow us to reduce the amount of works on our service. You won’t be surprised that introducing one functionality requires rebuilding many others. You should keep in mind that something that seems simple, may require a lot of additional changes or be impossible within established budget. That’s how essential is the need of constant, clear and honest communication with IT division. And I wish it for the both sides - after all we are on this cruise together :)