# Rails Technical Design

**URL:** <https://www.ruby-forum.com/t/rails-technical-design/194169>\
**Category:** Rails\
**Created:** [August 31, 2010, 3:06pm UTC](https://www.ruby-forum.com/t/rails-technical-design/194169 "2010-08-31T15:06:09Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![pankaj](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a9adbd/32.png) [@pankaj](https://www.ruby-forum.com/u/pankaj)\
**Post date:** [August 31, 2010, 3:06pm UTC](https://www.ruby-forum.com/t/rails-technical-design/194169/1 "2010-08-31T15:06:09Z")

</div>

Hi Everyone,

It will be nice if every one can share the process and the best  
practices followed for technical design of a Rails project. May be in  
the end we can come up with a common template(if needed).

Let me start first

Following are the steps I do before starting to code a Rails project.

1.) Identify the resources : like user, article, comments etc.  
2.) Identify the tables and their fields with data types.  
3.) Identify the models and their relationships.  
4.) Identify controllers and actions in them, and corresponding views.  
5.) List of plugins to use.  
6.) Identify methods in models their inputs and outputs(most of this  
is done at run time.)

Regards,  
Pankaj  
[http://www.railsguru.org/](http://www.railsguru.org/)

---

<div class="post-metadata">

**Author:** ![pankaj](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a9adbd/32.png) [@pankaj](https://www.ruby-forum.com/u/pankaj)\
**Post date:** [August 31, 2010, 4:24pm UTC](https://www.ruby-forum.com/t/rails-technical-design/194169/2 "2010-08-31T16:24:35Z")

</div>

pankaj wrote:

> It will be nice if every one can share the process and the best  
> practices followed for technical design of a Rails project. May be in  
> the end we can come up with a common template(if needed).
> 
> Let me start first
> 
> Following are the steps I do before starting to code a Rails project.
> 
> 1.) Identify the resources : like user, article, comments etc.  
> 2.) Identify the tables and their fields with data types.  
> 3.) Identify the models and their relationships.  
> 4.) Identify controllers and actions in them, and corresponding views.  
> 5.) List of plugins to use.  
> 6.) Identify methods in models their inputs and outputs(most of this  
> is done at run time.)

The problem with any attempts to “standardize” the technical design  
process is that different people work in very different ways. Sometimes  
we even approach different projects in different ways.

My general process is practically inverted from what you describe here.  
I generally start by designing the user interfaces first, then let the  
resources naturally flow in support of the user interface.

This basic process is described here:

> **[Getting Real](https://basecamp.com/gettingreal)**
>
> The smarter, faster, easier way to build a successful web application

What you have described above is a model-driven design. This process  
might work if much is known upfront about your system’s requirements.  
However, from my experience, that doesn’t often line up with reality.

The design of the user interface is the primary consideration for great  
software. It should be considered even above features. Contrary to  
popular belief, greatness in software is not directly related to feature  
count. Many of the best applications actually have a somewhat limited  
feature set. Instead they rely on outstanding implementation of the  
features they do provide through intuitive and creative user interfaces.  
To be successful one must focus on providing access to the features of  
an application. Features are of no use to the user if they can’t find or  
understand those features.

Efforts to “standardize” the software development process have been  
attempted innumerable times since the early days of software  
development. Strict engineering principals are almost always  
ineffective, and are in opposition to the creative processes involved in  
most software design.

> **[The New Methodology](https://martinfowler.com/articles/newMethodology.html)**
>
> Agile methods explained by contrast to the plan-driven mainstream at the time. Key differences are adaptive rather than predictive planning and being people-oriented rather than process-oriented.

---

<div class="post-metadata">

**Author:** ![pankaj](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a9adbd/32.png) [@pankaj](https://www.ruby-forum.com/u/pankaj)\
**Post date:** [August 31, 2010, 4:44pm UTC](https://www.ruby-forum.com/t/rails-technical-design/194169/3 "2010-08-31T16:44:50Z")

</div>

pankaj wrote:

> Following are the steps I do before starting to code a Rails project.
> 
> 1.) Identify the resources : like user, article, comments etc.  
> 2.) Identify the tables and their fields with data types.  
> 3.) Identify the models and their relationships.  
> 4.) Identify controllers and actions in them, and corresponding views.  
> 5.) List of plugins to use.  
> 6.) Identify methods in models their inputs and outputs(most of this  
> is done at run time.)

Ack!!! Like Robert, you seem to work in reverse from what I attempt…

1. Who are the stakeholders and what are the desired outputs? (what  
delivers the value for the system?)
2. What are the perceived entities/models and their relationships?
3. Scaffold a proof of concept with basic functionality.
4. Present the scaffolded app for conceptual review/commentary/usability  
comments (‘parking lot’ UI quibbles in the first round or two for an  
‘area’ of the app). See what a concrete example provokes from the  
stakeholders - are the models the right ones, what additional  
information is desired, what outputs, are there additional unforseen  
stakeholders, etc, etc?
5. Iterate at step 1.

Iterations (generally weekly) are a mix of presenting new scaffolded  
items and refining previous items.