If I Could Recommend Eight Books For Java Developers…

There are many books that are essential for your bookshelf if you’re a Java developer. But if I had space for just five books, which ones would I recommend? This question came into my head when I read this post about book recommendations.

Going Back To Basics


Topping the list of essentials for me has to be A Programmer’s Guide to Java Certification. I bought it before I did the certification exam years ago. Even though the edition I have refers to Java 1.4, it’s always been an excellent reference for the basics of the language. Without doubt, it’s the best book available to get going in Java.

Improving Performance


A few years back, I was working on some performance intensive features. I thought I knew threads well enough – I was wrong! This seems to be a common trend among all developers, we don’t have a great grasp on concurrency. Thankfully, Brian Goetz does and published Java Concurrency In Practice

As well as simply explaining threading you’ll find how to design and test your applications for concurrency. As multiple cores become more common this book is a must have for Java developers – especially as we dispel the myth that Java can’t be fast.

Becoming A Better Developer

The Pragmatic Programmer surprised me when I read it first. While not being specific to any language it sets out some great principles, habits and approaches for developers. I still read it every year or so to refresh. It’s been good for my own growth as a developer, and for the growth of development processes I’ve been involved in.

This book should be used in all computer courses, as it would lead to a higher percentage of graduates with a practical view on development.

 

 

I only recently read the highly acclaimed Clean Code by Robert C Martin, and that has proven to another valuable addition to my developer bookshelf. From the very beginnings of the book, you will notice common themes that lead to a poor code base.
If every developer took the time to read this book, I’m sure that software development would have a much better reputation.

Becoming a Java Expert


The second edition of Effective Java has been a welcome addition to my developer bookshelf. It has some great tips that I wouldn’t have picked up had I not read the book. And with such high praise from James Gosling, it’s a book that can’t be ignored.
“I sure wish I had had this book ten years ago. Some might think that I don’t need any Java books, but I need this one.”

The Classics

While this book is outdated in some aspects, if you can afford it, it’s a useful reference to have on your bookshelf. will always be seen as the classic book for software design.

Designing With The Future In Mind


The original GoF Design Patterns book has has set the scene for other books on patterns and design in general. Emergent Design: The Evolutionary Nature of Software Development really caught my attention recently. It has a nice concise appendix of design patterns giving a non-software analog for each, which really helps with understanding them.

It’s a great book for architects and developers to read to make designs more futureproof, stable and helps answer the question How Much Design Is Enough. It easy reading and shows how the software development industry can mature, and what you can do to improve your own practices.

 

Practical Design Patterns


The Head First series really focuses on making it easy to learn the concepts. While the original GoF book can be a bit daunting, I would certainly recommend that software developers, especially novice coders, get this book to see practical implementations of design patterns, written in Java.

 

I’m sure this isn’t the definitive list for all developers so I’d be happy to see your own opinions. What books related to software development have you found indispensable?

 

Creating An Agile Culture

I’d like to get rid of the illusion that your software development process determines if your company is ‘agile’ or not. It’s down to the culture, the mindset.

To prove this, we have to go back in time a bit – to February 2001 actually – where the Agile Manifesto was set down. It’s amazing how many people read this, and don’t pay attention to what’s said. To summarise:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

So, point number one, says that’s it’s about the people in your team and not the process you’re using. I’ve even heard people go as far to say that you can still be agile using a Waterfall process – after thinking about it, I don’t disagree.

So, the key thing, is responsive, responsible individuals on your team who are focussed on the project outcome.
To get the whole thing right, there’s a few values that need to be maintained. Here’s my list of what those things are:

  1. Communicate
    The standing meetings concept (mostly from XP) is a good one. Don’t worry about having a meeting for the sake of it – invariably, someone will have something to say – and if there’s nothing important, the meeting will be over quickly anyway.
    Make sure that all team members give updates on what they are doing. Something you think isn’t important might be vital for someone else to know.
    Keep the test team involved (there’s a tendancy for developers to leave them out) and make sure to leverage their experience.
    Encourage desk reviews of code and design with all the stakeholders.
    Everyone should try and inject energy into the team – if everyone feels empowered, encouraged and motivated, you’ll have no problems reaching the project goals.
  2. Blame Doesn’t Fix Bugs
    Solution oriented people are much more useful than problem oriented. That’s a known fact – and it holds true in software development too. Casting blame makes people feel defensive, while being constructive makes people feel empowered. The focus needs to be on outcomes, and the team should work together to find ways to solve problems, rather that over analysising them.
  3. Fix Misunderstandings
    This could fall under the communications category, but I thought it’d be good to add in as a seperate issue. Consider, if someone misunderstands a requirement, API call or a decision, chances are someone else has also misunderstood. So, when you’re addressing one persons misunderstanding, make sure everyone else knows about the clarification too.
  4. Keep It Simple
    Ask yourself if what you’re about to do is required for the project outcome. You’ll be surprised how many times it isn’t. Don’t write documents unless you really have to.
    A simple design always takes less time to finish than a complex one, and is a lot easier for everyone in the team to understand.
    Keep things as simple as possible for as long as possible by never adding functionality before it is scheduled.
    I looked at a Standish Software Survey graph – it showed that there was 45% of features that are never used. NEVER! So I definitely don’t want to spend my time working on Never Used stuff.
    That alone is motivation for me to make sure what I work on is relevant.
  5. No Broken Windows
    Anyone that’s read The Pragmatic Programmer will be familiar with this.
    The experiment carried out goes along the lines of leaving a nice car in a dodgy neighbourhood. They come back a week later, it’s still there in perfect condition.
    So they break a window, come back the next week and the car is burnt out.
    Why? Because they started a pattern of disrespect.It’s the same in software – no one wants to be the first to start this pattern – I don’t want to be first to introduce a defect. So if we repair any “broken windows” as soon as they appear, everything will be in prestine condition for the duration of the project.
    This really is worth noting – maintain high standards in everything that you do.
  6. Embrace Change
    Decisions – in software they’re not cast in stone, they’re written in sand. Things will change, and there’s no point complaining. If something does change it’s for the good of the project outcome.
    Embrace change (as XP would recommend), or just roll with it.
    Don’t fixate on a given plan, respond to the changing environment and learn.
  7. Be Flexible
    To be truly agile, you need to be able to cross disciplines – leading, coding, testing, requirements, fixing a machine – take it all as part of your daily job. You’ll increase your own learning, and value to the company.
    Be ready to do everything!
  8. Keep Everything Releasable
    If you’re a tester this is easy to understand, if you’re not just imagine you are for a second.
    To test or check progress, you need to see output – whether it’s fully ready or not. You don’t want to be told that you have to wait a day for a build!
    Everything should be ready to pass on at any time. It’s easier for everyone involved.
    It doesn’t need to be perfect, it just needs to be transparent.
  9. The Big Picture
    Understand the business and big picture implications of all decisions.
    This may be done by a Product Owner – (this could be a committee, Requirements Engineers and Architect). If using a product owner concept, use them as a “Customer”
    People need to be reminded of this vision by the Product Owner.
    To forget what the outcome of the project needs to be is the worst type of failure.
    If we keep selling a vision, people will believe.

So there you go – my opinions on real Agility.
It’s all down to the people and their mindset. If you have a team of developers following the above values, you can use any tools/processes that you want, but you will have agility.

I originally posted this article on AgileZone.