I don't usually blog about promotions and vendor programs - but this is something we joined and if you are a startup using/considering Microsoft's technologies you ought to hear about.

The program is called Microsft Bizspark and essentially it gives you free licenses for all the development team for the porpuse of designing, developing, testing and demoing the application - that's a huge save in development costs (we're using tools like Mingle and subversion but the program even includes a license for team foundation server if you fancy that)

Furthermore, if you, like us, develop a software as a service (SaaS) solution you are also eligible for free production license

To be eligible you have to

1. be a startup that develops software
2. privately held
3. be in the business for less than 3 years
4. and have less than 1 million USD revenues

check out the program guide for more details

Powered by ScribeFire.

 

I didn't intend to comment on this post from Jeff Atwood where he claims we (developers) are typists first and programmers later but since I qouted his blog on my previous post I reconsidered.

I'd have to say that this isn't one of Jeff's most intelligent posts.
 How many lines of code do you think developers write per day? let's google us some numbers:

Here is one interesting qoute

"Let's see if, quantitatively, there's any truth to the perception that the code velocity (net lines shipped per developer-year) of Windows has slowed, or is slow relative to the industry.  Vista is said to have over 50 million lines of code, whereas XP was said to have around 40 million.  There are about two thousand software developers in Windows today.  Assuming there are 5 years between when XP shipped and when Vista ships, those quick on the draw with calculators will discover that, on average, the typical Windows developer has produced one thousand new lines of shipped code per year during Vista.  Only a thousand lines a year.  (Yes, developers don't just write new code, they also fix old code.  Yes, some of those Windows developers were partly busy shipping 64-bit XP.  Yes, many of them also worked on hotfixes.  Work with me here.)

 

Lest those of you who wrote 5,000 lines of code last weekend pass a kidney stone at the thought of Windows developers writing only a thousand lines of code a year, realize that the average software developer in the US only produces around (brace yourself) 6200 lines a year.  So Windows is in bad shape -- but only by a constant, not by an order of magnitude.  And if it makes you feel any better, realize that the average US developer has fallen in KLOC productivity since 1999, when they produced about 9000 lines a year.  So Windows isn't alone in this.  [KLOC data comes from “Worldwide IT Trends & Benchmark Report 2001”, produced by META Group (now acquired by Gartner)]"

Here is another one from Jeff Atwood himself

But what I really want to focus on here is how you measure a project's size. What's big? What's small? McConnell is using lines of code (LOC) as his go-to measurement. Here's a table that illustrates the relationship between project size and productivity:

Project Size	Lines of code (per year)	COCOMO average
10,000 LOC	2,000 - 25,000	3,200
100,000 LOC	1,000 - 20,000	2,600
1,000,000 LOC	700 - 10,000	2,000
10,000,000 LOC	300 - 5,000	1,600

some of the best numbers I've found:

"

Alien Problems:

problems about which I know nothing, those have seen them for first time:

