Spring Cloud Contract, Completing the Consumer Driven Contracts Story

A new release of Spring Cloud, Hoxton, is gathering steam. Part of Milestone 2 release is a feature I have been looking forward to for Spring Cloud Contract (SCC), the ability to generate stubs directly off of contracts. In this article we are going to take a look at what this means and how to use this new feature.

Consumer Driven Contracts in a Polyglot World

Last year SCC implemented the functionality that allowed clients to write contracts without having to be familiar with the Java tech stack. This was done by supporting a YAML DSL for defining contracts and providing two Docker images, one that could consume contracts and validates a service is meeting the contracts and the other that can consume stubs so it could act as a mock of the service the contracts were written for. For more information on this, check out this blog article by Marcin Grzejszczak.

A common approach in many Java shops is to have a backend written in Java (i.e. the producer service), but the frontend UI (i.e. the consumer) written in JavaScript. By removing the reliance on Java specific technologies when writing contracts, this made writing contracts more accessible to frontend developers. By allowing the consumers to write the contracts you are able to do a work flow called Consumer Driven Contract Development. The consumers write a contract, telling a producer what they need in a format that can be validated programmatically, and then a producer developer can write, or update, the producer service to meet the requirements of the contract.

Consumer Driven Contract Development is a desirable development paradigm because it is a “pull” rather than “push” concept. Instead of producers “guessing” what a consumer might need, you allow the consumers to define the behavior they need from the producer. This helps to producers avoid building APIs consumers don’t need, or building APIs that are difficult for consumers to, well, consume.

We Keep Waiting on the Service to Change

While SCC’s changes allowed consumers to write contracts with technologies they were more familiar with, the consumer driven contract story was still a bit hollow. SCC had a Docker images that could act as a mock of the service, however it relied upon the availability of stubs. These stubs were only generated after the contracts were validated against the producer service confirming the producer service fulfilled the contracts.

A developer building a consumer could write a contract, but until the producer service actually implemented the behavior defined in the contract, the consumer wouldn’t be able to use the mock service. This could stall development on the consumer side for days or even longer depending on the workload and priorities of the developers of the producer service. If we are going to have consumer driven contracts, we need to allow consumers to be able to develop independently of producers. The contracts are still there, and since both parties are developing based on the contract, they should still arrive at the same point.

Running a Mock Service from Contracts

With the M2 Spring Hoxton release, SCC added the functionality to run a mock service directly from contracts. I have been presenting this year about Spring Cloud Contract, and how it can be used to do Collaborative Contract Driven Development, here is my presentation from Spring I/O in Barcelona back in May. I’m happy that now with the ability to run the mock service directly from contracts, this better completes the story in my presentation.

I have created a GitHub project for demonstrating how to use Spring Cloud Contract. The project has a repo for the producer, client (consumer), and a repo for the contracts. If you clone the client repo, you can see SCC’s new functionality in action by executing the run-produce-service-mock-no-stubs.sh script. The script contains the following:

docker run --rm \
-e "STUBRUNNER_IDS=com.ibm.developer:produce-service:+:stubs:9876" \
-e "STUBRUNNER_REPOSITORY_ROOT=git://https://github.com/wkorando/produce-contracts.git" \
-e "STUBRUNNER_STUBS_MODE=REMOTE" \
-e "STUBRUNNER_GENERATE_STUBS=TRUE" \
-p "8083:8083" \
-p "9876:9876" \
springcloud/spring-cloud-contract-stub-runner:2.2.0.BUILD-SNAPSHOT

This script is running a docker image and passing in some environment variables. Let’s take a look at some of the key values being passed in:

  • ​​​​​STUBRUNNER_REPOSITORY_ROOT This is telling the Docker image where the contracts reside
  • STUBRUNNER_STUBS_MODE This is telling the docker image the contracts are in a remote location (in this case a GitHub repo)
  • STUBRUNNER_GENERATE_STUBS This is variable that was added that tells the Docker image to build stubs directly off the contracts we sent
  • -p "9876:9876" This is telling the Docker image to have the mock service running on port 9876

Executing the script will have a mock service running on http://localhost:9876. If you look at the documentation that we generate from the contracts, you can see some of what the mock service is capable of doing. If you call the url http://localhost:9876/api/v1/produce you will get back a JSON list of produce items. You can also see how this works when working with a real UI by cloning this repository and running <span class="s1">npm run start:contract.

Conclusion

