Posts Tagged ‘TDD’

LSRC 2009 – Day 2

August 30th, 2009

Dave Thomas Keynote

Always a great speaker, Dave came down from Dallas to help kick off the conference.  Dave has been using for over 10 years, and he’s still using it.  He shares his reflections with us as to why he still enjoys programming in Ruby.

Ruby is an interesting language.  It can be described as a multi-paradaim language: object oriented, procedural, prototype-based, and functional (all at the same time).  He also points out that Ruby thinks the way he does, which also means – like Dave (or anyone of us) – it’s imperfect.

We shouldn’t worry about perfection though and instead should be pragmatic.  There isn’t only one way to do anything in Ruby, there is no “right way.”  It’s this ambiguity that helps encourage participation.  If Ruby were perfect there’d be no room for creativity, growth or adaptation.  Ruby is adding stuff – not taking away.

Dave also talked about his experience with being publicly “slammed” by Zed Shaw. He said he realized at that point in time that Ruby is not a community.  Ruby is a tool around which communities form.

Passionate people are messy, Ruby is messy.

Programming Intuition

A lot of people are programmers, very few are great programmers.  The difference in productivity between a good programmer and a great programmer can be a factor of 10.  Ruby rejects the idea that the world is simply two buckets of good and great.

  • Do one thing
  • DRY (Don’t Repeat Yourself)
  • SLAP (Single Level of Abstraction Principle)

How do good programmers think?  Does a good programmer simply boil down to command of the language and ability to recognize/use patterns?  NO!  Programming deals in abstractions and great programmers talk about code as if it were not abstract, but in tangible terms.  Good programmers can “feel” code, there is an emotional reaction.

Our brains are made to adapt to our environment (which we perceive through our senses).  Humans are wired to want physical attachments.  What senses do programmers use?

  • vision (why OO is “easier”)
  • hearing
  • kinesthesia (perception of movement, weight and position)

Code is not 2D, it’s not even 3D, it’s multi-dimensional.  So diagrams are not always useful.  Code sometimes has a “viscosity” and can be felt to push back or resist you.

What do we perceive as beauty?  Elegance?

Cultivate a Sense of Code

  • No specifications / think about it
  • Use tools that help you
  • Practice, use methods that provide immediate feedback

Experts operate on intuition, not on recipes or rules.

  • Master Ruby’s method lookup (it’s worth knowing)
  • Useful to limit scope of magic
  • Can modify individual objects with modules
  • Tr to replace inheritance with extends

Succeeding with Ruby on Rails

This talk was about the owner of Thoughtbot and how they got to where they are today.  Below are some of the notes from the talk:

  • Started in 2003 with 4 people
  • Not everyone wants to run a company
    • wanted to go into business to work the way they wanted to
    • happiness is very important
  • Perl was their “happy language” from Java, but Ruby and Rails ruined it
  • Decided to only do Ruby on Rails, revenue skyrocketed afterwards
  • Hiring is very important and hard
    • hire only people who want to learn and teach (passionate)
    • skilled
    • right attitude
    • salary (the best you can afford, not necessarily that money can buy)
  • Don’t compromise on core principals
  • Be nice

Identify what’s really important for you, don’t compromise on that decision, and be nice.

Hiring Process

When hiring people Thoughtbot first reviews a resume and code of the applicant, before they even do a phone interview.  Then an initial phone call is done, followed by a second interview if there is interest.  The 2nd interview is more technical in nature.  If an application is considered, they have to participate in a week-long immersive pair-programming situation with a developer on staff.  After this last step is then someone considered to be on the team permanently.

Core Principals

  • sustainable development (40 hrs a week)
  • all are technicians (even html/designers)
  • no contracts or outsourcing

Clients

When it comes to client relationships the approach Thoughtbot takes is to “do the best you can.”  This doesn’t always mean you succeed at every project, but you know that you did your best in trying.  Set expectations, be proactive and above all nice.

Thoughtbot does not believe in subcontracting and they insist you should work on the way you want to work.  If a client doesn’t want to work with you then you should ask them to find another team.  In the long run it isn’t worth being unhappy and you’ll just be frustrated (as will likely the client), all around bad.

Client Management

  • project planning form
  • Highrise
  • master services agreement
  • project lead (SM/PM rolled into one)

Design and Development

Like 37Signals, Thoughtbot is a big believer in design first.  They will figure out how a UI looks and works before coding.  This helps flesh out details you might not realize until later, when it’s more expensive to fix.  They practice pair-programming with an iterative, TDD development approach.  Pivotal Tracker is used to manage their backlog.

