7 ways we might change the way we develop software in 2017

IDRsolutions has always been an agile development operation and in 2016 we made a number of changes to improve our development processes.

What we did in 2016

Here is a summary of our major changes:-

1. Make code more modular

After 18 years of development, we had ended up with a small number of large projects. We split the 340K lines of code we have into 18 modules (which combine together to provide our end products).

2. Move to Maven and Git

We liked Mercurial but Git is clearly the more popular repository and so we switched from Mercurial to Git. We still have some legacy Ant scripts but we also took the opportunity to move from Ant in our IDEs to Maven.

3. Run more static analysis tests

We have substantially increased the number of tests we now run and we now use the static Analysers in NetBeans and IDEA as well as FindBugs and PMD. We have continued to switch rules on each week.

4.  Announce Move to Java8

We want to get the balance right between backwards compatibility and embracing new features. So we publically announced (with 12 months notice) we would move from Java6 to Java8 in April 2017.

5. Rewrite old classes

Have you looked at old code with fresh eyes? We decided as part of our plans to move to Java8 in 2017 that we would review the old code and tidy it up. We especially wanted to ensure that it was easy to maintain for the next 19 years!

6. Refactor code

We refactored lots of long methods and split large classes where these did not impact the public API.

7. Custom builds

We started to offer our Enterprise clients their own custom builds. So they could leave out the Viewer if they were just using the software as a server solution. We also provided a custom area for downloads and custom tests.

So much for 2016….

What will we might be doing different in 2017

Now we are looking at what we may do in 2017. Here are some of our possible ideas:-

1. Increase modularisation

We could split the code into many more modules.

2. Totally replace Ant

Is it now time to move completely to Maven, or make we should be looking at a replacement for Maven as well?

3. Investigate Java9 enhanced version

 Would a Java9 only version be a useful option or is Java8 good enough?

4. Have a more public roadmap

In past years we tend to keep this to ourselves, occasionally discussing with some select clients. Are there any advantages to making it more open? What would you like to see on it?

5. Separate code into separate jars (core, examples)

 Traditionally we tried to have the fewest jars (one reason we wrote our own replacements for JCE and ImageIO). Would developers prefer several jars to use together so that things like examples are easier to add and remove?

6. Move more code onto GitHub

Being on Git makes it much easier to use GitHub. What would be useful to post there?

7. Give some customers more access to our git repositories

At the moment, clients get access to the source for the releases, but not the raw Git repository. Should we consider this?

Before we finalise our list, we wanted to give you the chance to give us your thoughts.What would you like to see? What would make our customers life easier? What extra features would you pay for?

Watch how to use our PDF Viewer JPedal