I find the current technological moment frustrating because it feels that we are engaging in many misguided practices in the industry. They are common, they are popular, so they are often presented as "best practices." These "best practices" are often applied willy-nilly everywhere, even to the confusion of the people who created the popular framework or process. So even though what I am sharing is not novel, since there is nothing new under the sun, I think it is appropriate to say it again.
We sketch ideas in sketchbooks. When the idea has been proven, we build the machine. The sketchbook's blank pages and cheap costs gives us a boundless amount of possibilities. Let's remember that most of those will be bad ideas, but they are possibilities. Once you start building a machine, you want it to be resilient and reliable. As it becomes hardier, the possibilities are reduced, but we give up creativity in exchange for working on a meaningful machine.
When we have an idea for a new product, we want to take out a literal sketchbook to make some rough drawings and write down notes. We share these notes with others. If others agree that it is good, then we translate our sketches to some slides, maybe a graphic. Then we can share it with friends, customers, bosses, executives, whoever we respect who we need approval or funding to start building it.
If it is still considered a good idea, we translate our idea into some sort of application or program. We start with the simplest prototype. The prototype is meant to answer two questions. Can we buid it? Once built, is it useful?
This prototype should be built in a programming sketckbook. What do I mean by that? It should we something that gets the job done as quickly as possible. That can mean some bash one-liner. Or a bash script. Or something quickly put together with Python, Ruby, or your favorite scripting language. For a web service, that sketchbook may be PHP, Ruby on Rails, or whatever web framework you are the most proficient in. It should be done fast and cheap. The point is to learn.
Here is the place where many of us go wrong. We start building machines too early. Projects that lack customers are started with complex systems built with multiple computer languages, servers, a queue systems, and databases. Conceptually, they are still sketches; just very, very expensive ones.
Once the idea has been proven, we will refine the sketch. We will clean it up; get more details. People engaged in the diagram will make suggestion; at this point, it is easy to include them.
Our bash program may begin to get too big. It may be too slow to run. We begin to make easy adjustments to get better performance. We may rewrite it in a more performant or easier to maintain language. At some point, we are effectively building the machine.
With notebook drawings it is easy know when we are done sketching and when we beging build the machine. With software systems, there is no clear transition, so we must be deliberately aware of where we are. Here are some quick guidelines to know when we have a machine in our hands: it has a lot of users; it makes money; it loses money if it isn't running; losing the program would cripple your organization.
Here is other place where we often go wrong. Many of us, especially the people who created the system in the first place, don't think of our sketches as machines. We still want the speed of change that a sketch has. So we resent how long it takes to add features. We resent how ideas that previously were enthusiastically explored are now rejected by saying that the architecture doesn't allow us to do it. We resist bringing architectural changes. I have seen leadership dislike how their sketch is a machine that demands maintenance. They miss the old days when the limit was their imaginantion. We have to remember that a machine is a success. Success often comes with responsabilities.
Personally I like the idea of starting with a sketch system, and then rewriting it again once it has proven its worthiness. Creating a clear boundary that the sketch only lives until we reach a certain point; after that, we are rewriting, now, when it is still simple to do; now that we have more knowledge of what we need to do; now that we can clean up all of the fail ideas outside of the architecture and codebase. Sadly, this happens mostly with personal projects.
This brings me back to "best practices." Beyond sensible ones, like treating all people with respect, most of these are highly contextual. What is a good idea when you are sketching, writing code quickly to bring it as fast to the customer as possible, is a terrible idea when you are maintaining a machine. Similarly, creating a heavy process with a complex resilient system for my idea of instagram for dogs is premature. I will say that it is a bad practice, because you are burning money on an unproven idea.
This is to say, there are no best practices. What makes a practice good or bad depends on the context. So the next time someone pitches a best practice, remember to bring up whether we are still working on the sketchbook or working on the machine.