Monday, December 22, 2008

Glimmer Short Talk Description Change for EclipseCon 2009

I reported a few days ago that I will be presenting Glimmer at EclipseCon 2009:
http://andymaleh.blogspot.com/2008/12/eclipsecon-2009-here-i-come.html

I just wanted to mention that I updated the description to provide more value to attendees in the 10-minute talk that I will be giving in 2009. Last year, I provided a quick introduction to what Glimmer is about. This year, I will expand by demonstrating the latest features added to Glimmer.

Here is the part I specifically changed in the talk's description:
In this presentation, I will introduce Glimmer, demo the latest features by contrasting the code of an application written in both Glimmer and classic SWT, and finally provide a quick update on the status of the project.
Looking forward to seeing everyone at the conference.

Sunday, December 21, 2008

Black Box vs Invisible Box of Professional Practices

When a non-technical client requests software development services from a consulting shop, and they agree about the development of a certain application (the what,) is it a good idea to discuss the practices that will be followed in order to get the job done (the how,) or would mentioning the practices be irrelevant to a client who is not technical and has no expertise with software development?

For example, a certain consulting shop may choose to build the client's application following XP practices because from experience, developers at that shop have found that they finish developing features faster and with higher quality when following the XP process.

Is it relevant at all to mention these practices to a client who knows nothing about XP without being asked first? Or is it initially better to provide the client with the minimum amount of information needed, such as the number of developers, hourly-rate, estimated development time, etc...?

If the client was curious to know how the application is being developed, the details can always be provided when asked, but the reason I am asking the questions above is because often, mentioning these details too early can muddy the water and give the client authority over practices they do not have the qualifications to decide on.

For example, mentioning radical practices such as test-driven development and pair-programming sometimes stirs up discomfort and confusion about how these practices work due to lack of experience with them (like the classical misconception that the two practices aforementioned reduce productivity instead of increasing it.) The client then may demand removal/adjustment of the practices when in fact, the main reason the practices are followed is to serve the client in the most professional and productive way possible. That leads to the often frowned upon micro-management of practices, thus hindering creativity and productivity.

Without micro-management on the other hand, when the client is told he is sold the work hours of four developers with a certain estimate for application release, the developers can choose any way they desire to accomplish the client's goals. If they decide that it's more productive to pair on certain tasks and always write tests first, that is their decision. Trusting them with that freedom can often result in higher creativity and productivity in the long run, freeing the client from focusing on practices (the how) in order to focus on coming up with the best product to build (the what.)

After all, when I request from a company to build me a house, I do not want to be bored with all the technical details about how it is going to be built. I just want a quality home built by a certain date. If I get interested enough to know about the practices followed, I will ask, but I do not want to waste my time hearing about them before the beginning of the project if they do not affect my involvement with it.

In either case, clients still need to hear about the practices that directly affect their involvement with the development of the product. For example, stand-up meetings and iterative planning are two XP practices that need to be agreed on with the client before beginning the project in order to get the client's commitment and effectively apply them.

How would you answer the questions asked above? Are you in favor of having a black box or an invisible box around the professional practices that do not directly affect the client? Keep in mind that in either case, the box is transparent. It's just that with the black box, the client has to look closely to see them (like looking at tinted glass) whereas with the invisible box, all the details are being shown even before asking for them.

Saturday, December 20, 2008

The Attitudes for Excelling in a Team

Programmers working on a team often fall into the trap of comparing their skills to their coworkers and feeling negative about it. They often forget that people have different strengths and weaknesses, and having different perspectives and styles of work actually improves synergy and output rather than hinder it.

What are some attitudes that can help a team be more effective though?

Here is a list I just brainstormed quickly:
  • Motivation, enthusiasm, and excitement
  • Positive attitude and optimism
  • Respect and patience
  • Humbleness
  • Belief in the value of others
  • Love for learning
Could you think of other attitudes or traits that would help a team be more effective?

