On The Virtues Of Platforms – Spring Boot and Rapid Application Development in Java

From a presentation I did at Silicon Valley Code Camp 2014

Rapid Application Development Defined

Rapid Application Development (RAD) is a loaded term, meaning many things to many people. ¬†Let me start of by clarifying what I mean by¬†RAD — RAD does not mean code like hell, nor does it does not mean employing a tool that codes for you. When I say RAD, I am referring to the practice of leveraging existing services, components, patterns and practices to maximize the code that relates to your domain, and minimize boilerplate or commodity feature development. ¬†For example, code in your application that marshals XML or JSON has no customer value nor does it have a developer benefit. ¬†It‚Äôs tantamount to creating TCP packets in your code to send a request to a service. ¬†Sounds ridiculous, yet I have seen this practice over and over. ¬†Not only is it a waste of time, it‚Äôs error prone, and unmaintainable. ¬†As an application developer, you are not being paid to build commodity services…

Commodity Services Abound

There are a plethora of frameworks and platforms in every technology stack that attempt to address this and other commodity needs for the application developer.  Over time, the things we feel we need to code ourselves today become as preposterous as the TCP packet example Рmore and more moves down the stack into framework or platform components and services.  It’s the natural evolution of software, especially in the new world order of open source and massive developer contribution and collaboration (thanks Github!).

While it is wonderful that your current and future needs are being addressed by others, much of the developer effort starts to shift to finding the project that has a solution for you and how you can use it, if at all. Making sense of it all can be daunting. Fun facts, as of Oct 2014:

This is both the beauty and the chaos of the world of open source.

Frameworks Abound

Frameworks play a large role in helping tame this chaos.  They typically provide a collection of curated Components that work seamlessly together.  As well, these frameworks provide implied (or explicit) patterns and practices to help maintain good architecture and maintainability.  Some will go so far as endorsing other combinations of components in use for known use cases.


The Era of The Platform

Platforms go beyond software components and frameworks.  Platforms typically add more commodity services beyond pure software components, including

  • Development Tooling
  • Deployment Automation and Services
  • Systems Management
  • Testing Infrastructure
  • Maintenance of Framework Components
  • Versioning and Release Management

Platforms are trying to create cohesive technology experiences for developers and businesses so that you choose them as your one-stop-shop. ¬†This used to be restricted to the likes of IBM and Microsoft, but now it’s a much more diverse and heterogeneous world where cherry-picking best-of-breed software and patterns is the norm.

Less for you to worry about, more time to focus on your domain!

Making Good Choices

As a developer or (gasp!) software architect embarking on technology choices, you have a huge responsibility. ¬†You don’t want to paint yourself into a corner with a framework that is simple but potentially¬†limited in functionality, yet you don’t want to choose something feature-rich but overwhelming complex¬†and gnarly. ¬†Questions to ask yourself:

  • What do I need from the framework in the short term?
  • What might I need from the framework in the future?
  • How has the framework evolved, will it continue?
  • Are there enough people skilled in the use of this framework?
  • Is the documentation and support good?
  • Is it an ordeal or a joy to work with?
  • Is there a platform behind this framework?

Spring?  For Real?

Every time I tell someone I‚Äôm giving a talk on Spring with the word ‚ÄúRapid‚ÄĚ in the same sentence thinks a few things, some of which are not always uttered out loud:

  1. you are mad
  2. you are old
  3. you have so many other options, why suffer?

The short answer is, Spring has everything I know I will need down the road as the apps and services I work on evolve.  It has the patterns in place that provide sensible architecture and make extending it straightforward.  It gives me the flexibility to do anything that any other framework does.


Yes, it used to be DEATH BY A THOUSAND CONFIGURATION FILES but now there’s a a way to make things more cohesive and productive РSpring Boot.

So what does Spring Boot do to accelerate your development?  The Spring Platform consists of components and frameworks that are useful in and of themselves, but are brought together through Spring Boot in a way that lends itself to true RAD. The framework is road-tested, and continues to be actively developed, keeping up with the latest technologies and patterns (Big Data, Reactive, HATEOS, Microservices, Cloud-deployed) and actively partnering with other OSS projects.

What is Boot?

Spring Boot has been explained many times and probably better than what I am about to, so please take Josh Long‘s word over mine but I’ll give it a shot. ¬†In essence Spring Boot provides:

  1. Dependency Management ‚ÄúSimplification‚ÄĚ
  2. Automatic Component Configuration
  3. Cross-cutting infrastructure services
  4. Deployment and Packaging alternatives

How does it do it?  The simple answers are (respectively),

  1. ‚ÄúStarter Packs‚ÄĚ of dependencies
  2. Convention-based configuration
  3. Production-ready services such as metrics, health, app lifecycle.
  4. Maven and Gradle plugins

Starter Packs

Starter Packs bring together Spring and Third-Party dependencies needed to do something functionally.  Examples of a starter pack include

  • Web
  • Data
  • Security
  • Test