The GA release of Spring Cloud Hoxton should be available later this fall. The ability to generate stubs straight from contracts is a significant step forward in completing the Consumer Driven story. It’s a feature I have been looking forward to since I first started with with Spring Cloud Contract a few years back. If you are attending Spring One Platform next week and are interested in learning more about contract driven development, be sure to swing by my presentation on Thursday Collaborative Contract Driven Development.

Reflections on One Year in as a Developer Advocate; Travel

In the second part of my series on of my first year as a developer advocate I will take a look at one of the big privileges and hassles of developer advocacy; travel. Let’s take a look at some ways to make travel less stressful and more enjoyable.

Dealing with Security

Airport security is something everyone hates about air travel, particularly if you are a US citizen, or traveling in the US often. Long lines, having to pull apart your carefully packed bag, and taking off your shoes is frustrating. Going through customs can be a difficult experience as well as lines can become extremely long if several flights arrive at the same time.

A way to make dealing with security much easier is to get TSA Pre-check, and if you will be traveling in and out of the US often, Global Entry (note TSA Pre-check comes with Global Entry).  For a $85 fee, or $100 if you get Global Entry, and filling out a form you will be able to go through the TSA Pre-check line which means you don’t have to remove large electronics, nor liquids from your bag, and can keep your shoes on. TSA Pre-check lines are also typically shorter and unsurprisingly move faster than normal security. TSA Pre-check/Global Entry are easily some of the best money spent when it comes to making travel more enjoyable (or at least less aggravating).

A couple more notes when it comes to international travel. Even non-US citizens/residents can apply for Global Entry and TSA Pre-Check. Several countries also have similar systems to Global Entry*, depending on where your organization may be sending you, it may be worth it to apply for one of those programs as well. Many of these programs are also similarly available to non-citizens.

Benefits to Loyalty

When traveling only a few times a year, if you were like me, you’d prioritized cost and convenience over brand when booking flights or hotels. At this level of travel it makes sense to prioritize those factors as you will likely not accrue enough frequent flyer miles or hotel nights to get many benefits from being a member of a loyalty program, but when you are making dozens of trips a year you might want to reconsider your priorities around how you book travel.

Your primary air carrier or hotel provider might be chosen for you by your organization. However if you do get to choose, you will want to do some research. There are three major air alliances: Star, SkyTeam, OneWorld, if you live near an airport that is a hub to an airline that is part of one of those alliances that will probably be your best choice. You will get more flight options as we as more direct flights. Considerations might be where you are flying to. If you are like me and you home airport is a “spoke“, then research to see which airline best suits your needs. For hotels, the three biggest super chains are: Marriott, Hilton, and IHG. Marriott probably has the best coverage of the three, but often they all have presence in the same markets. If you are traveling outside of North America/Europe your hotel chain choices might change a bit.

With both airlines and hotels, initially the benefits of loyalty seem pretty minimal. Slightly earlier boarding and free bottled water aren’t exactly significant benefits, but persistence can start to payoff. Getting to the second, third, and above loyalty tiers start to provide pretty significant benefits. For airlines this can mean upgrades to higher classes, much earlier boarding (which is good if you have a carry-on), and more flexibility when it comes to re-arranging travel plans. For hotels you can get upgraded to a nicer room, more flexibility with checkout, and free breakfast. In both cases you can also start to accrue a large number of loyalty points which can be used for vacations, upgrades, or bringing your significant other with you on a trip.

A tradeoff to getting to the highest tiers of loyalty can mean occasional inconvenience. Your primary air carrier might not always offer the most convenient flights, your primary hotel chain might not always be the closest to a conference venue. On a recent trip to Oslo, I stayed at a hotel that was a 30 minute bus ride both ways each day, but it was also a long stay so I earned some much needed nights. It’s a balancing act, sometimes it might make sense to to take the more inconvenient flight or hotel, other times not.

Pack a “Go Bag”

I can be a bit forgetful at times. I have forgotten noise cancelling headphones, sunglasses, and a few other items here and there. While it’s a bit annoying to forget these things, I never forgotten anything too important because I always have it pre-packed in my “go bag”. My go bag includes all the toiletries I need, under garments, exercise clothes (more on that in a little), adapters, and a number of other important essentials.

