Beginner Tip: Soft Deletes in Rails

When you are learning Rails, all of the tutorials teach you how to delete an object from the application. This means actually deleting a row from a table in the database. However, this is actually quite rare in the real world. There are laws and other complications that restrict the ability of really deleting data. This means that we need to hide the information instead of deleting it. This is called a “soft delete” or a “logical delete”. When you remove the data from the DB, it is called a “physical delete”.

So how does one go about hiding information instead of removing it? It’s actually quite simple.

First, you need to create a flag on your model that shows whether an object is deleted or not. I personally like to say whether something is active instead of deleted, because it means that when I go looking for things to display, I am looking for a positive. For this example, we will be hiding blog articles.

A soft delete has two parts

  1. In the destroy method, toggle the active flag to mark the object as inactive
  2. use a named scope to access only the active objects instead of all of them

Let’s look at some code.


The Problem with “Real Developers”

Software Development has a huge problem that, if left unchecked, will kill it. I think we are seeing evidence of this toxin already. It’s the idea of “Real Developers”. This idea that unless you do certain things and act a certain way, you are not, regardless of what you can create, a real software developer.

This idea comes out in languages (Java vs .NET, Ruby vs php vs Python, etc.), tools (real developers use vim), hardware (all Ruby developers use Macs) and so on. It also manifests itself in how we code; real programmers refactor or use TDD or don’t use TDD. We are setting the entry bar so high that no one will ever want to become a developer.

The question I want to ask is why? Software development doesn’t need gatekeeping. Instead of putting people down for doing things differently, we should be embracing every person that wants to be a developer. Instead, we create artificially high entry and performance bars, write articles about how hard development is, and only hire people identical to ourselves.

The logical extension question is why are developers so threatened by people that are different (race, sex, ideology)? I have my theories, although writing about them will probably get me in a lot of trouble. So all I will say is that it needs to change. We all need to work at helping software development to grow up. We need to move tech out of its college years and help it move into its thirties. Software development should become ubiquitous and we should be the ones helping the world fall in love with what we do everyday.

Now, don’t misunderstand me, I am not against healthy discussion. I think understanding what good development means is very important. But at the end of the day, does it really matter if someone uses Vim, RubyMine, or Coda 2? If a website works and solves users’ needs does it matter if it was created in .NET, php or Ruby on Rails? Does it really matter if a refactoring was taken to what you think is its logical conclusion if the application works?

A culture built on teaching, openness, and growing talent will get us a lot further then the mirrortocracy that we have now. Until tech is a healthy mix of sexes and races, we have work to do.

An old idea to cure Impostor Syndrome

Over the last few weeks, I have come across a number of articles talking about or referencing “Impostor Syndrome”. It’s the idea that you feel like you don’t belong, that you’re are a fraud, and you will be found out someday. Is this a new problem and is it becoming more prevalent? In short, yes and here’s why.

Once, not that long ago, if you wanted a career, say as a swordsmith, you would go for a stroll and talk to the village weapon maker. If he liked you, or your family paid him enough money, he would take you on as an apprentice. You would spend your days stoking the fire, gathering supplies and, probably, making nails and putting swords together. Eventually, you would get the chance to make your very first weapon.

Eventually, after many years, you would know everything your master knew. This meant it was time to leave; time to seek out new teachers. You would journey around the countryside learning from all the other masters in the area. Once you knew their secrets, you would find a village and set up shop.

And then, one day, a bright-eyed kid would ask you to train him, and the cycle would repeat.

Today, we have a myth that anyone, especially young people, should be able to create Facebook or Google on their own right out of school. Apparently, people with no experience are smarter than those with a career behind them? Huh?!?! With these kinds of expectations, it’s no wonder we have a high number of people suffering from impostor syndrome. We are doing literally nothing to help them along. We throw them in the deep end and then mock them when they make mistakes.

This has got to change. We need more companies that know how to grow talent and skill. We need to re-implement the apprenticeship model and allow junior developers to be mentored by more experienced professionals. There are a few companies out there that get it. They understand the idea that strong developers need to be grown and nurtured instead of thrown to the lions to see if they will survive.

Foundation quick tip: columns and breakpoints

This is just a very small thing that I figured out about Foundation and figured I would share. In hindsight it is kinda obvious, but I don’t remember it being mentioned anywhere in the Foundation docs.

When setting up columns in Foundation, you have three sizes to pick from: small, medium, and large. The trick, if you want the divs to stack on smaller displays is to set the size for the screen width were you want the columns to appear. So, if you want your divs to be stacked on small screens and columns on medium and larger screens, then use medium.

Agile and Creativity

There is an interesting conversation asking “Is Agile the enemy of creativity and innovation” over on the Agile and Lean Software Development group on LinkedIn.

There seems to be an idea out there that Agile, with its discipline and need to release often, leaves no room for creativity. Although I have worked with teams were this was definitely the case, I disagree that the blame for this should be placed on Agile. To me, this is a people problem, or more specifically, it is a culture problem. Each of the teams that were lacking in creativity put releases first and foremost and did not see the benefit of creativity. They had very tight roadmaps and lacked the open space needed for innovation.

I think it is too easy to blame the processes or methodologies in place and to avoid looking at the people, but, when it comes to software, everything starts with people (even the Agile Manifesto starts with people). People will put importance on what they value and what is important to them. If a project manager or developer thinks getting software in front of customers is important, then that is what the team will work towards.

One way to ensure that creativity is part of Agile is to add it. One team I worked with, we created stories for things like aesthetics and styling. This simple step dramatically increased the visual quality of what we released as it gave designers time and space to work. It also provided time for the developers to work with and learn from the CSS experts, making the entire team stronger. Another team would pair a designer and a developer together when working on any story that touched the front-end. The developer would do all the HTML/CSS and the designer would guide the process. This greatly decreased the back and forth with the final design.

However, I am not sure that design is what the person asking the question had in mind. The problem with creativity is that it is messy. It requires time to make mistakes and time to iterate. Design Thinking has a step called divergence in which the entire team brainstorms ideas for a problem. From those ideas, the team then runs experiments to try and converge on the solution. It is what allows companies like IDEO to be as innovative and creative as they are. They take time to be wrong, a lot.

In order to be truly creative, you need the space and time to fail without that failing being a failure. And many development teams are not willing to take that time. They want to development the right solution the first time and then move on. This is not Agile, this is the culture of the company and what they hold as important.

Personally, I think Agile aids in creativity as it holds people, collaboration, and conversation as values instead of contracts, processes, and tools. To be creative you have to start with people and Agile does this. In addition, it builds in a process of getting better in the form of retrospectives. If someone on an Agile team feels the team is not creative, they have the opportunity to talk about it and see if they can bring about a change.

Instead of killing creativity, I think Agile can foster it and help it grow, but only on a team that understands that creativity and innovation must be part of the teams, and companies, culture.