A starter pack is essentially a manifest (in the form of a maven POM) that defines what each pack requires in and of itself. You simply include the starter pack you need in your app’s POM (or Gradle file).


The Magic of @EnableAutoConfiguration

The key to ending the suffering of the¬†DEATH BY A THOUSAND CONFIGURATION FILES is to use the @EnableAutoConfiguration annotation. ¬†This is the big hint that Boot uses to start performing various incantations and magic upon your application such that you should not, ever, never, seriously never need an xml configuration file. ¬†Beyond not needing an XML configuration file, you don’t need that much configuration even outside of files. ¬†Here’s how it works: Boot scans your classpath to see what kind of goodies you’ve included, and attempts to auto-configure for those. ¬†It also scans your application to see what @Beans are in place and which aren‚Äôt (but perhaps should be?) and backs off (respecting your config) or autoconfigures according to convention. ¬†Finally, you can help Boot with your application-specific settings (like DataSource config, ports, etc) with¬†your application.yml or application.properties.

To understand why this is significant, it helps to remember how things were before this.

Traditional Spring Way

  1. Configure Web Container
  2. Create Web Project
  3. Configure POM/Gradle/Ant dependencies (with versions) build and and packaging (150 lines +)
  4. Configure web.xml with Spring context config files, dispatcher servlet, servlet mapping, Spring security Filter, etc..
  5. Write Controller, Service, Repository Beans and Domain Objects
  6. Configure *.xml files (Or annotated @Configuration Beans) with
    1. Bean definitions,
    2. View resolvers,
    3. content-negotiation,
    4. controller mapping,
    5. resource handling,
    6. error handlers,
    7. db pooling,
    8. connections,
    9. profiles,
    10. transactionmanager,
    11. jdbc templates or JPA config.
  7. Write code to create/update schema from script
  8. Package WAR file
  9. Deploy to running Web Container.

Spring Boot Way

  1. Use/Include Spring Boot Starter Parent in pom/Gradle, add Spring Boot Starter Web and JPA
  2. Write Controller, Service, Repository Beans and Domain Objects
  3. Write Application class with @EnableAutoConfiguration
  4. Run

I’m not kidding, you actually get to just write code for your app.

Infrastructure Services

Infrastructure services are things you don’t think about until after you deploy your app into the world, and realize you don’t know what the heck is going on out there. ¬†It’s something you now can throw in right away, leverage what is provided, and then enhance them according to your own needs. ¬†Including the Spring Actuator Starter give you (among other things):

  • Audit
  • Metrics
  • Guages
  • Tracing
  • Configuration Views
  • Remote management via SSH

Packaging Alternatives

As noted before, Spring Boot provides Maven and Gradle plugins that give you a couple packaging alternatives for you application.

Package as a JAR

  • Choose embedded container (Jetty, Tomcat)
  • Configure container programmatically and/or via application config
  • Run using java ‚Äďjar

Package as a WAR

  • No web.xml required
  • Spring Dispatcher Servlet is auto-configured
  • Deploy to any Servlet container

Enough Talk

In the end, it developers don’t like reading manuals (or long blog posts), they want code! ¬†I created a project to demonstrate using Spring Boot to make a halfway non-trivial application¬†that goes¬†beyond “Hello World”.


Just clone it locally to give it a spin, or fork it if you want to hack on it/

git clone git@github.com:hoserdude/to-boot.git

The app was cobbled together in about 2 days, which goes to show how productive Boot can be, or if you are faster than me, how slow I am.

To-Boot was meant to demonstrate the following

  • Boostrapping (POM, Application.class)
  • Controllers (Routes, Marshalling, Resource Handling)
  • Views (Thymeleaf, AngularJS)
  • APIs (Swagger, DTO definition, Content Negotiation)
  • Security
  • Persistence (Config, Repositories, Domain Beans)
  • Application Structure, DI
  • Monitoring and Metrics
  • Deployment Options

I welcome contributions to this example if anyone feels something can be improved or added to it.


On The Virtues Of Platforms – Spring Boot and Rapid Application Development in Java

Fixed Ship Date Agility

Reality Sucks

Many software development teams work in an environment where they are beholden to date-driven releases. ¬†And many of these same teams aspire to be “agile”. ¬†Agile means a lot of things to a lot of people, but at it’s core it’s about only releasing things that are DONE. ¬†What drove the whole Agile movement in software was that the waterfall process of days of yore could drag projects on for years without anything being released, because the standard of DONE was essentially unachievable. ¬†Either the feature functionality was not complete, the testing was not complete (or do-able), or late-breaking integration or release issues were discovered which impacted the scope.

Valencia Street Graffiti

So what’s a team to do when they are told “You shall ship on this day, with this product“?

I have had to deal with this situation for most of my stint as a developer. ¬†This post is intended to share some of the best practices I’ve garnered from the projects I’ve worked on that are of this ilk.

Lose the Religion

