We talked to two 7N consultants about Java Development. Based on their extensive experience in the field, they provided insights into what is happening within the field right now and what trends they see in the future.
Here’s Part 1 of our interview, where we explore their approach to java development and discover amongst other things what is good code really according to them.
7N consultants interviewed in this article:
Flemming Harms (FH) is an enterprise software developer and architect with more than 17 years of experience. He is specialized in Java EE and JBoss technologies, Apache Camel and has been working in all areas from architecture, design, implementation, performance optimization and as Scrum Master.
He is actively involved in the Open Source Community and contributes to various projects, because he believes, that it is the best way to learn and master the products and get help. He strongly believes you can only have success as architect, if you involve the team in the design and decisions and is involved in the implementation phase as a developer.
Johan Pramming (JP) is a Java / Java EE developer and solution architect, specialized in system integration (EAI), integration platforms and ESBs. He is an experienced developer of Java applications, integrations and services that also want to work with other JVM based technologies.
He has solid experience in the development, maintenance and operation of Java, Java EE, and Spring based applications and services. In addition to his skills as a developer and architect, he also has wide experience as a technical consultant, configuration manager and DevOps consultant.
What is your typical work-role when you take on an assignment as a consultant?
FH: Java developer and architect
JP: Java developer and architect
What drives you as a specialist and 7N consultant?
FH: The biggest drive is the challenges I get every time I start a new assignment, and that I’m able to use my skills and knowledge to build software that solves the customer’s needs. I know it sounds like a cliché, but every time I start on a new project it is like starting on a new job for the first time, and I have to prove myself for the customer and myself.
JP: The always changing tasks and that my job never becomes a routine are two of the key reasons I enjoy working as a consultant. I also enjoy the opportunity and challenges of working with many different types of customers and projects, sharing my knowledge and experience while adding new items to my own stock of skills.
What makes a project especially interesting to you?
FH: It depends on several factors, but the domain I'm working in is of course part of what makes the assignment existing. For me personally, it is also when I work with open source technologies, and find the right set of tools to build the software. I very much like the idea that you are involved in the whole life cycle from design to operation. This gives the developers and architects a unique understanding of how the software, they are building, is working in production, and it is a good way to ensure developers are prioritizing testing, logging and monitoring, when they are also responsible for maintaining the code in production.
JP: For me the most interesting assignment is the one, where the customer has realized the need of special knowledge in an area in which you can contribute, and where the customer is eager to listen and respect the knowledge and experience you provide. I also always enjoy working with new technologies and domain, as well as acquiring new skills or improving existing ones.
How do you create structure in a project?
FH: It very much depends on the job, but I have a few tools in my toolbox I can use. The projects I have been working on for the last +10 years have been using scrum as a process, and that dictate some sort of structure on a project.
As a developer I think it is important to share what you are working on and how you will do it - that could be pair programming, code review or lightning talks where you present 10 min for the team if you have created something awesome.
I find whiteboard sessions useful, where you sketch up a solution or a problem that need to be solved. People are much better at explaining themselves if they can draw on a whiteboard while describing the solution or problem.
Writing automated tests might seem tedious and slow you down in the start of the project, but you will win as soon as the codebase is growing in size or refactor code.
Automate your build and deployment process and make it fast. Again, in the beginning this might seem like you’re wasting your time, because it takes time from building features and you can do it manual, but as soon as the codebase is growing and people expect you to do rapid development, continuous integration, or delivery you wish you would have done this from the beginning.
Which source-control branching model you choose is important, it can make a big different how you work and release. I personally like to work with trunk based development, because you work with short-lived feature branches, share code faster, less merge issues and it’s always release ready.
What is good code according to you?
FH: I guess this is always up for discussion and it varies from developer to developer, what they regard as good design and quality code. So, it's important to find a common ground in the respective project, establishing a mutual agreement on what good quality code is. However, I do have several guidelines and processes I personally try to enforce on a project, if possible.
Clean code is a huge subject, and I normally try to follow Robert C. Martin’s (Uncle Bob) clean code. If you don’t follow his blog or have his book, I would recommend you get it and use it as reference guide. In addition to the clean code by Robert, I find pair programming helpful and I use it from time to time, when it's not clear what is the best approach to solve a problem. For bug fixing I also find it helpful to use pair programming.
Furthermore, code review is probably the most important part in maintaining good code quality, and to make sure everyone is using best practices. The important part here is to keep a good tone from the reviewer and to think about how the author will receive it. Use phrases like, “I will suggest…”, “could you please provide info on what the purpose is for this…”, “great work, this is a really nice approach” etc. But it's equally important that the author doesn’t take it personally, and that he/she sees it as a help and something that will cause less bugs to fix later :-)
Document your code! and here I'm not talking about the method called “getName”, which only returns a name. No, you need to document whenever it makes sense and based on what the purpose of the class, method, function, input, output parameters are. Back it up with a short example in the Javadoc on how to use it. it's the small things in between that is important to document; why did you choose to skip the first two records or why did you add a constant number here etc. that doesn't seem obvious for others.
JP: For me good code is code that is easy to maintain, well-documented and tested. Being maintainable is a kind of fluffy terminology, and it is hard to define an exact recipe for making easy maintainable code. I would emphasize that code should be easy to understand and should utilize the feature sets of the language in which it is written, without attempting to minimize every expression to the maximum extend.
Part 2 of our interview with Flemming Harms and Johan Pramming will appear next Thursday, where we will discuss new technologies and prominent challenges within the field of Java.