Building a “go bag” will require a bit of an investment as it will mean buying duplicates of a number of items you typically only need “one”, but it’s money well spent. When I am preparing for a trip I typically on need pack a few pairs of pants and shirts. Not only does this only take a few minutes, but is also way less stressful. I’m not thinking if I packed enough socks, underwear or if I remembered a toothbrush and toothpaste? My go bag has about 80% of what I need, which means only having to worry about the last 20%.

Staying Healthy

Travel is hard on your body. There is the jet lag, airports and airplanes are the breeding ground for germs (I once saw a parent change a baby on the tray table in a plane), and being away from home can make it hard to maintain healthy routines. So let’s look at how to stay healthy while you travel.

mobile_pharamacy.png

Allergies, headaches, colds, stomach/digestive problems, they are inevitably going to happen. Being prepared is important, so I bought a pill case that has medicine for handling some of the common concerns. This has come in handy for me a number of times, I have also been able to help friends and colleagues who were dealing with a headache or upset stomach. It’s small and convenient. Though, in some of that earned wisdom, I would recommend getting larger pill case to carry a larger amount/variety of medicine.

In the previous section on the “go bag” I mention I always have exercise clothes packed and ready to go. This was a lesson learned after forgetting exercise shoes, or shorts, or shirts. I have had trips were I have been gone for several days to even weeks, and I can start to feel it in my body when I have gone that long with out any real activity. Exercise is important element to a healthy lifestyle and I would recommend exercising in the morning as you have more control over your schedule at that time. If exercising isn’t an option, find opportunities to walk. Travel is one of the privileges of being a developer advocate, take the opportunity and advantage by walking around and visiting some of the scenic locations of the places you are visiting.

Finally try to make healthy choices when eating while traveling. When it comes to weight the saying goes, it’s ounces in the gym and pounds in the kitchen. It’s not always easy, but eating fruit for breakfast, limiting the number of drinks you have at social (or avoiding drinking or the social hour altogether), can make a difference, especially in the aggregate. The social activities are definitely another perk of being a developer advocate, but be careful to not over indulge.

Trying to Be Green(er)

In a world that is starting to feel the effects of climate change, I am definitely conscious that my recent career change to developer advocacy has enormously increased my carbon footprint. There is no way around that a round trip from the US to Europe creates roughly 1 ton of CO2 per passenger. So what are some ways we can be responsible global citizens in our careers?

A very direct way would be buying carbon offsets. Here is a recent article answering some questions if you are interested in that area. Another advantage of buying carbon offsets is that is artificially increases the cost of travel for you. If you are spending hundreds of dollars purchasing carbon offsets, you might reconsider some trips, or trying to find ways to combine them.

On the subject of combining trips, while it doesn’t reduce carbon emissions, one can be more “efficient” with those emissions. As Roy’s tweet above suggests, flying across the world for a single talk isn’t very environmentally conscious. If you are having to make that trip, try reaching out to user groups in the nearby area. When submitting to a conference, see if there are other conferences nearby that can be included in the same trip. Try reaching out to the client facing members of your organization to see if there are any of your clients in the area, or if an event of some kind can be organized. Flying around the world to give a single presentation can feel wasteful, flying around the world to give two, three, four, or more presentations can start to feel more sensible.

Travel Self-Care

Travel can be very taxing, so it’s important to consider self-care when traveling. If you are crossing many time zones, adding an extra day to the start of the travel to allow you time to acclimate to the new timezone can be helpful. Additionally setting clear boundaries with your organization making sure you have enough time at home for recovery and spending time with friends and family can also be important.

There can be a feeling that taking this extra time is “selfish”, but it makes good sense even from the perspective of your organization. If you are severely sleep deprived when giving a presentation, running a workshop, or helping out with booth duties, you’re not going to be delivering quality work. Additionally if you are feeling overly stressed or run down because you don’t have time to recover from travel, that’s going to lead to burnout and/or inability to produce content/prepare for future travel.

Sometimes pushing for this additional time or cost associated with travel will require self-advocacy toward management, but appreciate that your well-being is important for both yourself and your organization.

