Saturday, September 28, 2013

A View on Software "Best Practices"

"He is noble, wise, judicious, and best knows"
-- Shakespeare, Macbeth
Act IV, Scene II, Lines 16

Being in the software industry for a few years now, I've seen my fair share of "Best Practices" come and go: RUP, UML, CMM, Scrum, Agile, Lean, ITIL, ...  What you say, "Sir we have just starting using one of those 'Best Practices' you have said have come and gone and we have never been better!"  Perhaps.

"In his writings, a wise Italian
says that the best is the enemy of the good
"
-- Voltaire, La Bégueule

But sir you say, "What does a dead French man have to do with our newly implemented 'Best Practice'"!  Everything!

The best is the enemy of the good, in fact as Sir Robert Watson-Watts say, "Give them the third best to go on with; the second best comes too late, the best never comes"!  Surely I jest, the third best, why not just the worst or the worst worst, why even brother at all?!?  How could any enterprise live with the third best?!?

Question, do you even know what the third best would be for you?  Do you know yourself well enough to know if something is even the third best for you?
As the Temple of Apollo says, Know thyself!  Know thyself, one of Apollo's most deadly arrows.  I know you do not have time for philosophical crap, but the question is still valid.  If you actually know yourself, as you are now not as you want to be, it would be easy to chose practices that work for you.  Practices that work for you as you are now, as you are as a being in this time, at this place, in this context in history.

I know, no philosophical crap!  The point is that truly knowing, you cannot lose.

"If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle."
-- Sun Tzu, The Art of War, Chapter 3

As Sun Tzu says, knowing yourself is not enough to truly find a best practice (yeah, I just used that term again), you must also know the context in history.  What is the situation, who are the players, what is needed, what do you have, ...  In less words, the context in history.

"A very popular term within the IT community is 'best practice'. It's a wonderful marketing term, how could someone possibly argue about adopting a best practice, but does the concept really make sense? I'm not so sure. There are many examples where a practice that is considered "best" in one context is questionable within another."
--Scott Ambler, Questioning "Best Practices" for Software Development

Scott Ambler is championing context in history and knowing thyself.  There are many different ways to see things.




From one point of view, four 2x4s on the ground next to each other is the number 4, but from another point of view there are 3 open spaces created.  Seeing both points of views at the same time, one is able to chose which point of view is best for them in their current historical context.

Have we gone off the topic at hand?  What about Software "Best Practices"?  Today's "Best Practices" as a colleague of mine, Dave Smith pointed out,  "Today's 'Best Practices' are just the currently generally acceptable practices".



A Software "Best Practice" is often just something that can broadly work and has been attempted to be generalize and sold to different companies.  If you know yourself and know the context in which you exist, then you would be able to pick and chose the best bits of different practices that are applicable to you and your current context.  If you find that one does not work as you thought it would, then do as the old joke goes, "Doctor it hurts when I do this.  Then stop doing that"!

Sunday, September 22, 2013

A View on New Software Projects and Run the Business Work

"He'll shape his old course in a country new."
-- Shakespeare, King Lear
Act I, Scene I, Line 187

"The thing that hath been, it is that which shall be; and that which is done is that which shall be done: and there is no new thing under the sun. Is there any thing whereof it may be said, See, this is new? it hath been already of old time, which was before us."
-- Ecclesiastes 1:9-10

Somehow most of my professional career has been spend doing new software projects.  To me a new software project is one in which at least one thing is brand new which is being brought into the organization by IT.

Examples of new software projects

  • new middleware
  • new release tool
  • new business system

From my point of view, for even if I could say to have an understanding of someone else's point of view it is still my understanding of their point of view and not there actual point of view.  From my point of view, new software projects are a bit like asking someone to order lunch for a meeting and giving them a couple thousand dollars (obscene indeed).



For a couple thousand of dollars that lunch better be really good and it better be there on time or a bit early.  O-and there will be hell to pay if there are any olives or if it is not from that new place down the street that just got a 27 from Zagat!

New projects typically have some type of tight deadline, which more often than not is self imposed.  There may or may not be a real reason for the deadline, but it will typically be tight.  Sometimes someone very high up wants to make a good impression (and get a promotion after the project is done) or there is some feeling that since you are using this new magical tool everything will be done like "that"!

If you are on a very large new project you'll more likely than not will bring in outside help.  As Niccolo Machiavelli tells us this is dangerous.

"Mercenary and auxiliary troops are useless and dangerous. Mercenaries are “disunited, undisciplined, ambitious, and faithless.” Because their only motivation is monetary, they are generally not effective in battle and have low morale. Mercenary commanders are either skilled or unskilled. Unskilled commanders are worthless, but skilled commanders cannot be trusted to suppress their own ambition. It is far more preferable for a prince to command his own army."
-- Niccolo Machiavelli
The Prince, Chapter XII

The people you bring in to help in general do not really care about you, your project, or company; they are simply there to get paid!  It is rare, but there are some consultancies that seem to care, but this is the exception not the rule!

That is one of the biggest advantages with run the business work, the people doing the work will have to live and breath in the same environment which they are creating.  If you have people who really care they will follow the Boy Scout Rule:

"Always leave the campground cleaner than you found it."-- as quoted by Uncle Bob
Clean Code

This means the more people who really care work on a legacy system, the better it will get!

Working with run the business type of system is like have a meeting over lunch because one of the key stakeholders is not available any other time in the next two weeks because they are going on vacation.  The person setting up the meeting is really sorry, in fact they are so sorry they bring in lunch for everyone.



No one expects much more than keeping things going from run the business type work.  Meaning you'll get to do what you think makes the most sense for the work at hand and often they are understanding if things take a little longer because the system is a little quirky.

The non-conclusive conclusion is that both types of work have there pros and cons, but if you understand what type of work you are doing and what the world will be like doing that kind of work you can fully throw yourself into it and make it the best it can be.