Friday, December 19, 2008

Contributing Value as a Junior Developer

When I was still a junior software developer in the enterprise, I often felt like my opinion did not count. I had the typical shyness many junior developers have at their first job out of college. Whenever I was in the presence of senior developers, I worried about whether what I said would sound dumb and attempted as much as possible to be right to avoid embarrassing myself.

What was the net result of that?

I shared my opinion less and less, holding back on any ideas I had, and feeling frustrated with myself being junior. I had the illusion that if I gain enough experience and knowledge, I would finally speak intelligently and assert myself.

Also, whenever I was sure of something I said to someone more senior, and he was not convinced of it, I would get really angry.

That attitude finally changed after I learned two things:
  1. Even the most senior and experienced of developers are sometimes wrong and they often humbly admit it because to them, finding the truth and serving the customer is much more important than others' perception of them.
  2. When working with other people, our brains are not directly connected to theirs, so communication is not instantanious or perfect, often requiring a lot of patience and many attempts from both the speaker and listener before the message is communicated successfully.

Once my attitude changed, my behavior changed too as a consequence.

For example, now whenever I have an idea I would like to share, I speak up about it despite knowing that the team may resist it or the idea may simply be bad. Why? Because that's why we work as a team; to get different ideas, different perspectives, and different thoughts. Every opinion matters whether it's from a senior developer or a junior developer. Having a different mind thinking about the problem is very valuable. And, if the idea is not good for some reason, so what? I learn something new and I feel good about stimulating others' thoughts with my suggestion, possibly helping them come up with a different more effective idea.

Also, whenever someone would not see my point of view or not be convinced of something I said, I would take a deep breath and try to communicate it a different way by drawing on the whiteboard, telling a story or scenario, giving a concrete example, or asking the person questions that point him to the message I was trying to communicate. At least, when communication fails, I don't take it personally and appreciate the fact that other people have different points of view and paradigms of thinking, which could make it challenging to communicate a point sometimes. But, if the point does get communicated, the synergistic value of co-operation is priceless!

Thursday, December 18, 2008

Ridiculous or Outside the Box?

Ever heard someone call your idea about something ridiculous?

Well, that may be a good sign about the idea.

Usually, when people call something ridiculous it is not because they objectively thought about it and found it ridiculous. It is because it triggered a feeling in their body that it's ridiculous. If they had thought about it objectively, they would have pointed out why they don't believe the idea is good and/or listened to you actively to figure out why you believe the idea is useful.

But, when someone utters a statement like that, it means the idea completely shattered their first level of habituated thinking and triggered a feeling of discomfort in their body. It means the idea pierced through their current paradigms of thinking. It means the idea is fresh and has potential.

So, the next time you hear the word ridiculous about an idea you mentioned, don't immediately flinch and take that personally. Instead, re-evaluate the idea objectively to verify that it is sound, and calmly present the pros and cons of implementing it versus the status quo or other ideas presented.

After all, is the idea presented really ridiculous or is it simply outside the box?

Wednesday, December 17, 2008

EclipseCon 2009 Here I Come

I'm speaking at EclipseCon 2009

My Glimmer talk proposed for EclipseCon 2009 has been accepted:
https://www.eclipsecon.org/submissions/2009/view_talk.php?id=367

Looking forward to being at Santa Clara, California during Mar 23-26 2009.

Pair Programming Tour

Corey Haines is a journeyman craftsman who's actually on a pair-programming tour.

He visited us at the Obtiva studio in Chicago on Dec 5 and pair-programmed with my colleagues Joseph Leddy and Turner King:


Here is a video of an interview he also conducted with our Chief Craftsman Dave Hoover:


His tour blog is interesting in general as it includes interviews with a number of software craftsmen such as Uncle Bob, Brian Marick, David Chelimsky, and Micah Martin. Check it out here:
http://programmingtour.blogspot.com

Monday, December 15, 2008

Dynamic Languages Replacing Static Ones?

A number of years ago, Uncle Bob (Robert C. Martin) wondered if dynamic languages would replace static languages for mainstream software development.

Here is a summary of an article he wrote in 2003 titled "Are Dynamic Languages Going to Replace Static Languages?":

For many years we've been using statically typed languages for the safety they offer. But now, as we all gradually adopt Test Driven Development, are we going to find that safety redundant? Will we therefore decide that the flexibility of dynamically typed languages is desirable?

The static languages being referred to by the article are typical mainstream static languages such as Java and C++ by the way, not languages like Haskell or Objective Caml.

When writing all code test-first with 100% test coverage for the implementation, one seriously begins to wonder if the static typing is helping or in fact hindering design flexibility in comparison to dynamic typing.

Here is a metaphor that may help us understand this better.

Static typing is like choreographing circus stunts with safety built into the moves. The circus people can only practice moves that are safe and would not result in them crashing down in front of the audience. While such moves will still look good due to the great practice put into them, they are generally conservative due to safety consciousness.

On the other hand, dynamic typing is like choreographing wild circus stunts, attempting such wild moves that if successful completely wow the audience.

Traditionally, performers would get into horrible accidents while practicing such wild moves, which is the reason why static typing became the norm in software development for a while. It was after all, the only way to achieve reliable business software delivery.

However, when the concept of a circus safety harness was introduced, performs were able to practice the wildest move and still be safe from injury. This is similar to having a unit-test suite acting as a safety harness for all the dynamically typed code you write. It lets you go wild with your software design, achieving unmatched productivity and flexibility with your code while remaining safely covered with your tests.

So, did test-driven development change the playing ground enough to enable developers to leverage dynamic languages in favor of static ones without the traditional fears that encouraged static typing in the first place?

First Code Example of Glimmer RSpec/SWTBot Testing

So, I mentioned in this >>blog post<< that Glimmer's now got Behavior-Driven Development support through RSpec and SWTBot.

In this post, I'll go over some of the technical aspects of how that works.

RSpec Cucumber is an engine that lets you map English statements (or any language actually) to executable code in order to validate software specifications written as scenarios with the code written to fulfill them. This is pretty much what Acceptance Tests in the XP process are.

Here is an RSpec Cucumber login.feature file that I wrote to test a Login (Glimmer) sample application:


Feature: Login feature
In order to keep user data secure
As a user
I would like to be authenticated before I can access my data

Scenario: Login
Given I fill in "User" for "Username"
And I fill in "Pass" for "Password"
When I "Login"
Then my status should be "Logged In"

Scenario: Logout
GivenScenario Login
When I "Logout"
Then my status should be "Logged Out"


The top 3 lines after the feature heading describe the user story being developed in the stakeholder language. Those lines are not executable.

The scenarios that follow however, which demonstrate the feature functionality, are written in the Given/When/Then format and executed to validate that the implementation satisfies the specification.

In order to execute these scenarios, you need to have code that can execute each step (statement on a line) in every scenario. Such code is arranged in *_steps.rb files. Here is how such code is written:


When /I fill in "(.*)" for "(.*)"/ do |text, label|
  @bot.text_with_label(label).text = text
end

When /I "(.*)"/ do |button|
  @bot.button(button).click
end

Then /my status should be "(.*)"/ do |text|
  @bot.label(text).should_not be_nil
end


The @bot object is actually an instance of the SWTBot class. This is an SWT driver that enables you to poke at an SWT desktop application by simulating a user filling in fields and initiating events like clicking a button.

Let's go through the steps one by one.

The following statement grabs a text box with the specified label, and sets its text property to whatever the text mentioned in the step is:


When /I fill in "(.*)" for "(.*)"/ do |text, label|
  @bot.text_with_label(label).text = text
end


This following statement on the other hand grabs a button based on the text that is displayed on it, and simulates a user click on it:


When /I "(.*)"/ do |button|
  @bot.button(button).click
end


Finally, this following statement looks for a label with the specified text and says that it should not be nil (null.) The should_not method is a method from RSpec that lets you write assertions using English-like statements as opposed to using the assert_equals method with two parameters:


Then /my status should be "(.*)"/ do |text|
  @bot.label(text).should_not be_nil
end


My code samples are still experimental and not ready to share yet. Once I have them in a good-enough state, I will commit them to the repository and blog about them in order to give people the opportunity to play with them.

Saturday, December 13, 2008

Friend of Eclipse 2009

Just wanted to share that I renewed my friendship with Eclipse.



If you want to become a friend too or just renew your friendship, click on the image above for more details.

I do it because I am very appreciative of all the work that went into Eclipse, RCP, SWT, and the ecosystem in general.

Friday, December 12, 2008

Writing More Code Is Easier!?!

The statement in the title may sound like an oxymoron, but some developers I met seem to believe it.

A developer came to me one time asking me for help with a problem he struggled with for hours. The first question I asked, as I usually do: "Are the tests passing?" His response was that he was under a lot of pressure, and he had to deliver a feature very quickly for the manager. In other words, no tests were written, and the developer was planning to write them after he had verified through the web browser user-interface that the feature is fully functional.

I took a look at the code and saw that it consisted of more than 50 lines of heavy logic packed into one gigantic method. It was difficult to read and decipher, but after I got a grasp on what the developer was attempting to do, I realized that most of the logic could have been done with one line of code using one of the 3rd party libraries used heavily on the project.

I asked the developer if he thought of checking whether that feature was in the library first before writing it from scratch, and he said he was so much in a hurry, he did not want to spend the time on that kind of research.

Well, I ended up writing a test as if the method never existed (keeping with the test first philosophy,) commented the method code out, ran the test and got it failing, added a few lines of code to pass the test, wrote another test, wrote some more code including the one line needed from the 3rd party library, and voila. A method with no more than 7 lines of code was working perfectly according to the tests that specified the behavior.

So, while it may seem like writing more code is easier than doing the hard work of DRYing it up, applying design patterns, and reusing libraries that can help, more code means more code to maintain and more potential bugs to deal with. In other words, more work in the future that becomes a lot harder to deal with than writing less code that is simpler and more reliable.

Thursday, December 11, 2008

Glimmer's Got BDD through RSpec and SWTBot

I got an RSpec Story Runner (Cucumber) test passing with Glimmer code that tests whether a user logs in successfully.

RSpec is a Ruby library that encourages BDD (Behavior Driven Development,) enabling you to drive the functionality of your application from the outside in by specifying the external behavior from the user's point of view and in the user's language.

Here is the test I got passing with Glimmer:


Feature: Login feature
In order to keep user data secure
As a user
I would like to be authenticated before I can access my data

Scenario: Login
Given I fill in "User" for "Username"
And I fill in "Pass" for "Password"
When I "Login"
Then my status should become "Logged In"


It uses SWTBot behind the scenes to execute the scenario steps, such as filling in text fields and pressing the login button.

Here is the user-interface:



Here is the user-interface Glimmer code relying on data-binding:


@shell = shell {
text "Login"
composite {
layout GridLayout.new(2, false) #two columns with differing widths

label { text "Username:" } # goes in column 1
text { # goes in column 2
text bind(presenter, :user_name)
enabled bind(presenter, :logged_out)
}

label { text "Password:" }
text(SWT::PASSWORD | SWT::BORDER) {
text bind(presenter, :password)
enabled bind(presenter, :logged_out)
}

label { text "Status:" }
label { text bind(presenter, :status) }

button {
text "Login"
enabled bind(presenter, :logged_out)
on_widget_selected { presenter.login }
}

button {
text "Logout"
enabled bind(presenter, :logged_in)
on_widget_selected { presenter.logout }
}
}
}
@shell.open


In a future post, I will discuss the technical details of how this works.

Wednesday, December 10, 2008

OO Language Use to Write Stored Procedures

Co-workers at Obtiva meet up every Tuesday for a weekly event called "GeekFest." Lunch is ordered for us for free and we use that time to enjoy discussing the latest technologies, giving presentations, demoing programs, and having heated debates about things like mock-based testing vs state-based testing and Ruby vs Python.

So anyways, I always like to think outside the box and ask some crazy questions, and yesterday I committed a crime by asking the following question after I saw a demo of a trigger and a stored procedure written to solve a specific problem that would have been harder to solve with writing application code (rare case): "Now that Oracle allows writing stored procedures in Java and MS SQL Server allows writing stored procedures in C#, isn't that the holy grail for developers that complain about how procedural and non-OO stored procedures are and how they produce difficult to maintain code? The Oracle Java version may be behind its time, but it's light years ahead as a language than that of stored procedures, isn't it?"

I got a backlash almost by everyone, even from the most OO-centric developers. Apparently, I forgot about one very important detail that one of our new co-workers reminded me of. Stored procedure code meshes well with SQL, which is a DSL that makes writing query code much easier than in Java. This ends up with simpler code that is easier to read than embedding SQL queries within another language with a different paradigm, such as Java.

Now, if we take that to the extreme, we would write all the application's query logic in stored procedures. So obviously, there is a point of diminishing returns. Stored procedures may be simple to write for small cases, but when used to write a whole application, they end up with the same issues that prompted the invention of OO methodologies, like lack of expressiveness for domain models due to no support for inheritance and polymorphism, and difficult maintenance as a developer is required to dig many levels into a procedure's code before understanding what it does due to no support for abstraction (assuming the code is well factored in many tiny procedures calling each other.) When a procedure is a method on an object, there is a lot more context to what it does, which saves developers from having to dig to understand what it does.

So, while the stored procedure language is easier than Java for writing code intermingled with SQL for simple cases, that does not necessarily mean it scales well for big projects with complex domains.

One last point that one of my co-workers mentioned that made a lot of sense is that you don't need an Object-Oriented language to write clean code. My response to that though is while that's absolutely true, you may still need an Object-Oriented language to write clean code that is easy to maintain when dealing with a complex domain. Just because the code is clean, it does not mean it's easy to maintain if the language is not expressive enough (no polymorphism, no inheritance, etc...)

What do you think?

Tuesday, December 09, 2008

Software Craftsmanship vs Software Engineering

I often hear a reference of Software Craftsmanship mentioned in opposition to Software Engineering, and I wonder: Are they really in conflict with each other?

The word engineering often gives people the feeling that a bunch of engineers are working very hard on a drawing board to solve big problems and come up with complete execution plans before getting to the implementation phase. Craftsmanship on the other hand gives the image of an apprentice humbly climbing up the ladder of competency by learning the craft step-by-step with a journeyman or master who is quite comfortable with delivering value to the customer.

Now, these are the touchy feely aspects of those two terms, and I can appreciate people leaning towards craftsmanship and seeing it in opposition to engineering with that regards.

However, I believe there is real value in knowing what software engineering is truly about as opposed to simply a common feel about it.

Here is one of the original definitions of Software Engineering (Naur and Randell, 1969): Software engineering is the establishment of sound engineering principles in order to obtain economical software that is reliable and works efficiently on real machines.

At one point, Waterfall was the only process for accomplishing that goal. Later, iterative incremental processes such as Boehm's Spiral Model and the Rational Unified Process became other agents of accomplishing it. Finally, the agile movement with XP and Scrum provided the newest practices for accomplishing that goal.

Now, with that definition in mind, is Software Craftsmanship in conflict with Software Engineering at all? No. Does Software Craftsmanship help with accomplishing the goal cited in the definition of Software Engineering? Yes.

While Software Engineering is about the macro goal of delivering economical software that is reliable and efficient, Software Craftsmanship is about the micro process that can help with achieving that macro goal.

One thing that can actually be considered the opposite of Software Craftsmanship though is academia without practice. Software developers study for a degree in Computer Science, Computer Engineering, or Electrical Engineering, and then proceed to work after graduation with very little practical experience beyond relatively small school projects. Such developers might follow a lot of the theory they learned without personal validation or playing around outside the box of their education. Unfortunately, this might end up teaching them the hard and expensive way that they cannot take everything they learned for granted without also properly analyzing the situation they are trying to address. Eventually, they remember that theory is simply distillation of reality and may always go out of sync with it as new knowledge is added or become inappropriate for certain work projects or situations without some new practical learning to augment it.

On the other hand, practice without academia is equally problematic and is the anti-thesis to Software Engineering. Aspiring programmers who do not learn the ins and outs of Computer Science and Software Engineering while attempting to apply Software Craftsmanship alone will end up perpetually deficient in basic software engineering knowledge and skills, and will get permanently stuck below true software engineers. That is software engineers who were passionate enough about their field to go through a 4-year computing-related degree joyfully (e.g. Computer Science, Computer Engineering, Electrical Engineering, Information Systems, Software Engineering, Math, or other fields of Science and Engineering that require computer programming), thus know both theory and practice, and can produce superior software. That is because they know that all theory is simply distillation of reality, and can always translate into practice. Those who do not understand that very simple fact and might blame academic education for being too theoritcal sadly miss the point of education altogether, and can never truly thrive in their work as much as those who do understand both theory and practice.

So, Software Craftsmanship is about learning software engineering skills gradually and practically with the guidance of a skilled journeyman or master while working on real projects, but only after having mastered the theory. Theory provides an invaluable shortcut to learning the lessons of millions of software engineers around the world faster in a distilled fashion. Afterwards, practical work validates the theory or reveals gaps in it under certain settings that need practical exploration to implement the right solutions.

As such, going the academia route is not in conflict with Software Craftsmanship at all. In fact, academia provides students with a faster path to excellence. And, if they apply Software Craftsmanship practices too along the way, they end up validating their skills in the real world during their education (through internships and open-source projects) and/or shortly afterwards (e.g. through real work) with the guidance of other experts in the software community.

That was the route I went in fact, and I am greatly appreciative of my Bachelor in Computer Science education at McGill University and my Master of Software Engineering education at DePaul University in addition to the on-the-job guidance I received from Kevin Taylor and Dave Hoover who are strong craftsmanship practitioners at Obtiva.

So to recap, Software Engineering is not about over-engineering or heavy-weight processes like Waterfall; it is about delivering economical software that is reliable and efficient. Software Craftsmanship is therefore not in conflict with Software Engineering, yet in fact in harmony with it as it helps accomplish its goal through practical learning of software development with the guidance of experienced developers.

Monday, December 08, 2008

To Get or To Do

So, the standard for getting property values from a model in Java is to call a getXYZ() method, like getName(), getAge(), getPrice(), etc...

Sometimes though, a model may have a property calculated dynamically, such as total. Other times, a property is determined dynamically based on passed parameters, like sales for a particular customer.

In these cases, do you prefer the name of the method to be getTotal() and getSales(Customer customer) or would names that reflect the behavior be more preferable, like calculateTotal() and determineSalesFor(Customer customer)?

Sunday, December 07, 2008

NIH Syndrome or Blowing Reuse Out of Proportion?

I see a lot of developers nowadays favoring re-inventing the wheel over reusing an external library or component, especially in the Ruby and Javascript communities.

The first thing that pops in my mind when I see them doing that is NIH (Not Invented Here syndrome.)

