Code Last

Why am I reading this?

This seems to be the the question I ask myself before reading any blog. I normally make a snap judgment based on the title, so thanks for sticking with me so far. Let’s first address the title of this blog series, “Code Last”, as it is a slight exaggeration of the process that we follow and will lay out over a series of blogs. Code Last is a saying I have started to use in opposition of the usual code-first methodology that is so prevalent across digital agencies today. My colleagues and I will lay out a process* that we have started to implement here at Olson Digital that foregoes the traditional issues seen on projects, solves for targeted business requirements, and increases velocity and stability. Oh, and client satisfaction.

*This blog series will focus on Sitecore using MVC specifically, but can easily be adapted to any product/language/etc.

So what is the problem with the way things are?

The combination of prescriptive solution designs, perceived compressed deadlines, and the compulsive need to “show progress”–has increased defects, decreased solution stability, has a negative affect on meeting targeted delivery dates, and while at first seems to increase velocity–actually decreases over-all project velocity as QA is started.

CMS/EM implementations at the enterprise level are like fingers. Sure there are common things like bones, muscle, skin, but those common items are never the same; each bone is a unique length, muscle tension varies, and the skin has a specific patterns of wrinkles (fingerprints). Acknowledging the uniqueness of each project, why do we assume that one broad approach will work for every project?

Deadlines

The bane of true Agile methodology. Meeting it is the single-most important measure of the success of a project. When originally scoped a project can seem to have more-than-enough time to check all of the check boxes that must be checked; when meetings pile up and mis-understandings/mis-communications are realized, the buffers that you remember having will all have evaporated.

At the risk of outing myself as a Harry Potter nerd and sounding like Dolores Umbridge – progress for progress’s sake must be discouraged. A well planned process will take time to get moving. When pushed for demonstrations, we tend to jump to coding in-order to show progress. That jump will be costly; while functional specs, technical design documents, and multitudes of test cases that support code that doesn’t exist are not as sexy as the homepage, the former will lead to a more functional site that is supportable.

And your solution is…?

Code Last.

Again, I am exaggerating, but the idea is to plan first. Definition of detailed functional specs, understanding the business, designing the solution and technical details–use this knowledge and these documents and to build your test cases and unit tests that will be used to evaluate the effectiveness of the code that is being written.

Then code.

Through-out this series we will address the following topics to help achieve the “Code Last” mentality.

Understand and Document

Defining and capturing client wants or needs is a key first step in the Code Last model.  Do they want a sports car or a pickup truck?  The requirements are very different.  For most of our clients we use an Agile or Iterative development model and therefore lean toward documenting requirements in User Stories.  Using Confluence as a repository and collaboration tool the entire team can review and provide input during the course of the project.

A specific User Story tweak we make with CMS projects is to write them from the viewpoint of both end user and page author; Because their needs are different.  Other key areas to document depending on the project are process or workflows which are incredibly useful in defining sequences and interactions of complex processes.

Given the interactive nature of websites, it is critical to focus on user experience–it is a priority area for us.  We document wireframes in Axure, allowing for both quick design and a level of interactivity that helps clients reach decisions faster.

The final look and feel is captured in Design Comps and Style Guide.  The icing on the cake from a documentation standpoint, this is where the user stories and wireframes truly come to life.  InVision is how we share these with clients for review and feedback.

Ultimately these documents provide the framework for all the downstream work that occurs.  From technical design through development to testing, they are all driven based on what the team has worked with the client to define.  It’s important to note that the defining team includes an Architect to help clarify what is and is not able to be included from a technical standpoint.

End-User-Story (Integration) Testing

Selenium is a set of software tools that support testing functions specifically geared to the needs of web applications.  Testing functions, such as FindElement, are highly flexible and have options for locating UI/DOM elements including: XPath, XML element ID’s, CSS class selectors, etc. Selenium compares the expected results with actual application output and generates reports based on those findings. There are many ways to extend functionality to Selenium’s framework including testing on multiple browsers; Firefox, Chrome and Safari being most popular. Selenium also has the ability to test on multiple OS, including Apple OS X, Linux and Windows.

By addressing each layer, and how they build a fully tested solution, we can start to sway the landscape from a House of Lies closing deals and burning bridges mentality to one where we deliver well-documented, maintainable solutions.