Humorous design decision of the day: Color coding titles

We are replacing a couple of spreadsheets with a web application. One set of spreadsheets had data separated/categorized into "orange section" and "green section". These were the background colors of the data in those sections. This data really belonged in a wiki, but that is another story. Anyway, everyone started referring to the data by color: like "Is that the orange data or the green data?" The users did not want to lose the distinction of the colors because now every one refers to the orange data and the green data instead of their proper names (which are pretty ambiguous). To keep the orange and green I made the background colors of the page names orange and green to match the spreadsheet. When we showed these pages to the customers they were very excited that we managed to incorporate their color scheme into the application. Sometimes it is the small things that matter the most to the customer.

Why Ruby and Rails?

"Why should we use Ruby and Rails?" has been popping up at work over the last month. Managers are worried about retraining the Java developers. And the Java developers are worried about wasting their time on some fad. Here are my reasons why you should be using Rails to build a web site.

First, Rails is a web framework, nothing more or less. It claims to do nothing but allow developers to easily create websites. It makes hard problems trivial and impossible problems doable. It claims a 10x improvement in development time. That claim is VERY DIFFICULT to believe, so I will address it later with examples from my current project. Rails should be thought of as a Domain Specific Language (DSL) for web applications. Writing templates or views of web pages is eased with many helpers.

Think of scriptlets in JSPs, but terse code that makes sense. The helpers range from creating links to creating whole forms. All of this goodness is packaged up in an MVC pattern. Unlike Struts, which also claimed to be MVC, there is a single layer for Controllers; each layer is contained in its own directory. Another benefit is the directory layout is standard. If you know the directory layout, every Rails application will be familiar to you. This is a big benefit after you have switched to your upteenth Java project which has it's own directory structure, completely different from all of those that came before it.

Second, you get RESTful web services for free. I can't stress this benefit enough. When you use the generators for Rails you get the server side of a the web service. Building the client is trivial. Remember I said I would prove the 10x improvement in developer time? We are building an application which will have many clients. The clients are mostly Java, so a developer was assigned to write the client for the RESTful Rails application. He decided to write a parser in Java. This took a couple of weeks to write and test. And from time to time we find new bugs in the code.

However, we could have written three lines of Ruby that would have done the same thing. I literally implemented the same thing he had been working on for two weeks in 10 minutes. 8 of those 10 minutes were trying to find the documentation on what needed to be written (sadly when I showed him the Rails way he shrugged and said, I know how to do it this way and I already have this time spent on it. Maybe I should have explained sunk costs). 10 minutes vs 2 weeks, 10x improvement in speed might be an understatement. This isn't the only way Rails improves implementation speed. Writing database queries are a breeze.

Rails comes with its own Object Relational Mapping (ORM) tool called ActiveRecord. Similar to Java's Hibernate in functionality, ActiveRecord improves development by making complex is easy. Rails provides generators to create scripts to create tables in your database of choice (support for many databases is provided including MySQL and Oracle). The generator also creates a Model class for each table you have in the database. The Model class is where you write the code for business logic and any methods needed to access the data. Except, you don't need to write much because Rails provides many access methods without the developer needing to write any code. Rails also helps by providing helper methods to create relationships between objects. ActiveRecord provides support for one to one, one to many and many to many relationships with just a single line of code in each Model class or two lines of code in each Model class for many to many relationships (technically you can do many to many with one line of code in each Model class in the relationship, but that method has been deprecated in favor of the more flexible two method approach).

The last time saving feature of Rails is that you can use Ruby gems in your web applications. Gems are like Java's jar files, they are packages of code that can be thought of as a library. Gems easily support dependencies so having a Gem that requires ActiveRecord is easy to create, which means you can create Gems that natively work in Rails applications. Need a User object in your application? Download one of the many authentication gems available on the web. Find the one that suites your need, install it and you are ready to go. Need to upload files? Install a file upload gem. This capability is available in Java applications too, but for some reason they are more complex.

Finally, Rails is a simple and easy way to get a web application up and running. A developer can finish a week long Rails course with enough fundamentals to be ready to go write a Rails application.

Skinny User Stories, Fat Unit Tests

One of my colleagues is continuously trying to improve the processes on his project. It is a large enterprisey project with requirements people, testers and a few developers. My friend places high value on knowing exactly what needs to be done and therefor has strived in the past to have very detailed user stories that includes expected behavior and constraints as well as test criteria. He and I had a conversation that restarted his consideration of the user stories. He likes that they are defining the "truth" in only two places, the user story and the code.

