My dev routine

Laurent Cobos
Jul 28, 2017 · 3 min read

Today I would like to share my software development routine. I’m working in a Golf SAAS startup.

Everything starts with a “user story” or something similar that describe what people want you to add to the software. Let’s see different type of requirements:

New features

As a golfer I want to pay my reservation online by credit card

At first I try to do a quick design session with another developer, we try to figure out what are the important concepts around the feature — we often ask our product owner or any product specialist for details, words from the trenches. Here what I want is taking the most informations I can and make a draft of the model. As a convinced Eric Evan’s Domain Driven Development practitioner I try to keep an ubiquitous language from code to spoken language with product specialists.

Since:

Real systems have no top — Betrand Meyer Object-Oriented Software Construction

I prefer a bottom-up approach, modeling the domain with the knowledge we have and then adding the glue from the final user to the application. In my opinion that’s the best way to build a software that is easy to maintain / fits user needs / makes coding a pleasure.

Then I start programming. For that part I’m using a Test Driven Development approach — that’s the only way I know to do professional grade code. I build the domain objects identified previously on the design session — I take a lot of effort to craft that objects, put the right knowledge in the right object, take care or messages sent between my objects, co-locate similar concepts, avoid coupling between unrelated concepts, … bref, that can be the subject of another post.

Once all my objects are setup I start to implement the use case of the story. Usually I build a use case object named as the user story in our example it could be PayReservationByCreditCard — that object will drive the domain to satisfy the use case. That object responsibility is only to drive, it has absolutely no knowledge of the domain and takes no other decision but orchestration. Generally it fetches objects from the database, calls operations on domain objects, commits the database transaction and then could send an email for example / trigger an event / … Remember that all the domain knowledge must be in the domain not in that object !

Enhancements

A used software will change by definition

After the new feature comes enhancements — that kind of requirements are as much important as new features. Usually you will get new informations about that feature you have already done, you will get a deeper knowledge of the domain.

As a golfer I want to pay my reservation in cash at the proshop

Depending on the impact of the improvement, I go back to the whiteboard with a peer and see how that new informations we have of the domain can change our first understanding of it.

Then I start to code :) — Before anything I check what part of the code will be impacted by the changes, I prepare/refactor the code I’ll have to change — like a painter, I make sure the wall is clean before any painting. As for a new feature I take time to craft my objects, I listen to the code:

adding another dirty if? writting acasestatement ? am I missing an abstraction ?

Sometimes a tiny enhancement in the feature results in a big change for the existing domain model — the enhancement is the feedback from the trenches It gives you a lot of informations that has to be carefully listen and understood.

What about you ? what is your routine ?

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade