Jan 30, 2008

Permission Marketing and Word of Mouth

I just watched Seth Godin's presentation to Google from a few years back and found that it's just as relevant today as it was then.

It's about 40 mins long and it well worth watching, even if you're not a marketer, if not just to see some great presentation skills.  The talk itself It contains some really useful thinking for anyone tossing up what to do with all those ideas floating around in the back of your head, and how to get the word out there about them.  He talks about how marketing these days is shifting from the intrusive marketing (ie tv ads, junk mail in your letterbox, telemarketers, etc) to "permission marketing" where you get ads relevant to what your interested in, but that don't interfere with what you're interested in.  The obvious one being Google's Ad-Words (which I use on this site for instance).

I can hear you now, thinking "That's great. Yep. Ad-Words.  Gotcha. Big whoop".   But then Seth mentioned that the best marketing is word of mouth, which everyone already knows.  But then he talks about how word of mouth happens.  It's about having something remarkable - as in "something work making a remark about".  In terms of a product or and idea, you can flip that on it's head.  Something is unremarkable if you're not solving anyone's problems.  And if you don't solve anyone's problem then it's not something that people will talk about.  Similarly if your product is middle-of-the-road and pretty much the same as everyone else's, then it's also going to be unremarkable.  If it's boring, then no one will talk about it.

Really interesting stuff.

I then ran across a recent post by Guy Kawasaki about the "Tipping Point".  The Tipping Point for those who don't know is the idea that if you get a few key influential people to talk about your product then you'll have a success.  Why?  Well, the influencers create interest amongst the early adopters, who then create enough demand to draw the pack (most people) who then draw in the late adopters.  At least, that's the theory. Guy debunks this (using Duncan Watt's thinking) and talks instead about how it's many people talking about a product independently (using the original Mac as an example) that creates the demand and success, not a handful of key people with big mouths.  Note that it's "many people TALKING about your product".  If your product or idea is unremarkable, then no one will talk about it.  Game over.  Go home.

Let's say you do start having people talking about your idea, is there anything you can do to try an help that talk along? Jim Benson has posted an interesting idea about running a Social Media campaign.  Basically using the various and many-facteted social networking tools out there to promote an idea or product.  Will it work in the real world?  I don't know - however it does have a few things going for it.  It's marketing based on permission not intrusion, it's marketing based on word of mouth and it's marketing based on relationship.  Those 3 things alone are enough to make it work.  Of course, without the right "remarkable" product, without something that solves peoples problems, then you'll be trying to push water up hill with a straw.  It's never going to work.

Jan 29, 2008

An Agile FAQ

I've recently presented an RDN session around the country focused on agile development, and what it means for developers.

In each session I've been asking people for questions.  Here are a few of the most common questions, and some (short) answers for them.

1. How do you convince management that you should use an agile methodology?

Convincing anyone of anything can be difficult at times, especially if they have a deep grained bias against your proposition.  Without knowing your relationship with management the best advice I can give is to try and educate them.  Give them examples of success stories, show them studies and research, talk about Microsoft adopting the process, the rise of agile in the industry, etc.  Hopefully with enough education you can then convince them to let you try it on a small project.  Use that project to learn your mistakes, figure out what works for your organisation and then grow from there.

2. How do you convince developers to do Test Driven Development (TDD)?

Once again doing the convincing can be hard.  If you're team doesn't do unit testing at all, then don't even think about this for now.  Get them started on TAD (Test After Development) - let them write their code and then add unit tests and try and build up a good code coverage number.  Once they're comfortable with unit testing, interface driven programming, mocking, etc then you can think about moving to a TDD situation.

If your team is comfortable with unit testing convincing them to to TDD can still be hard and is something best shown by example and done by agreement.  Talk about it,  explain how weird it feels at the start, do some lunch time workshops with mini-scenarios to get the team used to the feeling of writing tests first.  Once that's done then try moving to TDD for a fixed period to help ensure that people get over the uncomfortableness (maybe a week or two) and then assess where the team is after that, and see if they're willing to continue or not.

3. When wouldn't you use agile?

Some projects deal with high risk environments or exist in a very controlled environment.  These projects usually have a massive amount of oversight & double checking that goes into each step of development to try and ensure things are done to spec and done right.  In these situations an agile process is unlikely to succeed.  Some of the principles of agile and the practices (TDD, Pair programming) may be applied, but in general because of the culture the project is much more suited to a waterfall style of development.

I also wouldn't recommend the use of agile in a large project (more than 20 people) _if_ the company has never performed any agile development in the past.  Doing agile on a large project with lots of inexperienced people is a high risk move and extremely likely to fail.

I should also mention something that Robert C. Martin said in a recent interviewAs far as the kind of projects that should not go Agile, it is really a matter of company culture as opposed to project type. Very heavy command control cultures probably do not respond very well to Agile development. On the hand, very collaborative environments do.  

4. How do you deal with tenders?

I've touched on this previously (Fixed Price Contracts and Agile Delivery). In essence a tender is all about fixing time, price and scope.  However, if you consider the iron triangle (scope, resources, time & quality) you will quickly realise that if a tender is limiting scope, price and time then the only give you have will be in the quality of the product, or by supplying extending the costs through funding it yourself (ie provision of extra resources if required).

How do you then win a tender and still make a profit?  The same way as companies always have over the years - whack a hunking great margin of error on top of your estimates and start praying that your estimates are accurate and that you're assumptions around the requirements are correct.

In any tender based project the methodology you use to implement the solution is not going to change the fact that there are limits on 3 sides of the iron triangle. Both waterfall and agile implementations are going to be hamstrung by this from day one and only a big fudge factor will help bring the project in correctly.  That said, if I had a choice, I would choose to use an agile methodology each and every time because it will help establish a good collaborative relationship with the customer and having a good relationship with your customer means that you are much more likely to successfully navigate any difficulties in the project and avoid getting into contractual nastiness.

5. How do you convince management and developers that pair programming is better?

Once again, it's a mix of education and experience.

For Management: Yes, a pair of programmers will probably produce more lines of code individually than if they were to work paired, however the quality of that code will be of a lower standard than the code written by a pair.  This means that the business has a choice when it comes to pairing - they can either invest the extra time up front to get better quality the first time around, or they can invest cost into greater bug fixing effort (which also has a lost productivity cost associated with it).  There is a third option of course; they can absorb the bugs and accrue a large code and quality debt for the project.  Explaining it as an economic issue where pairing is the cheapest cost option is the easiest sell.

For Developers: Everyone has done pairing at some point.  They just might not have realised it.  Any time you get another developer to come sit beside you and help you out with a problem you are pairing.  Ask those same developers if they enjoy solving a problem with someone else or by doing it by themselves?  Most will answer that programming with someone else is more enjoyable.  This alone is usually a good enough reason to try it.  What you need to overcome are the initial objections like "I'll never get to work alone!", "it'll only work with the right people", "I won't get credit for my work", "I work faster alone!", "Do I have to sit next to someone else ALL day!", etc.  How you overcome these objections is up to you, but most teams that do pairing have a limit on the number of paired hours, or the types of work that people pair up on.  It really is up to you how you and your team to figure out the best way to make it work and the best way to do that is to try it out.  Much in the same way that a team might experiment with TDD they can experiment with Pairing.

 

As a note you might want to have a look at Pragmatic Programmers book Practices of an Agile Developer or Laurie Williams' & Robert Kessler's Pair Programming Illuminated.

I hope this is of value to you and for those who were at the RDN sessions, thank you for coming :-)

Jan 24, 2008

Visual Studio 2005 Solution File Problems

On the project I am currently working on we had a recent issue where opening a solution in VS2005 was causing a few messages to be displayed.  I was seeing the following

  • "Projects have recently been added to this solution....", and
  • "Some of the properties associated with the solution could not be read"

I eventually found two issues, both of which likely occurred by incorrectly merging the solution file.

1.  Duplicate Source Control sections

We had a second "GlobalSection(TeamFoundationVersionControl) = preSolution" section at the bottom of the solution file.  I simply removed the duplicate section.

2.  Incorrect Path Settings

The other problem was that one of the projects (in the source control section) had an incorrect setting.  It had

SccProjectUniqueName27 = a\\b\\c.csproj
SccProjectName27 = x/y/z
SccLocalPath27 = x\\y\\z
SccProjectFilePathRelativizedFromConnection27 = ..\\..\\..\\a\\b\\

This was fixed by deleting the relativized (is that even a word?) entry and changing the SccProjectName to a/b and SccLocalPath to a\\b

 

Now the solution file opens without warnings as expected and all is right with the world again :-)

Jan 20, 2008

An Introduction to Test Driven Development

As part of my recent Readify Developer Network presentation on Agile Development for .NET Developers I did a quick demo on test driven development and unit testing.  I've made a 10-minute video for the TDD section of the presentation and put it on YouTube so you can look at it any time you like.  Enjoy :-)

 

Please note that the slides from the presentation and a higher resolution video will be available from the RDN site shortly.

Jan 17, 2008

Software is a Service Industry

Ask most developers what they do for their job and they'll tell you that that they write software.  Well, technically that may be the major function performed in the execution of their job, but a developer's goal should not be to write software, but to write software that meets someone's a needs or wants.  To give you some examples:

  • If you write business software, you're trying to help people perform their jobs better.
  • If you write games then you're trying to meet someone's desire to be entertained.
  • If you write security software you're trying to help people keep their information secure.

I think you get the idea.  It's might seem obvious now that it's said,  but it's not something people normally think about.  When spending the major part of your working within Visual Studio then it's very easy to focus on the low level details and forget the high level goals of what it is you're doing.

 

Now if we extend the idea that we are trying to help people through the software we create then we realise that we are trying to service their needs. Any industry that exists to satisfy an individuals needs and wants is a service industry.  What this implies is that the I.T. industry is not a manufacturing industry or a retail industry but rather is a service industry (in fact if you dig to the bottom of any industry you'll see that everything is a service industry).

We have jobs as developers because we are servicing the needs of our customers, and the better we service their needs the more work we get.

So what does this mean?  It means that the customer should be Number One, not us.  We need to remain focused on delivering top quality software that satisfies our customers.  The process of writing code is just one small part of our service and, believe it or not, very few customers care about the internals of our code.

What they want is software that is fit to purpose, easy to use and well supported... with no bugs.  These are the critical elements we need to focus on with software development.  Everything else we do exists only so we can to deliver a service to our customers in a more timely manner.

 

So, the next time you sit down to write some code, think about who you are writing it for and do your best to meet their needs.