Womens Hair Re Growth Rogaine Side Effects To Vytorin Lotrel Metformin Accutane After Before Sucralfate Taken With Nexium Hgh Weightloss Shots Can Prilosec Cure Ulcers Diamond Brite Louis Mo Celebrex And Canada Tramadol Is Prescribed For Bactroban Lowest Price Effexor Diary Ring Purim Online Card Music Free Melatonin And Zoloft Interaction Cymbalta Suicide 2006 Avandia Purchase Singulair Phone Cymbalta And Abilify Lexapro Klonopin Alcohol And Paxil Cr Avandia New England Journal Irina Allegra Viagra Next Day Shipping Tricor Pacific Capital Calcaulating Motrin Dose Base On Weight My Dog Ate Allegra D Information On Vytorin Effectiveness Of Diflucan Ventolin Package Insert Craftsman Brite Driver Parts Canada Coreg 25mg Picture Of Generic Nexium Solar Brite Abana Marietta Prosthetic Heart Valves And Coumadin Levels Drug Interactions With Lexapro Ibuprofen Motrin Rainbow Brite Dance Song What Does Synthroid Look Like Lexapro Tardive Dyskinesia Can You Take Celexa While Pregnant Actos Manufacturer Prednisone Use Medication Self-management Coumadin Gneric Viagra Lasix And Heart Surgery Zestril Lichenplanus Cla Supplement Danger Hoodia Bipolar Hoodia Case Studies Flomax For Kidney Stones

One of the best coined terms in Software Development is the phrase: “There is no Silver Bullet” - meaning, there’s no magic way to slay the wherewolf, or doing software development in a perfect way. Yet, as I step out of the software development community and into the world of management consulting, I realize that the best developers out there, the ones committed to their field, eager to learn more and those who have an almost perfectionistic approach to their craft, holds on to this vision of finding the Silver Bullet - taking the role as the alchemist in search for gold.

I list a few dilemmas the silver-bullet-chasing software developer faces (and yes, I used to be one of them):

Creating Business Value vs “perfect code”: “Why do you code?” is a good question to ask a software developer. The honest answer would probably be because it’s fun, challenging and creative. Another, more formally correct answer would be because you want to create business value from IT. Consider that no business would care to pay a software developer who doesn’t provide business value tells us that the developer should be utterly focused on the value delivered from the programming. But value decrease with cost. Cost increase proposional with the time spent creating value. And here’s another thing: Innovative theory states that the effort to value ratio drops with time, improving and improving will at some point not generate enough value! Instead of chasing “perfect code” the developer should be more in sync with what business value is really being added?

Software product deprecation versus stable code: Software deprecation is a serious problem. It strikes when software evolves. As changes to the software is being made, complexity of the code and integrations increases. The time spent to add business value decreases to the time spent just making the product compile, run and work properly. The answer, of course, is stable code. Preferably modular where you can add business value as “components” like plug and play. However, there’s another very important aspect to consider: most software products are not created to last a life time. 5 years is often significant. Who can tell what kind of technology or what the IT landscape looks like five years from now? Even more, what business challenges will a company face in 5 years time? Any company thinking about investing in a new software product or web solution should consider the lifetime of their project, and think of this lifetime as “controlled software deprecation”. If so, it becomes completely waste (or YAGNI - You Aren’t Gonna Need It) to chase off after perfect code. Software developers should think in a similar fashion: if the product isn’t meant to last a lifetime, there’s no need to put all that extra effort into creating a great architecture with a fully configurable modular component software! Create what you need, no more no less. Anything else is simply bad for business.

The Agile Religion versus eliminate waste/YAGNI: I admit it: I was probably one of the earliest agile evangelists out there. In 2001 when I first heard about “lightweight” processes I was completely hooked: this is going to change software development forever! In three ways it did: 1) Software teams added some much needed understanding of mechanisms to how problem-solving creative teams work, 2) Business side understood that the outcome from creating software is at best uncertain and cannot be fully planned and budgeted from, and 3) the placebo effect of “believing” that agile rocks the world gave motivation, trust and controll back to software developers (who previously were functioning like machines or puppets controlled by the business people). Yet, the agile believers took XP, Scrum and other methodologies very seriously and said: “This is what we’re going to do, and we’re going to do it fully!” But following a methodology or process absolutely is exactly what agile is all about not doing. Reducing formal requirements, increasing rapid feedback and contribute to a collaborative environment is good but it all has to fit the corporate structure, the development culture, the business need from IT. Agile devleopment is a toolbox, and a good agile manager will use these tools in the best way possible, preferably combining several techniques but with a simple purpose: deliver business value the best way possible. Because, what is most important: following a process to its absolute or delivering the value asked for?

The silver bullet techniques versus adapting to change: With agile comes techniques like refactoring, pair programming, test driven development, self-documenting code and so forth. All good techniques. But like the previous point, using these techniques in all cases (like XP states) states two things: 1) There’s no room to maneuver. The techniques are enforced rather than adapted, hence working with an opposite psychological effect from what its intent was, and 2) behaves like it’s a silver bullet, which is the one true fact we’ve established does not exist! Insteand, these techniques are wonderful tools a software programmer should know about but used where it’s applicable. Not with a religious-approach that it solves all world problems.

Sometimes just simply programming works best: Yes, it may very well be! Adding all techniques, agile, creating a huge architecture, may sound good. But if the assignment is well understood, utterly simple and perhaps repetitive, why bother? If the software product is a support tool that can, in time, be replaced, why put all the effort into it? If the software can be created in a simple manner, make it compile, and accept that bugs will happen in production, then this may be the simplest approach that generate the most value!

No methodology og techniques can remove the effect of good leadership: Self-managed teams are great! They generate tremendous creative energy along with a dedication and commitment to the work. However, getting there is a long journey that might take years, it’s simply not enough to form a Scrum-team and state “we’re self-managed!”. But good leadership with creative teams is not about micro-management, it’s about getting the team to that ideal state where everyone’s a leader. Until reaching that point, the good leader must address team motivation, use what is available from the agile / software engineering toolbox, keep the team focused on the task at hand and be clear on expected results.
My points being:

1) eliminate waste, that also goes from new techniques or methodologies that’s not applicable in to the situation.

2) Create business value first, and consider that optimal code does not allways provide business value. Good leadership place expectations and focus on the business value. Proud developers will do what it takes to meet those expectations.
3) just following best practice for creative problem-solving teams like rapid feedback and a well established collaborative culture goes a long way - there’s no magic to that :-)