Some Final Tips

  • If you are in a city for only a single night, stay at an airport hotel. Airport hotels will typically have a free shuttle service and because they are closer you also can sleep in later and generally worry less about making it to the airport in time.
  • Pack an umbrella. It’s lighter, smaller, and better at keeping you dry than a raincoat, you can also just keep it in your backpack so it’s always handy. My umbrella has saved me a number of times when inclement weather suddenly showed up.
  • Airport lounge access can make long layovers a bit more enjoyable. Membership fees are often several hundred dollars, check to see if your organization would cover membership, if not most airlines let you use points in-lieu of money.
  • Loyalty programs often rollover by the calendar year. While you will maintain your same status level into the new year, you will start again at 0 for building up frequent flyer miles and hotel nights for status. As you get towards the end of the year, check to make sure you aren’t going to miss out on reaching a desired status level tier, otherwise it will have to wait until probably late next year before you reach it.
  • There is no real disadvantage to being member to multiple loyalty programs, so it’s a good idea to join all of them so at least you can accumulate points and status when you aren’t able to fly/stay with your primary.
  • Be sure to carry credit cards from multiple carriers, particularly Master Card and Visa. Also having a bank card with you is helpful as some countries strongly favor bank cards or so you can withdraw cash if needed (and not incur huge fees).

Conclusion

Travel can be fun, it can also be a hassle. You do enough travel and you inevitably run have some bad experiences. There are ways though of making those bad experiences less bad and also reducing some of the stress around travel. Joining programs to make it easier to go through security, pre-packing some of your luggage, and taking advantage of loyalty programs can help to reduce some of the stress around travel and also make it a bit more enjoyable.

Reflections on One Year in as a Developer Advocate; Content

This month marks my one year anniversary with IBM which is also my first full year as a developer advocate. So I wanted to take a moment to reflect on lessons learned and share the wisdom gained from my first year as a developer advocate. This will be a three part series focusing on different aspects that come with being a developer advocate; content creation, travel, and being an advocate for developers.

I hope this series offers a glimpse of what it’s like to be a developer advocate; both the highs and lows, though word of caution this is my experience as a developer advocate so what I say shouldn’t be taken as a universal truth. Take as one opinionated view of being a developer advocate, but also be sure to take in other views as well.

Content by Developers for Developers

Content creation is easily where I have spent most of my time as a developer advocate. Content can come in many forms; blog articles, podcasts, presentations, workshops, proof of concepts/working examples, and so on. What content you will be creating will vary depending upon your own strengths and preferences, as well as the needs of your organization. No content is inherently better, though having a mix is good so as to  appeal to and support the needs of a larger audience.

Content creation can be an extremely time consuming and at times mentally taxing process. When your content has a technical aspect, there can be an extensive problem solving and investigative component as you actually build the technical resource. This part is probably not surprising to any developers, what is surprising is, is that the creative process, that is the actual creation of the content itself (i.e. the writing of an article, recording of a video, etc.) can be just as time consuming. At least for me I spend a large amount of time writing, re-writing, and editing my content to make sure it flows easily and is clear in its message.

Because content creation can be a time consuming process, finding ways to reuse content is key. A blog article can become a presentation, or vice versa, a demo can be expanded into a workshop. Taking existing content and transforming it in to different forms can not only save you a lot of time, but also make that content more accessible and usable to a larger audience. A presentation has an important human aspect that some find engaging, however not everyone can attend a presentation, so by taking your presentation and writing a blog article not only draws more value out of the work you already did, but also helps make your content make accessible to a wider audience.

Be sure to give yourself realistic timelines and/or set aside enough time for content creation. A big change that comes with being a developer advocate is the frequent hard deadlines. If you are producing content for an event; conference, meetup, client meeting, etc., your content has to be ready by the agreed upon time. There will inevitably be times where you will be frantically finishing a presentation moments before going on stage, but it is best to avoid this by making sure you are setting realistic deadlines before hand.

Tip of the Spear, Edge of the Knife

As a developer advocate, you will often be working with the cutting edge of technology. The content creation covered above, a large portion of it will be for your organization explaining to developers how to consume your organization’s services/products. This means a couple of things:

  1. You will often be operating in an information vacuum, one you are working to fill! As you run into issues, you should reach out to members of your organization who work on the product you are writing about. This can not only help you in the problem solving process, but also be an opportunity for early feedback for the teams at your organization on how a product or service might be improved.
  2. Because API and offerings are not yet in their final form, you might have to often go back and re-verify everything described in your content still works the same way. It has happened several times now where a step or process has changed between the time I wrote an article and the time it has been published. There is also the curation of released content. Organization will add new features, deprecate features, and change features to match the needs of their users, as your organization goes through this process, it is important for you to update content that you have created that might be affected.

Be Clear