From my experience, reuse is not just about getting the features I need. It is also about stability, performance, usability, and other non-functional requirements that have been ironed out by the people who have created the reusable component and the communities that consumed it. Unless it fails in most of these areas, I usually don't see the point of re-inventing the wheel. While it seems simple to do on the surface, it is those hidden edge cases and bugs that creep up now and then that get me when re-writing it. This happens in the code when I have not thought of every possible scenario and in the design when I have not exercised the component in a real-world setting.

What's the flip-side to this argument though?

A lot of people in the agile community place great importance on minimalism. An ideal minimalistic code base does no more than necessary by your application. So, if you end up reusing components that do a lot more than needed, the complexity of learning how to configure them for your needs ends up offsetting the productivity gains behind using the components. In that case, re-inventing a smaller simpler wheel becomes a viable option.

The key thing though is determining whether a required feature is complex enough that figuring out all its edge cases and usage scenarios would be worth the time to re-write from scratch vs simply reusing an existing component that gets the job done. That trade-off is the key determining factor.

Does the programming language used play any role in the matter? I'd say yes. For example, I rarely find this option of "re-inventing the wheel" viable in Java since writing components in it is very slow. On the other hand, dynamic languages like Ruby and Javascript make it so quick and easy to build a component from scratch (when writing tests first) that it often is easier to re-write smaller components than to figure out how to use 3rd party ones.

What is your opinion of the matter? Do you have examples where you reused a component vs other examples where you ended up writing your own?

Saturday, December 06, 2008

Glimmer on JRuby 1.1.5

Glimmer is now compatible with JRuby 1.1.5.

Thanks to dacm for taking the effort to report a Glimmer incompatibility bug on Eclipse BugZilla:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=257793

It is now fixed.

Thanks to Steve, Tom, and Starling too for reporting that bug along with the fix.

The changes were deployed to both SVN and GitHub repositories.

Friday, December 05, 2008

Glimmer Finally Available at GitHub

Yes! After so many requests, Glimmer's Eclipse SVN Repository is finally cloned at GitHub (thanks to Soleone's suggestion to use git-svn):
git://github.com/AndyObtiva/glimmer.git

Here is the main GitHub project page:
http://github.com/AndyObtiva/glimmer/tree/master

This will make it much easier for people to contribute to Glimmer. Instead of checking out the SVN repository and submitting patches back to me to merge. Developers can now fork Glimmer completely on GitHub, commit multiple changes, and then notify me to merge the forked version back into the origin/trunk.

Happy Glimmering!

Thursday, December 04, 2008

The Illusion of Delivery

Writing code without following certain professional practices often reminds me of a story I heard in Steven R Covey's book, The 7 Habits of Highly Effective People. The story was told to illustrate the difference between a leader and a manager. Here is roughly how it goes:

A group of people are cutting trees in the forest. One of them is a leader and another is a manager. The leader decides to climb a high tree at one point to see if they're making progress in the right direction. To his surprise, he finds out that they're actually cutting the wrong forest, so he yells at the top of his lungs "Wrong forest!!!" What does the manager say in response? "Shut up! We're making progress!"

This is pretty much what happens whenever a professional developer tries to remind a colleague of writing tests before writing code, pair-programming, or doing paper-prototyping on user-interfaces before implementing them.

When the colleague resists the suggestion, reasoning that it is more important to deliver than follow one of the suggested practices, would the resulting delivery be real progress? Or would it just be an illusion?

Let's look at test-driven development for an example. If a developer is delivering code without writing tests first, he may be delivering features "now," but if they have bugs that need to be fixed later with double the time at least that would have been spent writing the tests in the first place, was that real delivery or was it just an illusion?

What about skipping pair-programming and working solo? After having a few years of experience in pair-programming, I am completely aware now of how slower I am at delivering complex features whenever I work on them on my own. Often, such features are scrapped completely and redone after a review with someone. Was that real delivery or just an illusion?