Step 1 is to come to terms with the fact that no process in a book is going to suit your circumstances. ¬†As a team you need to decide what principles from Agile that you can actually apply. ¬†The purists will cry foul (fair warning) and as long as they are outside your team you have nothing to worry about. ¬†If, however there are purists on the team, they have to decide if they really want to be there because you can’t ship fixed date stuff according to doctrine. ¬†The doctrine should be interpreted as a set of principles, but not to be followed to the letter.

Develop Tactics

Driving on ice simply requires the right training and equipment. ¬†It’s a calculated and deliberate process but can be safe. ¬†And if the road is made of ice, it’s all you can do.

Figure out your time constraints Рmap out your start and end dates.  Working backwards from the drop dead ship date Рcreate a two week buffer at the end.  Everything in between is available for iterations.  First iteration is called Iteration 0 Рthis is to tackle is high risk items and discover the lay of the land.  You should come out of this with your technology and architecture choices.  Try to keep it to a week.  The product owner needs to be very alert during this phase as the team members report back every day on how they are doing in the discovery and design phase.  This is where you get your first warning signals if something is going to be harder than it looked.  Your team may have to do proof of concepts and compare options.  Make it clear they are going to be making critical design choices that have to solve the customer problem, but also be feasible in the constraints you have.

Plan the first 2 iterations at the end of this.

Subsequent iterations should be relatively short (2 weeks?), fit as many as you can in between Iteration 0 and your buffer.

Stop to demo, course correct and plan the next iteration as usual within the cadence of the iterations.  Celebrate the little victories, and obstacles overcome.

Don’t Over Track

Keep track of what you need to do, who is doing it, and what got done. ¬†Get things sequenced in logical order (not just priority – some infrastructural stories might come before the top Product priority because they are enabling stories). ¬†Tracking is very important for QA purposes (they need to get ahead of the development if they can) and not important for velocity stats – remember a death march is not worth tracking for metrics – it’s worth tracking for what is being done, that’s all.

Cairn, Arches NP, UT

Be Inclusive

A Team is not a bunch of “developers” and a manager. ¬†No software product can go out the door without the support of QA, Operations, SCM, Marketing and sometimes Documentation, Privacy and Legal. ¬†Anyone who is required to get the product out the door is on your team. As such, they need to be part of the daily standups, they need to have their work captured in Stories and Tasks and they participate in planning and review. ¬†There’s nothing worse than spending a great deal of effort building something only to find out you can’t deploy it in your datacenter or you’ve violated some laws, copyrights or patents.

Embed Your Customers & Product Owners

One of the principles of agile development is transparency. ¬†Some mechanisms are built into most agile processes to promote that, namely the daily standup, iteration demos/reviews, and in some cases pair programming and daily test suite reports. ¬†These all keep the team up to speed on the status of the project, however it’s the product owner who ultimately has to do something with this data.

Embed your product owner, be it a Product Manager, a Customer or a stakeholder in the outcome of the project. ¬†By embed I mean physically embed them with the team, right in the middle of the action, co-located (Yahoo! style). ¬†The product owner benefits by hearing the chatter of the team beyond the scheduled meetings, and the team benefits from the availability to answer questions on requirement refinements, tradeoffs in implementation etc…

The knowledge the product owner has on a day-to-day basis gives them what they need to make course corrections, set expectations with other stakeholders, and also get a sense of what obstacles they can help clear in advance of work in that area.

Ensure Designers are Pigs, Not Chickens

Assuming the designers are embedded as I prescribed, they will quickly see the progress the team makes with their designs, or not. ¬†The critical dynamic here is that there’s a tight feedback loop between the implementation and the design. ¬†It’s ideal if a designer can sling some HTML/CSS in a web project, for example – that let’s them get ahead of the team and set up templates and patterns in advance. ¬†When designers are committing code, they have skin in the game, and join the implementation team. ¬†Designers should also be ready to offer more than one option to the team when push comes to shove – some designs are better, but sometimes they are harder to pull off – a good designer will appreciate constraints, and come up with something still usable and aesthetic, but easier to build and test.

Empower Your Team Members

The term product owner can sometimes disenfranchise some team members as it gives them the impression that they don’t have skin in the game. ¬†Make it clear that the “owner” is simply the person appointed by the business to make decisions in scope based on the resources and time. ¬†They should be the experts in the domain your team is working on and know what can be traded off when the time comes. ¬†It’s up to the team members to bring issues to the forefront and present options to the owner. ¬†The only way to encourage ownership of the outcome in some contexts is to put it in practice. ¬†Find opportunities in the standup to tease out opportunities for team members to contribute their ideas (in the parking lot of course) and incorporate them into the plan. This cycle creates a series of celebrated contributions to the outcome that keep the team invested.

Ship It

Get it out there, there will be bugs, there will be compromises.  Deliver the value to your customers, celebrate it, be proud of it, and you will feel all the more inspired to go back and make it even better.

Fixed Ship Date Agility