I couldn’t agree more with Amara on this point, clear documentation is incredibly valuable. I cannot count the number of times I have read documentation where crucial steps were skipped or elements within a sample piece of code/configuration were glossed over. Being clear, complete, but also concise can really elevate your content.

The best advice I can give when you are creating content is to appreciate that your audience is not going to be nearly as familiar with the technology you are describing as you are (after all its the reason they are consuming your content!). As developers we often experience this with users interacting with our applications in ways we don’t predict. So in the same way when developing an application keeping in mind that many users will only rarely use your application is a beneficial trait for a developer, keeping a similar mindset when it comes to creating content is also beneficial for developer advocates.

Be Cautious of Overpromising

More than anything else, the biggest problem I have had in my transition to developer advocacy is over promising when it comes to content. While working as a staff software engineer deadlines were somewhat fungible. As a developer advocate hard deadlines are very common.

Dealing with hard deadlines of completing a presentation, workshop, or demo for a conference, user group, or client visit, can lead to a lot of stress, anxiety, and late nights. Sometimes this happens because a small task ends up being much larger than expected, as developers we have all ran into that seemingly innocent ticket consuming your entire week. Because of the frequency of hard deadlines, be mindful of not over-committing yourself. Burning yourself out with constant stress and late nights, or having a failed presentation because you weren’t able to complete it neither helps yourself nor your organization.

Helping Yourself as You Are Help Others

While much of this article to this point has been warning of the dangers and difficulties of creating content creation, it is also among the most rewarding aspects of being a developer advocate. Receiving a thank you from someone because they found your presentation, article, or code example helpful is incredibly rewarding. I also cannot count the number of times I have gone back to reference an article or proof-of-concept I created when working on something only tangentially related. For me at least, it reinforces that the content I am creating has value.

As a developer advocate I have also been forced into learning many more aspects of the software development pipeline. I have been a Java developer for over a decade, but until joining IBM, I only had a very vague understanding of the JVM. While I wouldn’t label myself a JVM expert, because I of my work with Eclipse OpenJ9, I have a much deeper understanding of JVMs, and how they operate. Another area as developer I often didn’t interact a lot with was operations and platform technologies. While it has at times been a frustrating experience in the past year learning about technologies like Docker, Kubernetes, these will be valuable skills going forward.

The learning process while at times difficult and stressful is also satisfying and incredibly rewarding. Because I am working with so many different technologies and practices I never feel like I am in a rut, which is a pleasant contrast from my experiences as a developer.

Conclusion

Content creation is a time consuming but rewarding process. As a developer advocate there is a good chance many of your highs and lows will come from content creation. The most important points to remember is set realistic estimates and avoid overpromising and you will hopefully avoid a good chunk of the stress and anxiety I have experienced in my first year as a developer advocate.

Finding the Benefits of Impostor Syndrome

I am a frequent listener to the podcast Software Engineering Daily. On a recent episode Facebook Engineering CultureKent Beck shared his experiences from his time at Facebook. It’s a great episode and I would highly encourage giving it a listen as there are a lot of really interesting nuggets of information. One subject I found really interesting was when Mr. Beck shared how he initially struggled when first joining Facebook and how he dealt with a common feeling in the software engineering world, Impostor syndrome.

We Are All Imposters

Kent Beck was an early advocate for Test-Driven Development and Extreme Programming. He has written a number of popular books on the subjects and has been an influential voice in the software engineering world at-large for several decades now. With such a reputation Mr. Beck is not someone you would think would have to worry about feeling like an impostor.

In 2011 Mr. Beck joined Facebook, with already decades in the industry, he had thought he had “seen it all”. When joining Facebook, new engineers would go through a multi-week “bootcamp” as a way to introduce them to Facebook’s engineering culture. It was during bootcamp Mr. Beck realized he had in fact not seen it all. Facebook’s engineering culture deviated significantly from what he’d thought would be successful; few automated tests were being written, when he decided to hold a class on TDD, no one attended, and he felt he was one of the worst C++ programmers at Facebook, which was reflected in a bad review he got.

Mr. Beck had built his career and reputation on processes that put emphasis on writing automated tests, yet Facebook was finding success in not following these practices. When Mr. Beck tried to uses TDD practices at Facebook, he struggled. Upon realizing he was not performing well at Facebook, he get a feeling familiar to so many other developers, he was an imposter.

Programming Isn’t Just About Slinging Code

