Daily Archives: October 4, 2009

Takin’ Care of Business (The SI FAQ)

You get up every morning

From your alarm clock’s warning

Take the 8:15 into the city

There’s a whistle up above

And people pushin’, people shovin’

And the girls who try to look pretty

And if your train’s on time

You can get to work by nine

And start your slaving job to get your pay

If you ever get annoyed

Look at me I’m self-employed

I love to work at nothing all day

And I’ll be …

Taking care of business, every day

Taking care of business, every way

I’ll be taking care of business, it’s all mine

Taking care of business and working overtime

Work out!

If it were as easy as fishin’

You could be a musician

If you could make sounds loud or mellow

Get a second-hand guitar

Chances are you’ll go far

If you get in with the right bunch of fellows

People see you having fun

Just a-lying in the sun

Tell them that you like it this way

It’s the work that we avoid

And we’re all self-employed

We love to work at nothing all day

And we’ll be …

Taking care of business, every day

Taking care of business, every way

We’ll be taking care of business, it’s all mine

Taking care of business and working overtime

Work out!

Take good care of my business

When I’m away, every day, whoo!

Takin’ Care of Business
  by Randy Bachman, Bachman-Turner Overdrive

As the blog continues to grow in readership and popularity, the pace of requests increase. As such, I thought it would be a good time to put together a FAQ which covers, among other things, SI’s product and service review policies, publishing guidelines, book review requirements, and event attendance, coverage, speaking and promotion policies.

Here are the questions that I have answered. If you have any additional questions you’d like answered, send them along and I will consider adding them to future revisions of the FAQ (which will always be accessible off of the sidebar).

  • Will you review my product?Answer
  • Will you review my service?Answer
  • Will you review my portal, web service, social network, or community?Answer
  • Will you review my online offering if I sponsor the review?Answer
  • Will you cover my story?Answer
  • Will you post my press release on your blog?Answer
  • Will you publish my article?Answer
  • Will you promote my event?Answer
  • What about a media partnership?Answer
  • Will you review my book?Answer
  • Will you attend and cover my event?Answer
  • Will you speak at my conference, roundtable, seminar, or event?Answer
  • Will you exchange links with my site?Answer
  • Will you do a sponsored post on a particular topic?Answer
  • Will you accept sponsored links in your posts or on the sidebar?Answer
  • Will you write an article for me?Answer
  • How can you help me?Answer
  • Are you on X? Can I connect with you?Answer
  • Can I subscribe to your blog?Answer
  • I’m new to sourcing/procurement/supply chain and I noticed you have collected a great deal of solid information and resources. Where should I start?Answer

If Software Development Outsourcing is Too Agile, You’ll Be Kayaking Over the Waterfall

A recent article on how agile methodologies help software development outsourcing over on SourcingMag.com had some very good points on how agile software development can help you with your software development outsourcing. However, having lived through the Agile Craze in IT, I know that you can overdo it and actually hinder your development processes and development outsourcing.

Let’s start by review the positives put forward by the article:

  • Methodology Fit
    The ability to make continuous process changes and improvements is a boon to two organizations trying to synch their processes for the first time.
  • Bridge the Communication Gaps
    Frequent release-and-review cycles can help to bridge communication gaps.
  • Perfection is Iterative
    No one gets it right the first time. Only the lucky get it right the second time. Just about everything of significant technological complexity in this day and age takes at least three attempts to get right — and when you’re talking software, thirty attempts (behind the scenes) isn’t uncommon …
  • Building Expertise
    You can move your development to an organization that has built a number of similar systems in the past.
  • Responsiveness to Change
    Requirements and processes change continuously … more frequent iterations allow for faster revisions of requirements and code-bases.
  • Quality
    Faster feedback generally means that problems are identified – and solved – sooner in the development process.

Now we’ll look at the negatives that can result if you’re not careful:

  • Methodology Fractured
    While the ability to make rapid changes can be beneficial when trying to synch processes, they can also break processes that are working well.
  • Deepening the Communication Chasm
    Frequent release-and-review cycles that lead to constant improvements can give you the illusion that the communication gap is bridging when in fact the chasm underneath is deepening. The successive improvements could be due to trial-and-error and luck and not have anything to do with communication improvements. Plus, an over-focus on feature-function might cause you to ignore relationship building, which is critical if you are ever going to truly bridge the communication gap, especially with offshore development organizations in India, China, and Poland, for example.
  • Running-in-Place
    The faster you respond to change, the faster the change requests start coming in. If you’re not careful, you’ll start to cycle through changes until you’re back with what you started with — after months of wasted effort.
  • Lack of Robustness and Flexibility
    If you only measure quality by “how close the end-user design is to what you envisioned”, or “how many of your test cases run bug free”, you might miss the fact that the code is an unmaintainable mess of spaghetti that you’ll never be able to maintain, update, or modify again. Very Bad Code is a regular by-product of overly-aggressive agile development cycles with too many iterations. Building good code requires building a good, stable, underlying architecture that does not change. Just like you can’t use the frame of a three-story house for a 6 story office building, you can’t use an architecture for low-volume EDI message exchange for a high-volume real-time XML exchange. If you adopt a high-frequency agile development cycle and don’t take the time to get the right framework and software architecture up-front, the developers end up having to hack the code every iteration to make their changes and after five or six iterations you have a tangled mess that even a development guru won’t be able to make heads or tails of.

So while agile can be beneficial to your development outsourcing, it has to be used in moderation or the drawbacks will far outweigh the advantages.

Share This on Linked In