12 lines of usefull code per hour :((, includes thinking on it 

Some what, I know problems:

problems, that I know about but have not solved before.

33 lines of usefull code per hour, including thinking

Ah, I have done that before:

63.5 lines of useful code per hour"

These numbers shows us the most of the time spent on projects is doing other stuff- as in not typing programs.

but let's say you code 1000 lines of code per day. if you code for 4 hours in that day you would write 4-5 lines per minute - how many words per minute do you think that amounts to? unless you are writing COBOL I would say 3-5 words per line. what sort of typing speed do you need for that?

Note that " lines of code" is not a very good measurement of productivity. e.g. refactoring a design may generate lines of code for you (e.g. extact method) or you may remove lines of code (applying principles like DRY) or you can generate code from templates /wizards)
As John D. Cook says:

"I heard of a study recently that concluded inexperienced and experienced programmers write about the same number of lines of code per day. The difference is that experienced programmers keepmore of those lines of code, making steady progress toward a goal. Less experienced programmers write large chunks of code only to rip them out and rewrite the same chunk many times until the code appears to work. "

In any event,in my experience, you just get better in typing just because you spend all that time at the keyboard - it is defenetly not a goal in itself, just a nice side-effect.

Powered by ScribeFire.

 

Even if you don't write your tests first on a regular basis, you probably want to adopt that at least for debugging.
All the developers I know want to repro a bug before they make any changes to a the code (I know I do). When you write your test before you debug you do just that and you get several other benefits since you can

1. Make sure that the bug is indeed reproducable
   
2. Easily (and repeatedly) step through your code to pinpoint the bug
3. Verify that the bug is fixed
4. Get a regression test to make sure the bug isn't reintroduced
   

The only question now is what is the difference between a bug and a new feature?

One of my favorite things about UserVoice -- which we use for Stack Overflow -- is the way it intentionally blurs the line between bugs and feature requests. Users never understand the difference anyway, and what's worse, developers tend to use that division as a wedge against users. Nudge things you don't want to do into that "feature request" bucket, and proceed to ignore them forever. Argue strongly and loudly enough that something reported as a "bug" clearly isn't, and you may not have to to do any work to fix it. Stop dividing the world into Bugs and Feature Requests, and both of these project pathologies go away. (coding horror)

But that's something for another post :)

Powered by ScribeFire.

 

One important (yes, yes important) aspect of continuous integration (CI) is the way broken builds are reported. I'll tell you why but before that let's quickly recap on CI in general.
The point is to get an automated build process that run's after every check-in and takes the system for a quick spin to verify all the major parts are still OK. CI helps maintain the quality of the overall code by ensuring that components don't drift too much apart and that the current version is still valid to a reasonable degree.

Martin Fowler's article on CI (referenced above) lists the following practices

• Maintain a Single Source Repository.
• Automate the Build
• Make Your Build Self-Testing
• Everyone Commits Every Day
• Every Commit Should Build the Mainline on an Integration Machine
• Keep the Build Fast
• Test in a Clone of the Production Environment
• Make it Easy for Anyone to Get the Latest Executable
• Everyone can see what's happening
• Automate Deployment

What I am saying that a practice missing from this list is to maintain a clear concise broken build report. You see, whether we like it or not builds break. Not every checking (well hopefully anyway:) and not every day but that isn't a scarce sight either.
In our setup we get an email every time the build breaks. That's a good thing - since it increases the visibility of the problem. The message tells us who broke the build and what's the error (something doesn't compile, unit test broken or smoke test broken) and which file.

The problem is that is (was) that up until recently these details were unreliable for instance

• The error message was so long nobody bothered to read where the problem is
• Once a build was broken every new checkin also got the broken build notice - this time pointing the new person (doing the checking ) as the problem's source (even though the previous person was to blame"
• etc.

The problem here is that unreliable reports quickly turn into white noise nobody pays attention to (someone at the team said it was like the boy who cried wolf -by the time it is really "your" problem you are no longer listening. When nobody pays attention, problems get to age - in the long run this can also invalidate the whole CI approach - somewhat like the broken windows theory. So for no broken builds the team has to pay attention to what's wrong. The way to do that is to invest in the build script to make it more easy to understand  and as reliable as possible  - this is something we did (and still working on). I know I don't want to take the risk of broken build white noise...

Powered by ScribeFire.

 

I got a question from Dru for my opinion of tow messaging subscription modes - subscription by message (type) and subscription by topic
The way I see it there are two different usages for Topics.

The first use for topics is for grouping or marking related messages. In this scenario you can actually break the subscription into three different levels of  generalization:

1. Per message- interested parties subscribe to a specific type
2. Topics - interested parties subscribe to a set of related types
3. Topics hierarchy - interested parties subscribe to a set of sets

Here, when it comes to topics -on the pro side you get to easily subscribe to a lot of message types and on the con side you get to easily subscribe to a lot of message types...
The less specific the subscription, the harder it is to ensure it would work in open environments (i.e. when different organizations or groups get to integrate with your services). The problem lies in the number different messages you need to be able to handle/understand/parse and the control on new  types of messages. Getting versioning right with messages is hard enough when you have a hierarchy well that's just much harder

The second use for topics is routing.In this scenario a specific message type  can be sent using different topics.And the  topics basically become part of the  meta-data of the message. The supporting infrastructure can then use that meta-data to get messages to different subscribers. For example,  In a defense system project I participated in , we used Tibco Rendezvous support for topics to define interest regions on a closed set of messages e.g.  say you want only the messages related to the middle-east or the ones related to the US etc.
In the current infrastructure I am building I am going to implement something similar to topics (albiet without hirarchies) to allow different routings based on different saga types (so services that stay the same don't have to change thier behaviours)

To sum this, I would say that in my opinion the latter use for topics  is more useful for  general purpose use and the first use for topics is more useful in closed systems

P.S.
if you have an interesting question on SOA or architecture you can send it in and if I think it would interest a wider crowd I'll blog it here
 

Reshef Mann, one of the members of our devdiv released a nifty little utility for reading configuration files into easy to work-with type-safe interface.
Instead of trying to explain it - Here is the example from his Getting Started :

When you have .config file:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="MailNotificationSettings.SmtpServerAddress" value="http://localhost"/>
    <add key="MailNotificationSettings.Username" value="user123"/>
    <add key="MailNotificationSettings.Password" value="passwd123"/>
  </appSettings>
</configuration>

Define the following interface:

public interface IMailNotificationSettings
{
    Uri SmtpServerAddress { get; }
    string Username { get; }
    string Password { get; }
}

And from your program use this code:

public static void Main()
{
        ConfigurationReader configReader = new ConfigurationReader().SetupConfigOf<IMailNotificationSettings>();
        IMailNotificationSettings mailNotificationSettings = configReader.ConfigBrowser.Get<IMailNotificationSettings>();
        
        var mailNotificationService = new MailNotificationService(mailNotificationSettings);
        
        //
        //      Do the work..
        //
}

The project is open sourced under the Apache 2.0 license- so feel free to use it