Multi-threading skills - what do you mean by that?

A while ago I mentioned the possible need of brushing up our multi-threading skills. Having said that, I cannot but share the post I came across a few years ago in the RSDN.ru forum.

Disclaimer: I am not the author of the original post, I merely translated it, hoping its content can be useful.

Lately, many Java Developer job openings started to include Java concurrency/multi-threading as one of the requirements. As a response, many developers immediately added the corresponding line to their resumes. Being the one who runs interviews, I'd like to dispel some of the misunderstanding that is related to the term.

I'd like to split all multi-threading-related projects into 3 levels: the ones that use multi-threading; the ones that are based upon multi-threading and the ones which are multi-threading itself. The first level ("the ones that use") includes projects that are meant to run in the multi-threaded enviroment. E.g., there is BlahBlahFactory class and you need to mention in the documentation, if the factory is thread-safe or not. If not, you have to make it thread-safe using ReentrantLock. The second level ("based upon") includes projects with multiple threads being used as the key components. E.g., multi-threaded H.264 video codec. The third level ("are multi-threading itself") include projects that radically change the way threads are executed. E.g., development of Scala runtime environment, using Java, lightweight threads and unique memory model.

The point is that a developer often mentions java concurrency, meaning the first level, while a company can mean the second level (development of high-performance server, development of 3D action game's physics/AI engine, OLAP system development - all those cases require several threads to process a single user request.)  Sometimes developers do not know about existence of levels other than the first one. The entry-level books contribute to that heavily.

Below you can find a list of questions from an imaginary interview about Java concurrency, covering both the first and the second level. I hope that they can be used as directions for development.

Future of computing: get ready

Herb Sutter has a great, albeit lengthy article about future of computing. 

Five years from now we want to be delivering apps that run well on an isolated device, and then just run faster or better when they are in WiFi range and have dynamic access to many more cores. The makers of our operating systems, runtimes, libraries, programming languages, and tools need to get us to a place where we can create compute-bound applications that run well in isolation on disconnected devices with 1,000-way local parallelism… and when the device is in WiFi range just run faster, handle much larger data sets, and/or light up with additional capabilities.

I cannot but agree with him. We already feel the need to think in multi-threaded way even when we design trivial things. And we already cloud-bound - think iCloud, Gmail or any other of dozens of cloud services out there that we use daily.

So maybe it is a time to brush up the multi-threading skills and/or get hands-on experience with cloud services, isn't it?

Junior developers and pair programming

Not all of us like doing pair programming with junior developers. It can be hard to explain some concepts that are obvious to you, your short-term productivity can suffer, they can be too irritating with their stupid questions and so on.

However, pair programming is one of the best ways to learn and teach and to spread knowledge among team members. After all, if you have to rely on that junior (or not-so-junior) developer, you want him to be as smart and competent as possible, don't you?

Here is a couple of tricks that help me make the process more efficient and less painful for me.

Sometimes Agile just doesn't work

Why? Because Agile methodologies have their boundaries. Let's take a look at the following part of the Agile manifesto: “Responding to change over following a plan”. It sounds nice and very often it works just fine. The reason behind this principle is simple: changing a few lines of code should be simple if the process is right. After all, it is just code and to change it you don't have to move mountains.

But sometimes it isn't true. Sometimes changes can be too expensive to allow them. Imagine development of an embedded device. It includes both software and hardware development. Yes, you can write code for the software part in an Agile style. You can change that code, but if you ever need a change in the already designed and produced hardware – you're in trouble. It isn't easy to change hardware. In fact, it can cost you millions in R&D and manufacturing if you haven't done extensive planning before you even started the development. And that fact contradicts the abovementioned Agile principle. To develop the right code for your hardware (which you can change to some extent), you'll need a plan. And you'll need the extensive and thorough documentation, which contradicts another Agile principle – «Working software over comprehensive documentation».

And that's just one example. What other examples of Agile limitations can you think of?

More on user stories and Agile backlog

After writing this post about user stories, I found another fine article at Java Code Geeks about processing a backlog. I strongly recommend reading it. It has a very helpful and concrete advice on how to process your project's backlog and create the better user stories.

Here's the link: Breaking Down an Agile process Backlog

Enjoy!

User stories: deceptive simplicity

I've seen a number of Agile adopters who thought that switching from traditional requirements specifications to user stories can make their life easier in some magical way. 

- Come on! User stories ARE simple. Write three lines of plain text and off you go! 

Yes, sometimes that's a fine way to go - if you have deep understanding of the subject in question, and your vision matches the customer's vision. But this requires having a long and successful history of communication and collaboration with your customer, which a quite rare situation. Your customer should be technical-savvy to understand the decisions you make, or he has to trust your decisions completely. On the other hand, YOU have to have a deep understanding of the customer's business, you have to predict his needs - and that's not easy to do.

If you don't have this kind of relationship, you risk hearing from your customer something along the lines: "That's NOT what I wanted!" after you implement the story.

Code reviews, recommended reading

In addition to these posts (Code review vs. static code audits, Code review vs. static code audits-2) I would like to recommend a very insightful paper published by SmartBear Software: 11 Best Practices for Peer Code Review.

It has a lot of useful information both for beginners and experienced developers. On top of that, it provides statistics that helps you to understand why you have to implement these practices and what benefits they provide. (Nice thing to have if you have to confront your management about implementing new practices!)

I don't have much to say: just go and read it, guys and gals. It's totally worth it.