As this blog has evolved, and will inevitably continue to do so, I feel I can take some time out from technical posts to vent a little about the frustrations I’ve had in the past few weeks surrounding the Tools of the trade.
While I’m tempted to list in agonizing detail, each error and issue I’ve faced, for brevity’s sake I won’t. What I will do is say simply state the general area’s most damning to your happy use of any tools.
Documentation
Too much or too little are a bad thing. Wading through an avalanche of documentation, demo’s, sample projects, video’s can be daunting, tiresome and confusing but I’d rather have too much than too little. With too much, you can cherry-pick and track ( see resources ) with too little, you end up posting questions, reading vague forum/group/blog posts trying to figure out what’s going on. Don’t do this to yourself.
Lesson learned:
If all they have are a sparsely populated Wiki, avoid this tool!! All the blog posts in the world can’t make up for lack of documentation or a “How To’s”, “FAQ”, “Demo”, “Sample”
Popularity
You may be forced to follow a trend even though you feel there are issues with said trend. I hate herd mentality, I like to think I have a choice in what I do and how I do it. However I find that a lot of times, popularity of certain tools while tempting, shouldn’t overshadow your own good sense.
Lesson learned:
You can’t fool all the people, all the time.
Open Source
Oh, the gift and the curse that is Open Source. It might be free but, Caveat emptor!
Maturity, popularity and trends are factors when picking an OSS and few make it to the mature stage. Too new and there is no community, too mature and they’re behemoths with multiple off-spring contributions. Hidden complexities that can compound the original problem.
Other concerns to factor when assessing the degree of pain that you should anticipate with a particular OSS tool:
- Downloading the tool.
Almost always an unexpected excursion wading through versions and various download sources. Desperation and sore eyes might tempt you to click the first arrow you see and save whatever assembly you find, but take the time to read and be selective about the download options. Often times, the small print and versions really do matter. - Installation.
Some are well done, easy and straight forward (Gallio for instance) and others, well.. not so much. They may rely on other OSS tools and require you to do things manually, and before long you forget what you were installing in the first place. It’s not unheard of to be required to install/upgrade sometimes 2-3 other things, change system settings, uninstall versions.. it can definitely be a pain. - Too cool for School.
Be wary of the OSS tool that is very clique-oriented, it’s so new Google hasn’t heard of it talk-less of a production system. It’s too tied to a “principle” or some such and was built by the current Cool Guy, self-ordained Guru and/or demagogue-with-a-blog - who is above actually supporting his creation. Call me crazy but, you might want to reconsider this tool UNLESS it really delivers. - Configuration.
This can easily become a nightmarish hell of which there is no hope of deliverance. NEVER underestimate how much time/energy configuring a tool can devour. ALWAYS research the configuration and issues others have had, track these before you click the download button. If you need another tool to HELP you configure, find out how easy THAT is to configure and use. You can see how this could snowball. The tool might be great but if you can’t even get it to run, then I’m sorry, life is just too short.
That being said, don’t discount it without research. Sometimes there are good simple solid tools that can help you master the beast… - Ease of use, lifespan, support, community
You’ve downloaded, installed, configured and and still there’s more, the tool is a pain to use, doesn’t work properly and is hard to understand. You find yourself spending hours learning while deadlines come and go. We’ve all been there, every OSS tool or framework has it’s own idiosyncrasies . My biggest frustration is the learning curve for EACH tool, we use dozens of tools daily for various things, everything from SVN to VS plugins has their own approach, syntax, commands, whatever. Using them in unison can sometimes cause new unexpected problems.I am ESPECIALLY choosy when it comes to using OSS for this fact alone. Key things to ask yourself: How long has it been around, is it being updated, how big is the dev team, where is the main community, how quickly can I use it and never have to worry about it? There are so few tools that just install and work quietly. If the updates are too frequent, I suggest you pass. Don’t do nightly builds if your paycheck is on the line. If it’s stable, there is usually a decent amount of time between releases. People won’t complain if it’s a reliable, widely-adopted tool that just works. Don’t adopt anything that isn’t properly handled. I like to see some professionalism in the website, docs and, support. You usually know right away if the project is taken seriously or if it will be “Closed” in about 2 months. - Be ready to code.
Sometimes, you have to extend OSS, this is a given. I’ve been there and it’s not so bad. Extend it and blog about it or somehow share what you found and had to do to get it working in your situation. I have to say it is fulfilling IF you get it working the way you want.
Lesson learned: Go with the mature product. Not the fad. However, weigh the options and if it’s time to adopt a newer model do it. Just be wary.
Comparison
When people love tools it’s hard to get them to shut up about it. I’m sure you already know a few people like this. Well, the problem is how much of it is because they don’t really know anything other option? How objective are they really? It is hard to find an fair, un-biased comparison post about tools/frameworks without the Author blasting one or the other side. This makes it hard to see things clearly..
Lesson learned: Don’t read anyone’s blog like it’s a Bible. Keep an RSS and search through it. You will find people from both sides and be able to gauge things better.. shop around basically, don’t become a Stan.
Errors
Weird, unexpected, hard to understand, unhandled, cryptic/illegible errors. Hours can be spent debugging errors generated from the use of tools that a little better documentation would help avoid entirely. Everyone is guilty of this, from Microsoft on down. WTF do these errors mean!
Lesson learned:
No lesson learned here, just try to remember how you solved them and maybe blog about it for the next guy.
Google is good at searches, but there is a missing link when it comes to development related searches and people goggling Britney Spears.
Major failures are Time & Topics. Time, for instance people rarely specify enough information for google to do it’s job properly. i.e. version, dates on blogs, e.t.c. Google itself is a tool (lol, I didn’t mean that the way it sounded) and you have to learn how to use it properly and know when to abandon it for other means. If you leave the safety of your RSS/resources and venture into the wild unknown that is google.com to search for help, hours and focus are usually lost along the way.I still can’t blame Google though, if things were better documented I wouldn’t need to search. And searching/asking doesn’t mean you’ll get an answer.
Lesson learned:
Avoid Google. Use your resources instead.
Resources
Why is it so hard to develop without a vault of resources at your disposal? I just don’t think it’s possible in this day and age. Even with a photographic memory (which I don’t have anyway) it’s a pain to find, track and maintain resources needed to use tools.
Lesson learned:
Don’t program without resources. Keep them neat, easily accessible, up-to-date. Keep as many as you can assuming it’s in a searchable format. This includes RSS, Twitter, Delicious, eBooks, Whitepapers, Blog Post favorites, Blog printouts, templates, CodeGen, Snippets e.t.c.
Keep them in multiple places if need be. Online, portable drive, your phone, your blog.
Use tags, index and search by those tags.
If it’s a hardcopy, scan it and file it. Paper is so 2008!
Be The First To Comment
Related Post
Please Leave Your Comments Below