Stay ahead and focused
Aug 26

No Line Between Prototyping and Development

In this article, the author tries to remove the line between prototyping and development by encouraging a progressive refactor scalable programming style. By following the step 1 and 2 for each element of the project, you can maintain a decent cost-value ratio at any point of the project.

You might think prototyping is creating new thing, and development is choosing a framework and sticking with it. Well, actually the line between them are pretty fuzzy, because at one point of the development, you might want to design a new thing, and after you prototype it and you'd like to turn it into production where further development can be continued. If you really want to draw the time-line, that's when we get the second round of funding.

Let me explain this process using the following business idea that currently just generates a table row

    <tr>
        <td class="area" data-tip="Graphic Design and Page Layout">Web Design <i class="fa fa-info-circle"></i></td>
        <td>
            <div class="rating" data-score="4.5"></div>
        </td>
        <td>
            <a href="http://google.com" target="_blank">
                <i class="fa fa-external-link"></i>
            </a>
        </td>
    </tr>

The look,

    tr {
        margin-top: 10px; 
        font-size: 1.4rem    
    }

And the feel,

  $('td.area').qtip({
    content: {
      text: function(event, api) { return $(this).attr('data-tip'); }
    },
    position: {
      at: 'bottom center'
    }

First time

When you are prototyping an idea, you are not concerned with the re-usability of the code, because we don't know if the idea can be reused at all! So don't spend too much time doing that type of thinking, you're just wasting your time there. Without a context of optimization, optimization should not exist. It's like a equation with too many unknowns, can't solve :)

It'll be challenge to choose a framework at this point without knowing where the project is going either. Therefore you can not settle with any framework other than just picking some small programming pieces. For instance, here we have css, js, and html sitting in the same file referencing to a qtip jquery component.

That's all you need to get your idea there, a good analogous to this is that a painter just need brush and canvas, a writer just needs a pen and paper. We just need html (css/js) in their raw format. Most of the brilliant ideas comes with this format, so don't be shamed that you are doing it this way. To be honest, this might be one of the most efficient formats, when it come to brain-storming.

One More

Idea comes alive very quickly, once you show it to couple of people and get accepted, and you'll be happy to continue your work. And one obstacle you'll see immediately is more pages or elements that are similar to what you have done. This similarity creates a annoying debating issue.

  • Should I copy and paste, OR
  • Should I do some refactor ?

Well, it depends. Maybe you should just do both.

So the first thing comes to anybody is to CTRL-C and CTRL-V, it can't be any easier than that to steal your own work. Depending on how frustrated you realize wasting your talent brain cell for duplication and minor changes, sooner or later, you might start to think about better ways of doing it.

Let's use CSS as example first, you might want to relocate that piece of line to a separate CSS file so that it'll apply universally to all your HTML pages. Similarly, you can relocate JS file as well. And the same time, you might want to add more general identifier for CSS tr and JS td.area so that it'll apply to similar elements across pages.

How about the content ? What if this section will appear couple of times in the same page or different pages. In order to reuse it, we could refactor them out into variables that somehow injected back during templates generation.

    ---
        title: Graphic Design
        rating: 2.5
        url: http://www.google.com
    ---
    <tr>
        <td class="area" data-tip="Graphic Design and Page Layout">No Line Between Prototyping and Development <i class="fa fa-info-circle"></i></td>
        <td>
            <div class="rating" data-score=""></div>
        </td>
        <td>
            <a href="" target="_blank">
                <i class="fa fa-external-link"></i>
            </a>
        </td>
    </tr>

More

That's good. You probably won't see much benefits if you don't end up with adding more than 3 similar content. But when the duplication actually happens more often, you'll be happy that the work is much cleaner, and you don't have to type the duplicated part of html, css, and js over and over again. And especially when you have to make changes, you have less place to look for the touch up.

That's why the copy-paste and refactor are two sequential steps of this problem. I want to point out that two mistakes that we tend to make here.

  • skip step 1 and jump right to step 2. You think you are a pro, and you're confident that the material is going to be reused somehow. Well your guts might be correct, but 100% of times your guts is wrong in a prototyping project, or prototyping ideas inside a legacy project. Don't trust your guts in this case, always start with step 1, it's easy and most importantly, cheap. Don't put your ego into this game. Just saying "HTML" won't make you less PRO.

  • stay on step 1 and never goes to step 2. People might tolerate this behavior in a quick project. But for a well established project, this is a dead end, since it builds up your development cost very quickly, especially when it goes to the maintenance. Shareholder can't control or sometimes appreciate the efforts that we put into architect V.S. just-look-OK. If it'll cost you to maintain it as much as the development, will you still call it OK? Probably not. In realty, it's hard for them to find out.

The thumb of the rule will be always start with step 1 and if you get more duplication, start step 2 right away. If you don't get more duplication, or a change is requested, stay in step 1. Steps are designed for every element or every decision you are going to make, therefore it's not necessarily a giant step 1 and 2 for the entire project. Oh, people do giant step, it's called transitioning from prototype to development. When that happens, they also switch teams. IMHO, it's not a good approach, both ethically and financially in the long run.

Summary

In short, I encourage the development team not to draw a clear line between prototyping and development, instead look out for duplication and constantly practice the copy-paste and refactoring for each element throughout the project cycle. Therefore at any point of the project, you can maintain a decent cost-value ratio without over-doing or under-doing the work. This methodology can be equally effective in new project or adding new features to existing project.

Comments