Tip: Link to Unimplemented
Throughout our design and development process, we’re working around areas of the site that are not yet implemented but we also want to be able to allow our clients to demo their application. In an effort to manage their expectations, we need to be careful about what we link to. If a page/widget isn’t ready to be demo’d yet, we should avoid providing pathways to get interact with or navigate there. However, when we’re implementing HTML/CSS for pages, it’s sometimes makes sense to not hide certain things on the screen.
For example, let’s suppose that you’re working on the primary navigation of an application. You know what the other sections are going to be, but you’ve only implemented a few of them so far. Your HTML/CSS person is working on the design for the navigation and wants to have them be proper links… even to pages that don’t yet exist.
One option, which is quite common, is to provide a link with href="#". This works to some extent, but when people click on things, they naturally expect something to happen in response.
This approach doesn’t mesh well with our team as we don’t really want to field any questions like, “the navigation links are all broken. Nothing happens!”
So, a pattern that we’ve been using for a while is to trigger a javascript alert for every link within an implemented area that is linking to something that isn’t yet implemented.
Let’s take a really basic javascript function like:
# public/javascripts/application.js
function unimplemented() {
alert("NOTICE\n\nThis feature is not implemented yet. Please check back again soon!");
}
This allows us to do the following:
<a href="javascript:unimplemented();">link text</a>
When someone clicks the link, they’ll see a typical javascript alert message. This informs our clients/beta testers that we’re paying attention to what works and what doesn’t.
Let’s take it a step further and push this into a view helper.
# app/helpers/application_helper.rb
def link_to_unimplemented( link_text, *args )
link_to_function( link_text, 'unimplemented()', *args)
end
Now, we’re able to use link_to_unimplemented and pass any arguments that you’d pass to the default link_to view helper.
<%= link_to_unimplemented( 'link text', { :class => 'link_class_name' } ) -%>
Now our web designers can go about their work and use this helper as necessary.
An nice benefit for doing this is that we have a pattern that we follow so that we can rely upon to make sure that we don’t forget anything. This is the equivalent of adding @TODO@s throughout our code base.
If we search through app/views for ‘link_to_unimplemented’ we should be able to prevent missing any broken links. In the next screenshot, I’m using grep with colorized matches.
As you can see, we have something left to implement in that area of the application. :-)
This has been one of those lightweight patterns that we’ve been able to adopt and it’s definitely helped manage the expectations of our clients throughout our development process.
I’d love to hear your thoughts on this. How does your team handle things like this?
Related Posts
Embracing Chaos, part 1
Consider this part one of several posts on my thoughts of the art of embracing chaos.
Don’t let the books fool you. The construction of custom software is an unmastered and volatile cesspool of chaos. I don’t adhere to the belief that there is a perfect methodology or process that will work for every project… as I’m sure many of you don’t.
Unlike bowling, you’ll never achieve a perfect score. Even in bowling, It’s unlikely that anybody will learn how to bowl a perfect score and do so on every game for the rest of their career.
You’ll never meet every expectation that a client has on every project.
You’ll never meet every expectation that a user has when they interact with your application.
Expectations are an interesting thing.
Your project might get widely adopted and embraced, but you’re still trying to control chaos.
It’s chaos. Pure chaos1.
So, why do we bother? Why do we try so hard when the odds aren’t in our favor?
To be continued…
Related Posts:
1 Chaos Theory, Wikipedia
Rails Business: "Weekly" Review #3
It’s been about six weeks since the last Rails Business “Weekly” Review on here, so perhaps it’s worth changing the name to cut me some slack on not being consistent. ;-)
Since the last post, we’ve gone from around 400 members to 555 as of this morning. We’ve had 562 messages as well, so there hasn’t been a shortage of discussions taking place. I’d like to take a few moments to highlight some of the discussions that have taken place and encourage you all to consider participating, if you’re not already.
Licensing and Client Agreements
Tim Case writes,
“My client sent me this agreement drawn up from their lawyer that included the following:
(c) the Contractor shall not bundle with or incorporate into any Work Product any third-party products, ideas, processes, software, codes, data, techniques, names, images, or other items or properties without the express, written prior approval of the Company;”
Tim then goes on to ask how his applies to using Ruby on Rails, which as a MIT license and how other consultancies are handling these types of situations. Follow the discussion…
Escrow
Gustin writes, “Does anyone have any escrow experience, legal and cost? I am dealing with a client that got burned bad and we are reducing their fear with escrow on the first two iterations.”
Project Planning tools
Mike Pence writes, “So, I used to use MS Project for the composition of those dreaded Gantt charts, but it has been a few years since I had to be so formal. Anything new and exciting – and more robust than Basecamp – happening in the world of project planning software?”
Not long after, Jim Mulholland started a new thread on the same topic and brought up the open source application, redMine. Follow this discussion…
Ruby on Rails versus .NET
Michael Breen asked a big question on the list, which has sparked an going discussion about the benefits of using Rails versus .NET (and other platforms).
“A couple of months ago I decided to stop actively pursuing .NET gigs to focus on Rails. Several of my existing .NET clients have learned of this through the grapevine and have contacted me to discuss.”
Three things Tim’s learned from Freelancing Rails
Tim Case shared his experience of freelancing with Ruby on Rails and highlights three things that he’s learned.
- The non-code business aspect of Freelancing is demanding.
- It takes 10 hours to bill 6 to 8.
- Figuring out your rate is hard.
Read the rest of Tim’s observations and the discussion the followed.
Client issue tracking and documentation
Jeff Judge writes, “Hello all! I was curious to here how people are handling client issue tracking and documentation.”
Several applications were mentioned for handling issue tracking and the general consensus was that there was still a lot to be desired that current options didn’t provide. Be sure to follow the discussions…
Join the Community
These were just a small handfull of the discussions that have taken place over the past several weeks. If you’re an aspiring Rails freelancer or business owner, be sure to join the community and share your experiences and learn from other members of the community that are willing to share theirs.
Until next time, have fun!
Rails Business: Weekly Review #2
First of all, I’d like to welcome the more than fifty people that have joined the Rails Business group since my last post. Over the past week, there were less posts, but we did cover a few important topics, which may be of interest to you.
Subcontracting
Michael Breen asked a few questions about subcontracting for larger firms and how people set their rates when doing this. Several of the responses provided some personal experiences (good and bad) of being a subcontractor on large projects. Where some risks are and how to negotiate your rates, when applicable.
Change Requests
Nick Coyne started a discussion on how to manage change requests in an Agile development process.
Dealing with large clients
There was also a discussion about how to go about responding to a 150 page RFP for a large client. A few of us offered our experiences of bidding on large projects. Read more
Join the Community
The list is about to pass 400 members and it’s already proving to be a valuable resource for all of you entrepreneurs out there. I encourage you all to introduce yourself.
- For more info: http://groups.google.com/group/rails-business
Rails Business: Weekly Review #1
This past week (give or take a few days), the Rails Business group has covered a lot of topics, that might be of interest to you, should you be running a business and using Ruby on Rails. Many of the members of the new group are independent contractors and have been very open in sharing their experiences of working for themselves. I’d like to take a moment to highlight a few conversations and tips that were covered this past week.
Health Coverage
Mike Pence started a conversation about health coverage…
“Has anyone else found the medical insurance issue to be a show stopper for them? Are you one doctor visit and diagnosis away from financial ruin? I can tell you firsthand that wishful thinking won’t pay those bills…”
This started a discussion about how people are able to work on their own and maintain health coverage, which is definitely not something that should be considered lightly. Read more…
Client Expenses
Another great question was raised by Mike Breen.
“I’m going to start work on my first project that will require me to travel. How should I handle the expenses? Do I build the costs into the contract price or do I submit the expenses to the client for reimbursements? Or does this vary from client to client based on the company policy?”
The responses included links to IRS sites and sections of other peoples’ contracts. Read more...
Hosting Client Repositories
Where do you host your client’s source code repositories? Are you managing it all yourself on your own servers or using a service?
The discussion (so far) has lead us to evaluate our own solution for this at PLANET ARGON. It appears that everyone has different concerns about how they want to manage client code during the development cycle.
For example, do you allow your client access to trunk/ if they aren’t all paid up yet?
Also, it seems like there are a bunch of new commercial options coming out (and are built on Rails). Read more...
Naming Your Business
Jared Haworth writes,
“For those of you who are working as ‘independent developers,’ have you found that it makes more sense to simply do business under your own name, for example “Jared Haworth L.L.C.,” or to come up with a clever business name instead, such as “Code Fusion Studios”?”
This was a good conversation to follow and definitely raised a lot of great questions and things to consider in response to the original message. Read more...
Other Topics
- Magazines, what business magazines do you read?
- Where do you find gigs?
Join the Community!
The community is still only a few weeks old and we’re already approach 350 members! It’s been a great learning about other peoples’ experiences… as well as sharing what I’ve learned since I started PLANET ARGON (and how the name came to be).
If you hadn’t had a chance to join, stop by and introduce yourself!
Embracing Failure, part 1
I’m currently reading To Engineer is Human, by Henry Petroski and found the following applicable to software development and managing client and customer expectations.
“As much as it is human to make mistakes, it is also human to want to avoid them. Murphy’s Law, holding that anything that can go wrong will, is not a law of nature but a joke. All the light bulbs that last until we tire of the lamp, all the shoelaces that outlast their shoes, all the automobiles that give trouble-free service until they are traded in have the last laugh on Murphy. Just as he will not outlive his law, so nothing manufactured can be or is expected to last forever. Once we recognize this elementary fact, the possibility of a machine or a building being as near to perfect for its designed lifetime as its creators may strive to be for theirs is not only a realistic goal but also a reasonable expectation for consumers. It is only when we set ourselves such an unrealistic goal as buying a shoelace that will never break, inventing a perpetual motion machine, or building a vehicle that will never break down that we appear to be fools and not rational beings.”
I’m sure that most of us are guilty of having high expectations for products that we purchased. (why does my ipod screen scratch so easily when in my pocket?) We also set high expectations for the code that we develop, which is why we (hopefully) continue to refine our process. We’re bound to time and budget constraints, which often prevent us from testing every imaginable edge case. Given our constraints, problems are almost always going to arise. It’s no wonder that we see Test-Driven Development as an important part of a healthy development process. We want to catch our failures as early as possible.
Our clients often have high expectations and it’s almost always very reasonable. That’s not to say that some clients will not have highly irrational expectations. It’s our job to manage these expectations as best as possible.
Do we mislead our clients by convincing them that our TDD/BDD process is going to prevent any bugs from creeping from the woodwork after the development cycle is finished?
“I thought that we paid you to fully test the code?”
Really… is that even possible? Can we predict (and test) every possible interaction within an application? Highly unlikely.
What we can do is plan for and embrace failure. We can help our clients understand that almost every application needs to be maintained after it’s initial development cycle. Bugs are inevitable and there needs to be a clear process for handling them.
Perhaps I’m abusing the bug fixing process by calling it a failure… but I’ve also found that yes… many bugs are due to failure. Whether that be a failure to specify application behavior, a failure to understand the project goals, a failure in communication, ...or maybe a failure in our software architecture. We’re constantly failing.. and it’s okay!
IT’S OKAY TO FAIL! (some of the time…)
“No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art. Contrary to their popular characterization as intellectual conservatives, engineers are really among the avant-garde. They are constantly seeking to employ new concepts to reduce the weigh and thus the cost of their structures, and they are constantly striving to do more with less so the resulting structure represents an efficient use of materials. The engineer always believes he is trying something without error, but the truth of the matter is that each new structure can be a new trial. In the meantime the layman, whose spokesman is often a poet or writer, can be threatened by both the failures and the successes. Such is the nature not only of science and engineering, but of all human endeavors.”
As we’re creating these virtual structures… are we really taking the time to reflect on our failures? This is why some teams adopt practices like iteration retrospectives and post-mortems.
I’ll end this with a few questions, which I hope that you’ll share your experiences about…
- In what ways is your team embracing the failures of your development projects?
- How do you help manage your clients expectations… so that they too can plan for and embrace failure? Isn’t their new business venture on the web… likely to experience some failure?
We have so much to learn…
