This post originated from an RSS feed registered with Ruby Buzz
by Robby Russell.
Original Post: Keeping the Code Organic
Feed Title: Robby on Rails
Feed URL: http://www.contegix.com/rss/feed.xml
Feed Description: My reflections on programming with Ruby, Rails, PostgreSQL... and learning how to run a business...
The landscape around us is quickly changing—really, it has been changing for some time now—we’ve come a point where we admit that it’s okay to want more for less. We want more features, in less time. We want more control, for less money. Why? When did we collectively decide that huge monolithic systems could be completed in a fraction of the time it should take?
After years of working in .NET, PHP, Perl, and even a little Python, I have gone down the road of simplicity. I want simple looking code (thank you Ruby). Code that I can hand off to another developer and for them to simply get it—which helps to keep things moving. It’s about getting the project done.
Scenario: The client wants delivery in X days, so you aim for Y days early. Shortcuts get made, tests are forgotten, code is blemished, and deadlines still manage to sneak by unmet. Why do we do this to ourselves?
I say, no more!
Sacrifices Are Okay
What? You mean I can choose to leave something out? I can—dare, I say—tell my client no? Yes! Well, maybe. It’s time to re-think how you view your projects. Have you asked your client, “What is the single-most-important feature of this project?” Every project has one. Your customer will likely be relieved to hear that you care about the purpose of the project. And it gives you an idea as to where not to make sacrifices, which in turn helps to identify the areas where you can.
So, if you haven’t asked them yet… ask them now.
The Big Picture
If things change, how will it impact your timeframe? When your schedule is threatened, it becomes easier to see what isn’t necessary, or perhaps, not necessary right now.
All features in a project are part of the big pictures. If you ask your client what is required they will almost always respond with the all to easy, “everything.” Simply accepting this as fact often leads to shoddy workmanship in favor of giving your client “everything.” To the client it may seem like you aced the test, but that’s because they don’t know you’ve cheated. I’m sure a lot of you know what it’s like to inherit the code of someone who has done this, and you know you’ve probably been on the other end as well.
A Neverending Story
Projects aren’t just instantly created, they evolve. They need to be fine-tuned, maintained and should most certainly be refactored when necessary. Most projects require ongoing work… because requirements do change.
It’s time to stop and really consider how you approach both your clients and their projects. Can the next project be built in an evolutionary fashion? Can you focus on one new feature at a time, maintaining your tests, and avoiding bloat?
“Big fleas have little fleas
Upon their backs to bite ‘em:
Little fleas have lesser fleas
And so ad infinitum.”
I found this in a book that I picked up at the local Library booksale for something like 20 cents. The book, The New Utopians by, Robert Boguslaw was written in 1965 and has some insightful thoughts on systems as organisms.
Keep it Organic
Pesticides are not necesary to produce quality produce. They are a cheap shortcut that can cause other problems in the longrun, and are generally not a healthy addition to the lifecycle of the fruit or vegetable (or to those who harvest it and consume it).
Test-Driven Development allows you to constantly monitor the behavior of your application. Feature-Driven Development keeps your team focused on what is currently the most important piece of your project. Don’t rely on pesticide, let the project flow the way it wants to.
Keep it Flexible
Business Rules should not be flexible… but they should. That sounds confusing, but it’s not. Know where to make that distinction. Add your rules first… build your tests… then code. Maintain flexibility through your rules.
Test First. Code Second. Lather. Rinse. Repeat.
Be Proud of Your Code, But Not Blinded By It
You’re biased. Your code is biased. The opinion that you have about your code is biased. You are proud of your code… but you can do it better and some people are better at somethings than you are. Don’t dwell on it, embrace it.
How many of you are making the mistake of being the only programmer on a project? I’m not a big fan of big teams, but I know that small and focused teams are extremly productive and better positioned for the big projects of tomorrow. Find someone that you trust and trade peer-review time. Not sure where to start? Pick up a copy of Refactoring. It’s time that you RE-think how you are doing things.
Embrace Heuristics
It’s time to challenge yourself. A new year is almost upon us and we’re all behind on our goals… because things change. This is the time to explore your possibilities. Learn something new. Don’t be afraid to break things. Just learn why the thing broke. Learn to be a good tester. Learn to write cleaner code. Learn to refactor your code. Learn to make it readable.
Previous Topic