They also believe strongly that people should do what they enjoy.  Folks are encouraged to work on projects that interest them, there are not set roles or boundaries.  If a designer wants to get more into Rails, he’s allowed to take on some Rail work in a project.  There is always at least two developers per project.  If one becomes bored or wants to work on a different project it makes it possible to swap people out without affecting the project to terribly.

Open Source

Part of the culture at Thoughtbot, they’ve made many open-source contributions to the Rails space.  Abstractions don’t stay internal to the company.  By releasing open-source software they get their ideas validated and legitimized.  Payback includes recognition in the market space.  They also have to support the software less, because the community itself supports the software (crowd-sourced support).

The one suggestion for other companies looking to do open-source contributions:  keep quality high, incubate internally for a while before releasing, make sure it’s something you enjoy using yourself.

Products

The talk ended with the question about why and how do you keep Ruby relevant?

  • consulting scales w/ people
  • but we want a small company
  • products can scale without people
  • make products you use yourself
  • make products you enjoy using

How long will Rails be around for (be popular)?  How long will Ruby be around for?  We have to take responsibility for Ruby and Ruby on Rails so it remains popular.

No comments »

Posted in Programming

Tags:

What’s TDD?

October 22nd, 2008

TDD is often viewed by managers, like paired programming, as a huge time suck. This is primarily due to a fundamental misunderstanding of what TDD is – it’s not just about testing.  TDD offers more value than simply a passing test.  Time spent wisely now will avoid big time sucks later.

TDD (and BDD, but I’m going to focus on TDD for simplicity; BDD is about behavior but very similar) is an approach to programming that is particularly popular in Agile development circles. Properly done TDD feels something like this:

a)  First you think about what test will best move your project forward.  (This part can take a while, take your time)

b)  Next you go RED, that is you write the smallest amount of test code that fails. (Less than 5 lines, please – should be a min or less of writing)

c)  Go GREEN. Write just enough code to get your test to pass, no more no less. (This helps you focus on not over-engineering your solution – should be a min or less of writing)

d)  Refactor your code and tests. Look for things like duplication and other “code smells” or if something doesn’t read elegantly and can be written better. Remember 90% of the life of this code will be spent in maintenance, so make it easy to maintain! You should continue to stay green as your refactor. (Take as much time as necessary on this one)

e)  Repeat, again and again.  You’ll find that after an hour you’ve done about 25-50 cycles.  TDD can be intensive, and it’s completely normal to cycle through a this pace.

Are You Wasting Time?

It depends what your goals are. If you want to write software with a low confidence of quality then by all means write code without tests. Your users will politely point out the bugs to you when they encounter them, to your embarrassment. You’ll need to take precious resources off existing projects and tasks, get them to research what’s going wrong, determine if it was supposed to be designed that way (maybe you just arn’t handling that expected error in a nice way, or maybe that error shouldn’t be happening to start). Poor customer satisfaction, project delays, and a lower team morale—what is that worth to you?

The Facts

The fact is all code has bugs, some more than others.

How fast can you identify them?

A failing unit test typically will tell you exactly what line in the code is failing. You could also go in manually poking around, but that takes more time. A suite of 700 tests can be exercised in under 7 seconds. Can a human being test 700 operations/functions of an application in that time? Probably not.

Writing tests while you write code doesn’t take any more effort than if you wrote the tests last. The difference is you identify bugs and issues sooner, which allows you to adapt quicker and fix the problems before they become problems. And remember kids, the cheapest time to fix a defect is at the time of the code’s authoring, and the most expensive when it’s in production.

Limitations of Testing

Testing isn’t a silver bullet, and as I said earlier – all code has bugs. Tests will greatly improve your code quality though. There are some things to keep in mind:

a) Developers tend to write “clean tests,” that is they don’t often think about edge-cases or ways in which the software might be utilized

b) Developers tend to have an optimistic view of code coverage. Many think they’re 95% covered, but in reality the best developers are probably around 80% and the worst 30% (McConnell, Code Complete 2). There are tools that can help measure code coverage.

c) Developers tend to skip more sophisticated kinds of test coverage. You might have 100% statement coverage, but it doesn’t mean all the branches are tested (eg. all the true/false, if, ifelse, else, etc).

Final Closing

TDD helps you write better designed code and applications.  It keeps you focused on the task and helps prevent over-engineering.

TDD helps you write code that is testable, after all it IS tested.

TDD helps you identify problems sooner both in design and the code itself (syntax, operations, etc). Identifying these sooner than later equals money saved.

TDD lets you refactor your code with confidence and deploy with confidence.

TDD doesn’t take any more effort than writing tests last, probably less.

No comments »

Posted in Programming

Tags: