Customers crave functionality. Software developers must deliver functionality whilst taking care of the technical health of the software.
Business logic should not be entombed in stagnant and obsolete architectures, frameworks or platforms. Nor should the introduction of technological change disrupt or diminish the use of the software. Based on these premises and our experiences at Proximity, I want to specifically reflect on our approach to the adoption of new technologies:
How do we deliver functionally software rich solutions whilst keeping them technologically current?
First of all, what do I mean by “adoption of new technologies”? For the scope of this article, I am talking about taking advantage of third-party low-level technical solutions – programming languages, databases, software libraries – in order to provide the essential foundation for our software solutions.
Here are some examples of technologies we have adopted:
- For web application development, adopting JavaScript libraries like jQuery and Backbone
- Staying current on new release features for our delivery platforms e.g. in our role as IBM specialists, having a keen awareness of DB2 for i advances
- Transitioning to useful framework libraries e.g. for our Java EE projects, changing from using Enterprise JavaBeans 2.0 (EJB2) to the Spring Framework beans, or from servlets to the Spring Framework Model View Controller (MVC)
- Adopting and getting the most out of software tools in order to increase efficiency and quality e.g. using build systems like Gradleor source control management software like Git.
As a developer, I know that the majority of end-users don’t give two hoots for any of this detail. It’s invisible to them and they tend to focus on the end product and its functionality.
At the same time, any techie worth their salt knows how important it is to have a keen focus on the design and the architecture of the software. The selection and use of technologies is a key part of this focus.
So, what is our attitude to taking advantage of the burgeoning number of technology solutions? I’m going to try and give you some fundamentals of our approach.
Be curious about technology
It is essential to foster people in the organisation who have a passion for technology and who read widely on the subject. When you have a problem, life is easier if you have a background in the available solutions. Even if you choose a home-grown solution, it can be advantageous to understand how other people have tackled the problem.
Architect for change
In the day-to-day architectural process, always keep “ease of change” at the forefront of your mind. It’s hard to introduce fresh technologies to software which have been badly organised. Compose software as loosely coupled, coherent modules with well-defined interfaces. Keep on top of this – don’t let the software rot and decay. When the time comes to introduce new technologies, it will be pay dividends.
Choosing the right frameworks or solutions
In the area of third-party software libraries, this is an art-form. There are loads and loads of low-level solutions, under various license types, that can really help software development. The old cliché applies here: why reinvent the wheel? This is perhaps a good subject for another blog post. Therefore, I won’t spend time on it here aside from saying two things– don’t agonise too much. You should quickly narrow down target solutions for the given problem and then try it in practice.
Start using it – iterate and review
In the absence of a crystal ball, you are not going to understand the full impact, both pros and cons, of using a technology without really implementing it. So, get using it. This can be in a small and low-risk way but you need to ‘get your hands dirty’ for want of a better term. Then, review regularly and you can then either expand the usage or even completely reverse your decision if it does not meet your needs.
Communicate
You really shouldn’t take decisions in isolation. Communicate widely and involve other people. At Proximity, we have regular reviews where we discuss our focus areas and choice of technologies. Don’t be afraid to be questioned and be prepared to justify tech decisions to both experts and non-experts. Software developers are (mostly) human and can react adversely to change (especially when on the surface it seems to be arbitrary). So, it really pays to get team buy-in when introducing new methods and techniques. Taking a healthy attitude to communication can help your team make the right decisions and get full commitment and trust.
I’ve not given you a science, a prescription or a formula. I’ve given you an approach and ethos.
This is backed by our significant success and experience in delivering functionally rich, reliable software to our customers. I hope you’ve found this interesting and that it has given you an insight into our attitude to IBM i services at Proximity.
Throughout the process, and no matter what technology we adopt the focus remains the same: it’s important to us that our customers are able to keep getting value from our software long into the future.
Posted by Paul on 23rd October 2014.