Changing Perspectives

February 17, 2010

“In the early days of our industry, programmers wrote in assembly code, selecting registers in which to place variables and managing memory explicitly. If we had magically provided these programmers with a Smalltalk compiler, they might have asked, “How does this help us select registers? How do we allocate memory?” They might have concluded, “”We don’t want no stinkin’ Smalltalk!”

Old and new programmers are still writing programs, but the technology to achieve the goal has changed. When a new technology is sufficiently different, you can’t evaluate it in terms of the old technology.”

Source: Stephen J. Mellor, Letters section, IEEE Software, March/April 2004

Sometimes new ways of doing things come in our life and it might be difficult to adapt. If you are used to drive a car and you take a train, you don’t ask how you are going to “turn left”: the train just follows the tracks. However, you have now to go to a station, buy a ticket, look at timetable, etc… This could be the same thing with some of the software development approaches that have recently become popular.

Functional programming, domain driven design or frameworks that favors convention over configuration like Ruby on Rails can offer a new perspective about what you have to do to develop software. If you have the time (and the energy) I would like to strongly encourage you inform you about these approaches or even better to try them. Ironically, the above quotation was in reply of a letter about UML and Model Driven Architecture. Six years after, there is not a lot of people still caring about this way of developing software, as it is for Smalltalk or assembly languages.

Resources

* Wikipedia.

Functional Programming

Domain Driven Design

Convention over configuration

* Articles

Functional programming – HaskellWiki

Functional Programming For The Rest of Us

Ruby on Rails guides

An Introduction to Web Development Using the Ruby on Rails Framework

An Introduction To Domain-Driven Design

An Introduction to Domain Driven Design


The Three Rules of Test Driven Development

March 6, 2008

Over the years I have come to describe Test Driven Development in terms of three simple rules. They are:
1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.You must begin by writing a unit test for the functionality that you intend to write. But by rule 2, you can’t write very much of that unit test. As soon as the unit test code fails to compile, or fails an assertion, you must stop and write production code. But by rule 3 you can only write the production code that makes the test compile or pass, and no more.

If you think about this you will realize that you simply cannot write very much code at all without compiling and executing something. Indeed, this is really the point. In everything we do, whether writing tests, writing production code, or refactoring, we keep the system executing at all times. The time between running tests is on the order of seconds, or minutes. Even 10 minutes is too long.

Robert Martin

http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

Besides these rules and independently of an agile approach, I always like as a developer being able to verify quickly my code, because it makes much more easier to find all the errors I do ;o)


Sharing Trough Implementation Patterns

January 31, 2008

The thing I like about the pattern form is that it gives you a way to talk about the motivation for what you are doing. So there is a lot of Java style books, and good ones, out there people with lots of experience, people who’ve thought carefully about how to program, but when I read them what I hear is a set of commandments, “Name variables like this, arrange your code like that, etc” and all those are good things to do in certain circumstances, but what doesn’t ever come true for me is why? What’s the context, what stage needs to be set before that’s the right thing to do, and what are the consequences? If I do that what other thing should I do so that the whole system works well together? So there are different personal styles.

People come to those styles because there are a bunch of decisions that work well together. Taking one bit of that out and using it isn’t necessarily working well. So by writing a pattern kind of format I get a chance to say: “How do you name fields?” Well, let’s see. What are all the things that you might want to communicate? What things might a reader be interested in if they are reading a name of a variable? What are all the constraints on naming, both in terms of like cognitive constraints. Abbreviations don’t work well for a variety of reasons, but why? Really long names don’t work well, but why? By writing in terms of patterns I get an opportunity to think about all of those. Here is my rule for naming variables, to use simple names that describe the role of the variable in the computation, but if I just said that as a commandment, someone could copy that, but they don’t really get it in the same sense that I care about, and more importantly when that is not the right rule, they don’t get any sense of what thinking was behind that rule, so they don’t know when to break it.

Source: “Kent Beck on Implementation Patterns” on infoq.com

The main point in Kent Beck’s words is that you cannot use software development methods and tools without knowing the context in which you should use them. Every time you find something interesting and new, you should ask yourself why and when you could use it, and why and when you should not use it.


%d bloggers like this: