Tag Archives: Ruby

Mistake Proofing Deployment of Software Code

This is a continuation of my previous post: Improving Software Development with Automated Tests. Lets look at a typical poka-yoke example. A USB connector must be put in the right way up – for the connection to work properly and the communication to occur as intended. So to mistake proof the process the connector won’t allow the USB device to be put in upside down – the hardware connection designed to not allow that type of connection.

Using a deployment process that prevents code from being submitted that has an error follows a nearly identical process. The process blocks an error from being made. It seems to me a process that blocks code with a bug from being deployed with an error is the basically the same as a USB connection that will not accept the device being put in upside down.

Mistake proofing in no way should limit focusing on improving the process. Mistake-proofing a process both improves it (many poka-yoke solutions make the process easier to use) and prevents an error in case you still try something wrong. So I see the automated tests as a way to serve as a backstop, in case the process improvement you made to the software development process failed in some form. Then the automated testing required to deploy would prevent the introduction of that error to the production environment.

Improving Software Development with Automated Tests

Automated software testing is a mistake proofing (poka-yoke) solution for software development.

The way automated testing works is that software code is written that tests the software code of the application. This automated testing code test that business rules are correctly being followed by the code in the application.

So for example, a user should not be able to create a new account without entering password. Then you create code that does not allow an account to be created without a password. And you write a test that passes if this is true and fails if it is false.

The best implementation will then not allow deploying code to your production environment until the code has passed all the automated tests. So if a software developer changes the code, the automated tests are all run and if there is an error noted by the automated testing the code cannot be deployed to the production environment. So, in the example above, if somehow the changes made to the application code somehow now let an account be created without a password the test would fail, and the developer would know to fix the problem before putting the code into production.

Thus automated testing mistake proofs the process. Now the mistake proofing is only as good as the test that are added. Software development is complex and if the code has an error (based on the business rules) that is not tested then the code can be deployed to production and affect customers. Automated software testing tools are a huge help in preventing many errors from affecting customers.

It seems pretty obvious but until the widespread adoption of agile software development techniques and frameworks that make it easy to adopt automated testing (like Ruby on Rails) this sensible process improvement tool was used far less often than you would think.

Baking in Quality to Software Development

One of the reasons my organizations switched to Ruby on Rails for software development was the great integration with automated testing. We always wanted to have good test coverage on our software applications (which are web applications – some used only inside our organization) but didn’t actually find the time to do so. Since we adopted Ruby we have been doing much better in this regard. It isn’t just the switch to Ruby, of course, but the switch to Ruby coincided with the beginning of many improvements to our software development practices that have continually improved over the last couple of years.

Here is a post on How to build quality software by an agile, Ruby, lean software developer

I’ve mentioned previously about baking-in quality and not having developers throw code over a wall to testers.
…
Everyone on the team is concerned with not only assuring quality in what we deliver, but making it visible to ourselves and the business.

We work in an agile manner, iterating through development with extreme programming practices and Behaviour Driven Development. Facilitating our relationship with the business is Scrum and we utilise kanban principles and systems thinking to maintain a speedy throughput of high-quality work. This mixture allows us to communicate effectively, develop the correct features properly and continuously deploy our work when it is complete, thus maximising business value. I should also mention that we are fortunate enough to have our business people/customer sat across from us.
…
Without testers or a QA team there is no wall over which work can be thrown and the responsibility for quality absolved.
…
The inspection typically carried out end-of-cycle only yields bugs that were low severity and of no real impact to the end user.
…
An agile testing must-have, we use TeamCity to continuously run our unit tests on each check-in. We also execute our Cucumber acceptance tests on scheduled runs. The status of the builds are visible on dedicated monitors around the office as well as a nice 6”² projected screen.

via: @benjaminm

Three Years of Real-World IT Projects In Ruby

Nice webcast by Martin Fowler, Three Years of Real-World Ruby. This talk is probably only of interest to those of you in software development, but for them I think it is an excellent presentation.

At work we have been use Ruby for the last 3 years and have found it to be a powerful language that helps make writing software applications fun. And that is important. By providing a powerful language and a rails framework that takes away much of the drudgery of writing code you can create an environment where develops are happy and productive. We are hiring, by the way.

The talk provides a good background on their experience using ruby to manage projects; and how they manage ruby application development projects.

Joy in Work – Software Development

The wonderful cartoon in this link illustrates the all too common despair in work. Software programmers are more likely to really enjoy what they do. There are many reasons for this not the least of which is that they have a fair amount of control over their careers. If they don’t like what they are asked to do, the tools they are asked to work with… they will (more than others) leave for another job. Some managers get frustrated that such people are not willing to put up with the normal bother everyone else seems willing to accept (programmers are often “unreasonable”). But I see an occupation that is more focused on joy in work than most. And creating joy in work is what managers should be worrying about – not getting troublemakers to fall into line.

Why I Program In Ruby (And Maybe Why You Shouldn’t):

Harmony and balance make you feel good. American Rubyists frequently take up all the points of Ruby’s power, expressiveness, and efficiency, but they don’t seem to register the point that Ruby was designed to make you feel good. Even Rubyists who want to explain why Ruby makes them feel good often fail to mention that it was expressly designed for that exact purpose.
…
Don’t program in Ruby because you want power or efficiency. Don’t program in Ruby because you think you “should”, either. Program in Ruby because you like it. And if you don’t like it, don’t program in it.

I enjoy programming using Ruby on Rails.

IT Operations as a Competitive Advantage

Operations is a competitive advantage… (Secret Sauce for Startups!)

The example above is the tale of two Web 2.0 startups scaling to 20 systems during their first three months. The first team starts writing software and installing systems as they go, waiting to deal with the “ops stuff” until they have an “ops person”. The second team dedicates someone to infrastructure for the first few weeks and ramps up from there. They won’t need to hire an “ops person” for a long time and can focus on building great technology.

In my experience it takes about 80 hours to bootstrap a startup. This generally means installing and configuring an automated infrastructure management system (puppet), version control system (subversion), continuous build and test (frequently cruisecontrol.rb), software deployment (capistrano), monitoring (currently evaluating Hyperic, Zenoss, and Groundwork). Once this is done the “install time” is reduced to nearly zero and requires no specialized knowledge. This is the first ingredient in “Operations Secret Sauce”.

This is a nice short article discussing startup IT operations. On that topic it is interesting. It is also a good example of how a bit of up front planning can help any organizations. Make plans on realistic options – which often means not expecting everything to be perfect. Expect to have to make do with fewer resources than you would like but are what you will likely have… At work, I use subversion, Ruby on Rails (and practice continuous build and test – I’ll take a look at cruisecontrol.rb) and we are setting up Capistrano. I’ll let our system administrator know about puppet (it looks useful) and take a look at the monitoring options (we have something in place now, I forget the name).