Guy Kawasaki has some great points on building a community.

1. Create something worth building a community around.
2. Identify and recruit your thunderlizards—immediately!
3. Assign one person the task of building a community.
4. Give people something concrete to chew on.
5. Create an open system.
6. Welcome criticism.
7. Foster discourse.
8. Publicize the existence of the community.

Looking back, i3Connect did a great job in items 1, 4 and 5. We did a OK job in 6 and 7 and a poor job in 2, 3 and 8. This article would have been very helpful for us in 2000 when we were starting out. For a startup like i3Connect, a community is what would make or break it and our poor execution on the points above proved to be fatal to us.

All said and done, I think Microsoft is one company that has done a good job on creating a community, especially on item 5.

Sorry for the lack of updates to both the site and blog. The site was difficult to update via  web browser (thanks to the custom ASP.NET engine I wrote) and blog running Community Server was infested with comment spam. This is a classic syndrome of the Broken Window concept.

The site runs DotNetNuke 4 (on ASP.NET 2) and uses modules like Blog, Articles, etc. Thanks to Orina’s help in migrating the blog entries from the old blog server, all the earlier posts should be there.  

Now that the technology problems have been addressed, I hope to post information you may find useful. Unfortunately most of my work and information that I learn – is covered by some form of NDA. That said I will try to work around those restrictions and post in areas of Software Management, User Experience, Startups and cool technology.

If there is something particular you like to see, let me know.

These folks have done a great job in documenting how VSTS helps the SDLC process. If ever there was a picture that was worth a million words, this is it. Microsoft needs to use this picture for their VSTS marketing efforts and hire these folks.

Eric Sink has a great article on Tenets of Transparency for ISVs.

You can extend this to individuals in any job role. The more transparent you are, the faster you can get your work done.

Start with a simple exercise, before attending any meeting, send an email documenting your expectations for that meeting. You will be amazed how quickly the discussion moves forward.

Along with Comega, the MS research folks have come up with Spec#, which is oriented towards developing higher quality software by adding features like non-null types, checked exceptions, method contracts, model-based testing, etc.

The great things about these two research projects are that they extend and build on C#, which increases the chances that it will be usable by real world programmers, to provide actual feedback that can be used to enhance the C# language.

Hopefully, feedback from these projects will give C# 3.0 and 4.0 features that reduce programming time, reduce object-database-xml impedance, enable safer concurrent programming and help writing more secure and higher quality programs.

One of the reasons projects spin out of control is poor estimation and scheduling of work. There have been tons of material on estimation but scheduling has not got the same coverage.

One of the common pitfalls of scheduling is mapping a project plan estimated numbers to a team member at 40 hours a week. Let’s run though this with an example, John is working on a 6 month project that is assuming that he would be working for 40 hours a week for the next six months. Besides working on this project, John has to attend a regular staff meeting, take care of some production support issues, take part in a virtual team for planning, attend some training and mentor a new employee. Also, John is planning to take three days off around Thanksgiving to spend the week with his family.

End result is that John this month can spend only 25 hours week on an average on this project but the project manager has gone ahead and budgeted at John to spend 40 hours a week. Poor scheduling like this that does not take care of the actual number of hours that a team member can commit and ignores vacation and holiday times are doom their projects to failures. If your project plan is based on inaccurate data, how on earth do you expect to ship on time.

There is a simple solution to this – Always plan with the correct numbers of hours a team member can spend and include vacation/holidays/buffer time.

One of the reasons projects spin out of control is poor estimation and scheduling of work. There have been tons of material on estimation but scheduling has not got the same coverage.

One of the common pitfalls of scheduling is mapping a project plan estimated numbers to a team member at 40 hours a week. Let’s run though this with an example, John is working on a 6 month project that is assuming that he would be working for 40 hours a week for the next six months. Besides working on this project, John has to attend a regular staff meeting, take care of some production support issues, take part in a virtual team for planning, attend some training and mentor a new employee. Also, John is planning to take three days off around Thanksgiving to spend the week with his family.

End result is that John this month can spend only 25 hours week on an average on this project but the project manager has gone ahead and budgeted at John to spend 40 hours a week. Poor scheduling like this that does not take care of the actual number of hours that a team member can commit and ignores vacation and holiday times are doom their projects to failures. If your project plan is based on inaccurate data, how on earth do you expect to ship on time.

There is a simple solution to this – Always plan with the correct numbers of hours a team member can spend and include vacation/holidays/buffer time.

One of the points raised by the NIH (Not Invented Here) folks is Reusing software artifacts does not encourage innovation.

The fallacy with the argument is that if there is already a reusable artifact, then by definition your artifact cannot be innovative. You are just reinventing the wheel and trying to claim that your wheel is better than all the others and thus innovative.

IMHO, Software Reuse allows you to focus on innovative ways to solve business problems by taking care of mundane building blocks.

Let’s take an example of Joe, an IT developer/analyst who is assigned to build reports. Joe decides to use ASP.NET and C# to write reports after understanding the requirements. Most of Joe’s time will be spent in writing queries, formatting reports and other low level activities. At some point of time, Management will start wondering why does it take so long to get a simple report and how come the report does not work in Excel. They will wonder where all the money they are spending is going.

Mary builds a reporting solution block that allows her to quickly build reports without focusing on the C# and HTML code. This allows her to work with the business teams and also suggest what reports add value and how to deliver to them on a regular basis via email. Mary can build a reporting solution block by reusing reporting solutions like SQL Server reporting services or reusing .NET components like Active Reports, etc.

By spending her time solving business problems in an innovative fashion with technology, Mary adds value to both herself and her organization. Mary shows true innovation by doing more than her expected role by working with her business teams to figure out how they can make quicker and better decisions based on the information she provides.

If Management had to cut or outsource a job, guess who would they choose.

One of the points raised by the NIH (Not Invented Here) folks is Reusing software artifacts does not encourage innovation.

The fallacy with the argument is that if there is already a reusable artifact, then by definition your artifact cannot be innovative. You are just reinventing the wheel and trying to claim that your wheel is better than all the others and thus innovative.

IMHO, Software Reuse allows you to focus on innovative ways to solve business problems by taking care of mundane building blocks.

Let’s take an example of Joe, an IT developer/analyst who is assigned to build reports. Joe decides to use ASP.NET and C# to write reports after understanding the requirements. Most of Joe’s time will be spent in writing queries, formatting reports and other low level activities. At some point of time, Management will start wondering why does it take so long to get a simple report and how come the report does not work in Excel. They will wonder where all the money they are spending is going.

Mary builds a reporting solution block that allows her to quickly build reports without focusing on the C# and HTML code. This allows her to work with the business teams and also suggest what reports add value and how to deliver to them on a regular basis via email. Mary can build a reporting solution block by reusing reporting solutions like SQL Server reporting services or reusing .NET components like Active Reports, etc.

By spending her time solving business problems in an innovative fashion with technology, Mary adds value to both herself and her organization. Mary shows true innovation by doing more than her expected role by working with her business teams to figure out how they can make quicker and better decisions based on the information she provides.

If Management had to cut or outsource a job, guess who would they choose.

If you have been reading Ashvil.Net or have subscribed to my RSS feed. Please take some time to help me understand why you read my blog by taking this survey, powered by nsurvey.org.

I plan to use this information to help me understand my audience better and fine-tune my articles, blog and presentations to my readers.

Thanks,
Ashvil