While you are defining the truth in two places, I would say that only one of those places has any long term value. The code. As soon as the sprint is completed, your requirements, especially if they live in a tool like Rally, only exist for the sprint where the code is written. After that sprint, it is doubtful that documentation will ever be read again. This is why specs should be light weight. They are only used for a moment in time. Any time that you begin talking about the specs again, you will have to repeat yourself because invariably one person in the conversation will not have a full understanding of the requirements and you won't have the time to send them the requirements to read. Now is a developer going to go through Rally, or any other tool for that matter, to read the requirements for code? No.

The best place to store requirements is in the Unit Tests. Theoretically, you hope to only have one truth, and that one truth has to be the Unit Tests. Every other type of spec is disposable or maybe a better word is perishable. The specs will go away. The contract will go away. The shall statements will go away. The tasks in Rally or JIRA will go away, but the tests will always remain. "Why does this code do
this?" Should always be answered by "look at the test." This doesn't mean leave comments in the test, it means make the test methods the spec.

I've never really been able to put a finger on why I am so against requirements. It seems irrational and crazy. But I think I understand it better now. I have known subconsciously that the requirements are perishable. That they change. They change as soon as you put it in front of someone and show them how it works. The requirements are never absolutely correct. And if they are right, have you put to much time into managing them?

Lessons Learned:
* Requirements are perishable, their shelf life is the length of a sprint.
* Tests are the ultimate "truth" of the requirements of a system.

Don't change my code!

Dear developer peer,

May I bring up a delicate subject? You were offended because I changed code that you had written. You got upset because there was some sense of ownership of the code. You put time and energy into the code. You had to sweat to get the code to do what you wanted it to do. You pressed CTRL+C and CTRL+V six times to get the code in the right place, and write some very funky if statements to get it to work correctly.

All of that was lost to your wailing about lost code is that now TWO people have had to spend time trying to understand what the code does. Your time and mine. I needed to alter the behavior of your code in some minor way, but before I could do that I had to go through and figure out the twisted logic. What gets lost is that I am offended when I find in your code of 60 lines of nested ifs (4 deep). I am offended when after spending 45 minutes trying to understand the intent, I can, in 10 minutes, convert said atrocity to 20 lines and 1 if.

You yelled at me because I wanted the code to be "my way". And that "there is more than one right way". But when your way is 9 if statements and mine is 1 then, well, I don't feel bad. I changed your code because I was offended. I never got a chance to tell you that because you were so pissed, so, now, 10 hours later, I am telling you. If you don't want me to change your code, then write clean code that doesn't offend me. Write code that doesn't offend the compiler. Write code that won't put the CPUs at 100% for 25 seconds. Write code that lets the database limit the dataset instead of returning everything and then looping through it to discard what isn't needed. And for sanity's sake, don't have the exact same code copy and pasted six times in the same method/function.

And don't take this as me thinking that my code is great. I know my code sucks. I look at the code of other developers that I know are smarter than me and try to mimic their style. I try to improve my code every day. The difference between you and me is that I know my code can be improved and would love it if someone came in and showed me how.

Getting Creative

My son and I were having a conversation about some of his writing the other day. I told him that he needed to be more creative in his writing, and one of the best ways to do that is to give yourself constraints. Here is a great article about why constraints are a great way to get creative:

Next, creativity is all about connecting things. It is about knowing x and knowing y and then figuring out that if you put x and y together you will have something awesome. Often x and y are completely unrelated, but just knowing them helps. That means you have to start to learn lots of x's and y's. And they don't really need to be anything in particular, just... learn.

Open your mind to consuming information. And practice. Then put yourself in a position to create something and then CREATE! And do it by giving yourself constraints and using things that you already know.

Improved Office Arrangement

I propose that office arrangements should be re-arranged. Currently the bosses sit in offices and the workers sit in cubicles. Managers are always talking to each other, so if they sat in cubicles it would facilitate communication amongst managers. Also, putting the developers in offices would allow them to stay in the zone because they would have fewer distractions.

Managers say they need offices because the meetings they have require privacy, but I imagine that if those meetings were held in the open more collaboration would happen. They say developers should sit in the open because they need to communicate, but all of the times that I have ever "communicated" I was with a manager.

Who knows, projects might show up on time for a change.