RoR in enterprise – lessons learned
After a while my first enterprise prototype is finished and I have to summarize what was right and what was wrong during the period of prototyping.
Really nice surprise for me was the way of communication. The requirements were formulated more precisely then any requirement before, but not from the beginning. When I did start, the requirements were very vague, but after first screens and first few features the communication was excellent and clear. This was the phase of fundamental principles and relations creation.
After some time, the flow of requirements was stronger and stronger. It was necessary to start requirements management – yes, it is true. You cannot get rid of it.
In the middle of development users started to use it and a new set of “handy little” features was requested.
Later the system became very important and the users started to solve real production issues using the system.
Now, the system is almost finished. I mean – the necessary features are there, but sometimes it is not consistent. Especially the stuff that is used rarely. The enterprise is pushing me to pass it into production regime.
And what are my lessons learned?
- The start will be painful. Be prepared to completely redesign the code and model.
- Scaffolding is for some time more than enough.
- It is not necessary to focus on good graphical desing from the beginning. Focusing on features is more important. In my case I did implement a nice design after 80-90% of features was implemented. And in fact, I did it because the environment was really ugly, not because customer did ask me to do it.
- Make sure you find the right group of people to prototype with. It is impossible to create a prototype without business experts.
- It is not important how much you boost your performance using good tools. You will always have more requirements than could be implemented. Requirements management is a must.
- Communicate clearly that you are working on a prototype. Otherwise you will be forced to make it a real application. Here I started to think about using grails for prototyping. Nevertheless, I have no experience to decide if it was a good idea or not.
- Be prepared for success! The application that will be created is in line with the requirements and heals the biggest pains of the business users. It is highly probable that the users will love it.
- Do not stick with one technology. Anything that makes the process faster is valuable. Eg. I did use Sybase PowerDesigner to generate “history keeping” triggers automatically. Adding a new table to my model was just few clicks and assigning the right trigger template.
- And last, but not least. Listen! Listen more! And make sure you understand that you are not the one who knows the business. You came there to help them to communicate their needs, not to show them how to do their business.
Now I must say, that Ruby on Rails is a great tool for project communication. It is able to communicate user requirements very efficiently and precisely.
![]() | Published on October 23rd, 2007 | | 4 Comments | | Posted by Roman Mackovcak |