Development Mise en Place
Culinary artists have a French phrase "mise en place" — literally, putting in place — that teaches a cook to have his or her workstation ready in terms of ingredients and equipment. As a developer applying the mise en place concept to project developer simply makes sense.
Mise en Place is not Big Design Up Front
When thinking about this concept my first reaction was that it sounds a lot like a methodology we are trying to forget. The idea is not to get absolutely everything ready for the entire project at once, rather it is to prepare the tools, the functional requirements, the goals, etc. for an individual component before starting actual work.
A meal is composed of several "dishes" if you will. Normally you have a protein source, a vegetable, a salad, and maybe some bread. Each of these is a component of the overall meal and each can be prepared by a different cook. Now, I won't bore you with the names of each of the types of cooks — besides that is a great use for Wikipedia — but as developers we sometimes have the luxury of separating components and giving them to different team members or even to different teams.
Preparing Your Workstation
I don't mean your literal desk or even your computer. I mean getting your project or component in order. The first part of mise en place involves building the tools used for your project. For example, getting the build system in order, or creating the test suite directories and bootstrap files. You have a better idea of the tasks that must be accomplished, but doing them all before you even start actually coding will benefit you in the long run.
After you get your high-level tools built and your environments configured you can start by gathering all the specifications for your portion of the component or project. This might be user stories, interface mock-ups, et cetera. Once you have the requirements you can create any tests, tools, or other components you need until you feel you are truly prepared to build the functional project code.
I like to break my work into small tasks. As such, I prepare my mise en place only for an individual unit of work by creating issues, bug reports, or feature requests in the issue tracker, writing the unit tests I hope to be able to pass as part of my development mise en place — which is why I employ TDD frequently, and generating some sample documentation for the individual component. Once I'm done with my work I'll go back and modify the documentation if something happened to change along the way. In this way, my documentation is as up-to-date as can be expected.
How do you practice the concept of Mise en Place?
Coding to an Interface
In a recent user group presentation the topic of using interfaces to enforce coding standards, ensure component compatibility, etc. was touched upon. The inevitable discussion about the definition of coding to an interface commenced.
The Literal Definition
Most people when first introduced to the concept of coding to an interface or even "design by contract" type concepts take the literal definition. At this basic level the technique means to use your programming languages OOP interface to define the behavior of the objects you will be using and accept objects that implement that interface where necessary, as illustrated in the following listing.
interface Deleteable
{
//some methods
}
class Book implements Deleteable
{
//implementation
}
class BookDataSource
{
public function delete(Deleteable $book)
{
$this->purge($book);
}
}
With this arrangement any methods that are necessary to prepare an object for deletion will be implemented in the Book class and the data source will only allow objects that implement the Deleteable interface to be purged from existence.
This technique is employed to allow better unit testing, for polymorphism, to ensure that objects have certain behavior, and a variety of other reasons. Coding to the contract provided by the interface is a great practice.
An Expanded Definition
While the literal definition above is definitely accurate and valuable, the interface extends into other areas. In modern software projects there are a variety of resourced one can call upon to learn about the behavior and properties of software components. Each of these resources is a part of the contract and useful as an interface to which developers should code.
Documentation
The most obvious resource for defining behavior and properties is documentation. Whether this is some sort of specification document in a wiki, in a binder, on notecards, on napkins, etc., or code comments documentation is a useful interface as long as it is maintained. Maintenance is the pitfall of using documentation as a contract because it is so often and so easily neglected.
Because documentation is most likely out of date — hey, I code in the real world — it is my last choice for an interface-defining resource. However it's better than having nothing.
Unit Tests
Thinking about it, unit tests are the ultimate supplemental contract for code. They will immediately notify the developer if the terms of the contract (the assertions) are broken. They also provide usage documentation that will help integration efforts.
In Your Code
The message I hope to get across with this post is that the concept of design by contract or coding to an interface is broader than the literal implications. Using supplemental contracts for your projects will make your projects better if only for that day in the future when you wonder why you made the decision you did.
Working Outside Your Comfort Zone
No, I'm not going to inundate you with quotes of famous and not-so-famous people about how stepping out of your comfort zone will revolutionize your life. Instead, I'd like to simply encourage you to step out of your box every once in a while if for no other reason than the potential to learn something.
What is My Comfort Zone?
The absolute first step in this technique for improvement is to figure out where you comfort zone is. For a lot of the people the knee-jerk answer is in whatever language they are currently using. This is not a bad answer but it will most likely lead to a shallow experience. For example, my obvious comfort zone is in PHP development. To step outside my comfort zone, then, I'd merely need to read through someone else's project written in Python or even Ruby and then pat myself on the back for each concept or technique I can extract from such projects. However, doing so doesn't really answer the question what is my comfort zone and doesn't force me to get outside of it.
My real comfort zone could be working with a relational database or even using scripting languages. I could easily follow the noSQL revolution for a sample project or work on a project written in, e.g., .NET using C#. These technologies are so different from my normal tools that I'd be forced to think about problems and solutions in a different light.
Different Technologies, Different Approaches
Working with differing technologies is not guaranteed to help at all. In fact the experience can be extremely frustrating because you will come across innovative solutions that simply won't be possible in your "home" environment because of language or technology barriers. This is natural and should be expected. If this weren't the case we wouldn't have such a deep pool of languages to chose from.
Instead of focusing on the negative, keep digging into the project. Given enough time you should be able to find a few concepts from the new environment that you can either adopt or at least adapt into projects in your preferred languages and tools. In my case I inherited a few projects that are written in .NET. Instead of immediately grumbling about how awful it is to work in that environment, I've embraced it and gone on some bug hunting/fixing expeditions through the code. As a result I've learned quite a bit about how another developer uses a different technology to accomplish some of the same tasks.
Read Other Developers' Code
This leads me to the final benefit of stepping out of your personal playground: you get to read other developer's code. I don't remember where but I recently read a comment in which the author stated that it's silly for a developer to assume he or she can continue to expand his or her knowledge without reading peer code. He or she went on to say that this is like a person deciding to become an author without ever reading other works.
At first I resisted the notion that an author must read other's work before becoming a talented author. After all, it's quite possible that a person can be naturally gifted. However, the underlying meaning became apparent. We all must learn ways that work and some ways that do not. Without seeing a variety of approaches there will be no growth. This does not mean that you must immediately adopt what you read. You should look for similarities to your own work as much as you find differences.
A Real-life Example
Like a lot of other web developers I've always held contempt for JavaScript. It's a language that was once far outside my comfort zone. However, the Dojo framework came along and converted me. Using and reading through the code led me to appreciate all the nuances I once despised about the JavaScript language. I listened to talks on the language's history, I learned some of the advanced techniques and concepts presented by Douglas Crockford, John Resig, et cetera, and then I read the specs for upcoming versions of PHP. I had unknowingly adopted some of the functional programming techniques and concepts prevalent in JavaScript and now I could apply them to my PHP projects.
Stepping out of my comfort zone was one of the most influential decisions I've made. I hope you will take some time to do the same.