Slowly the software engineering world has been moving away from exclusively measuring the worth of a developer in how well they can “sling code”. A funny example of this was when tech twitter was ablaze for few weeks during the summer of 2019 with “10x engineer” memes. While it’s good that there is a greater appreciation that skills outside technical ones are necessary to be a successful developer, often when we experience imposter syndrome it’s because of our concerns related to our technical know how.

This is where Mr. Beck was finding himself back at Facebook. Despite his decades of experience and accomplishments, Mr. Beck realized that he wasn’t going to make it at Facebook just by “slinging code”. So Mr. Beck did some self-evaluation found that he would be of better service by helping to coaching up other engineers:

It was clear that just trying to sling code was not my differential advantage there. I started coaching. I had done a fair amount of one-on-one coaching with engineers before. There were no coaches at Facebook. I could see that there were engineers with tons of unrealized potential.

Because Facebook was solving unprecedented problems, there was no way they could hire somebody to solve them. They had a big bunch of the technical horsepower had to be generated in-house. I started this coaching program called good to great and began working with engineers one on one. Ended up coaching maybe a 150 or 200 engineers.

Personally, the program matched up other senior engineers with junior engineers who got more coaching. My students were demonstrably faster at getting promotions. They were twice as likely to get promoted in the year following coaching than their peers who didn’t get coached, all other things being as much equal as possible.

When we are experiencing imposter syndrome, it is important to remember that even if we lack the technical know how or skill in one area, there are other skills we have that can be of benefit to our organizations. For Mr. Beck it was his skill as a coach that helped him be successful, for you it might be skills and ability in some other area. If you are dealing with feeling like an imposter, take a moment for self-evaluation to see what other skills you could utilize to be successful.

Improvise, Adapt, Overcome

While Kent Beck was improvising by utilizing his coaching skills, a key decision he made was to re-evaluate his approach to programming. As mentioned above, Mr. Beck helped popularize Test-Driven Development. He wasn’t someone who casually wrote a unit test here or there, he literally wrote books on automated testing. However Mr. Beck wasn’t going to be successful by following these methodologies at Facebook, he was going to have to adapt:

I deliberately chose to forget everything I knew about software engineering. I just said, “I’m going to try and be a programmer and I’m going to watch what people do. I’m just going to copy what they do. If somebody says this is too diff since that one, it will be too diffs. If somebody says you need tests for this, I’ll write tests. If they say you don’t need tests for that. Why are you writing tests? Then I won’t write tests, even if I think that’s my – that’s the natural thing to do.

When dealing with the feeling of being an imposter, Mr. Beck didn’t become overwhelmed by it, nor did he suppress it. Instead he embraced it and then overcame it by using it as an opportunity to grow as a software engineer.

Conclusion

As someone who has also at times felt like I’m an impostor, it is good to know that even someone as accomplished as Kent Beck has experienced that same feeling as well. What is important though when encountering that feeling you are an impostor is to remember you have other skills that you can use to be successful and to take the opportunity to learn new ways of being successful so you can grow as an engineer and person.

Quotes taken from show transcript.

Three Books Every Developer Should Read

A lot goes into growing your career and knowledge as a developer. There are many ways to learn; the most common would be experience from the day-to-day work of being a developer, a bit more self directed would be; building small proof of concepts with a cool new tool or framework, reading blog articles, watching videos, or listening to podcasts, all are great ways to learn, and each provide their own unique benefits. However these forms typically are more concerned with answering the what or how. Books are another popular form of learning and where they differ from the other forms is their focus on the why.

Books, by focusing on the why, help to explain the underlying principles and rationale behind a practice or pattern. It is one thing, for example, to know that it is a good practice to wrap all calls to an outside service in a circuit breaker. It’s another to understand the goals and benefits behind the practice. This deeper level of understanding can help a developer make the move from junior to senior in more than title.

In this article I’m going to offer recommendations on three books that have read that have really helped me in my career. These books cover a wide range of subject areas; system/application design, reliability, and delivery. While the code examples in the book may be written in a language different from what you are familiar with, the principles are technology agnostic. So rather you are a; C#, Java, JavaScript, frontend or backend developer all these books should still be relevant and beneficial.

Domain Driven Design

Image result for domain driven design

Author: Eric Evans, Amazon

If you have wondered where the term “Domain Driven Design” came from, it is from this 2003 book. The concept of Domain Driven Design (DDD) has been talked about, blogged about, and tweeted about, a lot since its initial release. The quality of the commentary can vary, but it’s difficult to properly condense down a 560 page book into a 1000-2000 word blog article or hour long talk.

