Software teams are continually looking to adopt and mutate their processes to help counteract their immediate needs and weaknesses. And I think we can all agree that different software processes have their strengths and weaknesses.

Therefore, it is only logical to say that the this equation holds true:

Process Strengths + Current Team Weaknesses = Process Adoption and Success

Wrong.

The #1 failure of newly adopted software processes is effort.

I have watched numerous teams time and time again throw away software processes (that could have solved all of their problems) because they never gave any effort to truly adopting them.

You see your egg and expect it to crow – Chuang Tzu

Just because you “label” yourself as an Agile team – does it mean you are actually using Agile? Seriously…be brutally honest…does it?

It pisses me off to no end when a poorly executed project is blamed on the process. What a bunch of bullshit! It isn’t the poor process’s fault – it is the crap job of the people executing it.

I sincerely believe that regardless of the process – if you give real effort your project will be a success. After that, permanent adoption of new processes is if the new processes give you better success on a relative scale.

Without true effort, no process will work.
Without true effort, no project will be a success.
Without true effort, you are wasting your time.

Last week during my birthday giveaway, SlickEdit was kind enough to donate a copy of their product Slick Edit Tools for VS.NET. Of course, I was unable to keep my mitts off of it and I had to give it a test drive before I gave the license away.

First off, I am going to tell on myself and admit that I have not yet dug my heels into ReSharper, SlickEdit, CodeRush, or any others that I maybe missing. I do know a lot about ReShaper’s functionality due to using IntelliJ in my short Java career, and as a result I figured SlickEdit was going to be “another refactoring add-in”.

Instead, it turned out to occupy a completely different space of functionality. I don’t quite know how to explain the space of features that they occupy other than – it does everything else that ReSharper and VS.NET doesn’t.

To further attempt to explain it’s features apples to apples, it is a lot like VisualSVN, WinDiff, NDoc Viewer, Ants Profiler, and ReSharper’s feature to quickly open files with acronyms – all mashed into one VS.NET add-in. In short, there is a lot of lighter weight functionality going on here.

SlickEdit Tools is actually broken up into 2 smaller products: Editing and Versioning Toolbox

The Editing Toolbox provides the features that enhance the editing experience. Just to name a few examples:

• Open files and folders quickly using acronyms
• Preview what /// comments look like in NDoc and auto-wrap source comments that get to wordy
• Document your code without modifying source – “annotations”

Of these features, the one that intrigued me the most was the annotations. I guess I have never given thought to storing source code comments in a separate file, and to be honest, it isn’t a practice I would take. Either way, I give credit for the original thought. Some might find that feature handy in situations that I have not come across.

The Versioning Toolbox provides features that let you easily understand and navigate the history of your source code. This is like the VisualSVN + Tortoise SVN combo only they have some really interesting (and again original) features and visualizations.

So what is the end verdict?

Even though SlickEdit Editing Toolbox occupies a much different space than ReSharper, I really felt that the features that existed were like a Lexus – solid but still in the unnecessary luxury class. I just felt that there should have been more to it in terms of features and the profiling was the only feature well worth the cost.

On the other hand, SlickEdit Versioning Toolbox will definitely be getting a second look. With both VisualSVN and SlickEdit Versioning Toolbox having a price point of $49, SlickEdit seems to definitely come up on top in terms of features. VisualSVN has its’ one or two strengths as well, so if you are looking for a paid alternative to ANKH, I would highly recommend test driving SlickEdit Versioning Toolbox.

SlickEdit Editing Toolbox

SlickEdit Versioning Toolbox

Notice: All reviews on codesqueeze are not paid nor are traded for services. These reviews are shared so you may save time in your quest for better tools.

There are many big reasons why you want stakeholders involved in a project including: input, feedback, direction, and buy off. However, all projects have a single thing in common – budget.

When project owners get left in the dark (or sometimes keep a blind eye on purpose) they run the serious risk falling trap to the Credit Card Phenomenon.

The Credit Card Phenomenon occurs when people become disassociated with their money due to using credit cards. They no longer rely on the physical signs that they are spending money – explicit counting of money, physically handling money, and the resulting lighter back pockets. In essence, they are keeping a blind eye on their pocket books.

Project owners that are not involved in the software projects that they are funding run this exact same risk. I have seen on numerous occasions clients enjoy that “spending high” as their projects burn through their budgets with little or no direction.

Of course, this story has a sad ending. In the end, the client is unsatisfied because they had no clue that they were burning budget at such a high burn rate, and they do not have the resulting product that they needed as an outcome.

At least, once a week involve your client in a team meeting and explicitly show them how much they have using a budget burn down chart. It is absolutely necessary that software teams identify these situations as your reputation as a team and company depend on it.