How about delivering user-interfaces without doing any sort of conceptual design or paper-prototyping, let alone user testing? I've seen quite a number of user-interface screens developed and done only to be completely overhauled afterwards because they reflected the developer's mental model as opposed to the user's. Was that real delivery or just an illusion?

Writing tests first guides developers towards better code design, provides a safety harness that enables future refactoring of the code and maintenance by other developers without unexpected bugs popping up in other areas of the application, and keeps progress real and linear as opposed to illusory and unpredictable.

Pair-programming saves quite a bit of time by having developers sell each other on the benefits of certain designs before diving to implement them, results in transfer of knowledge between team members that makes them much stronger, and gets the benefit of unexpected synergistic solutions that often save hours of work. That's often much better delivery than having two programmers working independently all the time.

Finally, a little bit of time spent on designing user-interface paper-prototypes (10 minutes) and a bit more time spent testing the prototypes with real (or model) users (10 more minutes,) saves developers from so much time in rewriting bad user-interfaces or figuring out a reasonably usable user-interfaces for the actual users.

So, the next time you think about skipping one of the recommended professional practices, ask yourself: "Will I be delivering to the customer the most value in the long run if I skip this practice, or will I just be kidding myself into thinking that I'm delivering now when I'm hindering delivery in the long run and keeping myself in an illusion?"

One yardstick I use to evaluate whether my resistance to a suggested practice is legitimate or is just plain human resistance to change is to also ask myself "Am I only resisting it because I don't see how it can help the customer or is there a little bit of feeling of inconvenience to adopt it?" If there is even a nugget of feeling that I do not want to be inconvenienced by change, I give the practice another chance, keeping in mind that often it takes getting good at a certain practice before I can reap benefits from it.

Final Note: there are of course situations where some of the practices mentioned above may not be appropriate. For example, in a situation where a legacy app requires one extra feature and the team is not trained in TDD, it wouldn't make sense to apply it, but it does make sense to think about implementing that practice strategically in the future.

Wednesday, December 03, 2008

Tuesday, December 02, 2008

Video of Glimmer DSL Engine lightning talk @ RubyConf 2008

A number of people expressed interest in contributing to Glimmer, and they wanted to get an understanding of Glimmer's internal workings in order to get started.

I gave a lightning talk about Glimmer's DSL engine during RubyConf 2008, and fortunately the ConFreaks guys recorded a video of it, just as they recorded one of my >>main Glimmer talk<<.

Check it out over here:
http://rubyconf2008.confreaks.com/glimmers-dsl-engine.html

It is pretty short (10 minutes,) but provides a good primer for Glimmer's internal DSL engine.

Monday, December 01, 2008

Glimmer Easy Tab Item Syntax

Have you ever found using TabItems and TabFolders somewhat painful due to their inconsistencies with the rest of the SWT widgets? For example, TabItem is not just any kind of widget as it does not get added to the children of TabFolder, yet to a special list of tab items instead. Additionally, you cannot use TabItem as a parent for other widgets. Instead, you must instantiate a Composite and then pass it to the setControl method on TabItem. It is something that I forget to do whenever I haven't used the TabItem widget for a while.

Well, worry no more. Glimmer's got the solution.

Check out this syntax:


shell {
text "SWT"
tab_folder {
tab_item {
text "Tab 1"
label {
text "Hello World!"
}
}
tab_item {
text "Tab 2"
label {
text "Bonjour Univers!"
}
}
}
}


The new tab_item in Glimmer acts as a special widget that feels like a composite by allowing you to lay widgets inside it, but still behaves like a tab item by allowing you to set the tab title text. Give it a spin, and let me know what you think.

Here is the interface produced:

Tab 1


Tab 2


By the way, this feature was implemented in response to a suggestion by Tom Robinson. So, if there are any other features that you would like to see in Glimmer, please share in a comment, an email (andy obtiva [dot] com,) or a post on the Glimmer Eclipse newsgroup.