Despite it being written all the way back in 2003, its lessons are still as relevant as ever. A concept particularly important for today would be bounded contexts. If you are considering switching to a microservice-style architecture, finding the edges of a context is critical or else you might end up changing very cheap method calls inside a monolith application with very expensive http calls between services.

Favorite Lesson in the Book

Ubiquitous Language –  Early in my career I would frequently see code that would have very generic names Processor, a, validate, and so on. Figuring out what the code was doing or how it related to business needs was difficult. Ubiquitous Language describes writing code using the same nouns and verbs that your team uses to describe business concepts. So instead of Processor you might have CuustomAccountProcessor, appointment instead of a, and validateMailingAddress.  While the concept of “self-documenting code” is a myth, writing code in this way helps to lower the learning curve for new developers, or even for yourself months later when returning to a project or module.

Release It!

Image result for Release IT

Author: Michael Nygard, Amazon

Michael Nygard’s 2007 book covers how to design applications and systems to be fault tolerant and provide a good experience to clients when problems inevitably occur. The book covers several areas that can affect the performance of an application and/or system. The book is written in an anti-pattern/good pattern format, first covering a widely followed anti-pattern, the problems from following that anti-pattern, and then a good pattern that addresses the same need, but creates an application or system that is more stable, responsive, and able to recover from outages.

The image above is from the first edition, which as mentioned was released in 2007. This is the edition of Release It! I have read, but a second edition was released early last year. The Amazon link above is to the edition of the book which is the edition I would recommend reading. The reviews of the second edition suggest it is just as well written as the first edition.

Favorite Lesson in the Book

Limiting Cascading Failures – No matter the careful planning, amount of resources available, or good design practices followed, failures will happen. Finding out the cause of a failure is something to worry about later, what is important, in the moment, is returning to normal state as quickly as possible. The steps to getting to normal state will vary, but it will always be faster and easier if you design systems to limit the scope of a failure. If a database goes down, it will always be harder to return to normal state, if the application(s) that depend upon that database also crash and/or need to be restarted.

Several organizations I have been with didn’t see as much of an issue if a downstream service also crashed/needed to be restarted, the thought being they wouldn’t be usable anyways. This always complicated the process of returning to a normal state and additionally impacted deployments as there was a deployment order requirement. Designing systems to limit cascading failures makes recovery from failures faster and can also have the added benefit of making deployments easier as well.

Continuous Delivery

Image result for continuous delivery book

Authors: Jez Humble and David FarleyAmazon

On the subjects of deployments we have, Continuous Delivery. Not that I am playing favorites with my book recommendations, but Continuous Delivery has had the most profound impact on my career and how I view software development. The lessons in Continuous Delivery really resonated with me as it often covered the pain points I was often experiencing as a developer at the time and offered much more practical and sensible solutions that addressed them.

Continuous Delivery is one of the major reasons for why I got really interested in automated testing, as automated testing is the foundation on which continuous delivery (the practice) is built. Generally speaking my opinion is that if more organizations got continuous delivery right, it would address a lot of the other problems they are frequently dealing with.

Favorite Lesson in the Book:

Auditability and reproducibility – The major theme in Continuous Delivery is automating the delivery pipeline to production. When the subject of automation is discussed, often its benefits are described as being increased speed and reduced costs from replacing slow and expensive manual labor with processes executed by machine (script). These are certainly significant benefits, but, while subtle, the biggest benefits of automation in my opinion are its quality of being auditable and reproducible, which are also covered in Continuous Delivery.

Automated processes by their very nature are auditable and reproducible. Want to know what an automated test is doing? Look at the code for the automated test. Want to see what happened during a deployment? Look at the logging from the system the executed the deployment script. Automated tests can be repeated, deployment scripts reran to narrow in on and investigate a potential issue. Not to overhype automation too much, as it’s not a panacea, but its benefits over manual processes are difficult to overstate.

Conclusion

There are many great books on software development available. This is only a small selection that I have found particularly helpful. I have found myself frequently thinking back to lessons learned from these books and referencing these books in presentations and blog articles. Taking the time to read some books is really important for all developers. Rather it’s the books listed in this article or others, I hope you set aside some time to pop open a book. While benefits may not always be immediate and often require a relatively high investment in time, books can provide longterm returns in ways other types of learning may not always be able.