Review and Summary of Greg Young's presentation

Greg had a presentation here in Montreal for the user group ".NET Montreal Community". I didn't know Greg before his presentation. He was talking about "Everything you wanted to know about architecture but were afraid to ask". I must say that this presentation was really revealing to some point. Greg really made a point that customers are the architect's priority and that the job of the architect is to bring IT and Business together.

His presentation was energetic, funny (man... you should see those slides!) and when you left... you learned something.

Here's what I remember 24 hours after the presentation.

Context is everything.

Pushing a prototype directly to production might be a good idea if it means the company's survival to get this product available. It all depend on... the context! If the application is a startup and no money is being made, the faster you have a product, the faster money starts to get in. In this scenario, you have to make some sacrifices. Instead of configuring a BizTalk installation, you might do a simple In-Code workflow that will help you get the first version out. It is not however a reason to keep the code crappy. This is a technical debt and will need to be paid back later. When the product/business starts making money, a proper BizTalk installation will have to be done and rewriting the workflow part will probably be time intensive.

Software is there to bring money or to save money

Which bring us to this. Money.

A software is not there to save reports to a database. It's there to save money by automating the reports creation so that someone doesn't have to spend 3 hours making a report (saving money here!).  It's there to MAKE money in the case where you are actually building a product or offering a service to potential client. By keeping this in mind, we keep a better view of what the client really want.

When in a BBoM, build bubbles

If you are in a situation where all the code is crap, start by building a bubble around what you are currently implementing so that other system can't break you. By bubble, we mean "clean code" that will do the work it is supposed to do, be testable, perform, etc..

Of course the bubble is going to be pierced and demolished with time but the longer people work on the system and the more bubble you build and in the end, you finish by having a nice encapsulated system with less mud. There will still be mud. It never will go totally away. But way less than if you would have thrown garbage code everywhere.

TTL (time to live) of a system is important

If the system is going to be rebuilt every 3 years, it's worthless to build it like it's going to last 25. A lot of money can be saved when you don't have to make code that will last 25 years.

It doesn't mean that QoS and other non-functional requirements are not necessary. It is as necessary as anywhere. It just means that there won't be a 8 month planning to build the best architecture possible so that it can actually overcome ANY changes the business might have. By reducing the amount of architecture and choosing a simpler architecture that will be easier to maintain but less impervious to changes. Complexity to such a system will eventually increase up to a point where a rewrite is necessary. But here is the trick... a planned rewrite. Because of this, less time is spent on development and more time is spent on making money. Business loves that.

Architect must keep sight of the current context

Let's take an example. You have been hired by a small retail business to build an e-Commerce web site. The company is a start-up and living off debt. Their website is scheduled to be release in a month and they are expecting this money to payoff their debt and increase the sales.

Of course, you could start by building a site that will suite their needs and will start making them money. But you can also build the Next-Generation-E-Commerce-Application-That-Will-Blow-Competitors-Away but that will take 2 years to complete.

The goal is to keep sight on what the client need. The client want to make money. It's boring. It's more fun to build something that is incredibly powerful and that will be a real technical pleasure to build. If you chose #2, you just lost sight of your context.

The client would need money but you are lost on building "the next big thing".

Conclusion

Context is king for an architect. Craftsmanship must take the second place when making money (thus paying YOU) comes in the highest priority. It's not however a reason to slack off and write crap code. The better our code the easier to maintain and the easier to add new functionality it is. There is just times that prototypes are going to be shipped in production because it's essential to the business and that you are going to maintain it. The main goal is to be aware when we get a technical debt and to be able to reimburse it as soon as possible to keep the client happy.

The presentation Greg gave was very interesting and I really would love to see another presentation by Greg (DevTeach 2009? Montreal User Group?). If I got anything wrong in here, please tell me. I would love to discuss it with more people!

Re: Do We Need a New Internet?

That was the question asked by the New York Times in this article.

If you were in for the short answer and want to leave that quickly... here it is. No.

What I really liked about this article how that "growing belief among engineers and security experts that Internet security and privacy have become so maddeningly elusive that the only way to fix the problem is to start over".

Start over? What happen when you start over? Ask Netscape, dBase, and many other. Joel Spolsky have written this inside his blog in April 2000. Close to 9 years ago and I still agree with him. But those are private company that failed because they were in a competition with other companies. That can't be true for the internet right? The current network is now spread to pretty much all countries in the world. The United States of America are still among the leaders and the ones bringing bright ideas/technology to improve what we already have. If America were to drop out of the Internet and start their own thing, 2 things would happen.

First the network would stay alive (how many countries can just start over?). And America would seriously lag behind... like Netscape, dBase, etc. Sound familiar? Yep. That's it's... starting from scratch.

What I really disliked in the article is that "[...] users would give up their anonymity and certain freedoms in return for safety". Americans already did this and nobody is really more safe. I'll refer to my good friend Ben to take over for this one: "He who sacrifices freedom for security deserves neither.".

So... No. There won't be any new "Internet". We must focus on what we already have. Like Joel Spolsky already wrote in this April 2000 article, "It's harder to read code than to write it". Taken on an IT side, it would mean that it's harder to understand how everything is working than to just start over and start from scratch. Starting from scratch is easy because you have a green field but just like the current network, it would become really fast as close to what it is today. If it's faster, people will find bigger things to transfer. If it's safer, people will find bug in the software somewhere and exploit them. If you have less freedom... that will always be gone.

So stop complaining. Fight for Net Neutrality but please stop believing that starting anew will solve all your problems. Most of the time... it only bring other problems that you haven't seen before and nothing would have really changed.

Unit testing Internals member of a solution from another project

Here is a little bit of knowledge that lots of people are not aware of. There is an Attribute that is InternalsVisibleToAttribute that allows access to a specific external project (the unit test project).

This attribute, once inserted inside AssemblyInfo.cs, will grant "public" visibility to all internal members of the project to the project specified within the attribute.

Here is how it is shown on MSDN:

[assembly:InternalsVisibleTo("MyAssembly, PublicKey=32ab4ba45e0a69a1")]

It is however wrong and will never work. The main reason is that what is there let us believe that it's the PublicKeyToken but it is in fact the PublicKey as clearly typed there.

So... how do we get this PublicKey? By executing the following command:

sn -Tp MyAssembly.dll

The result is going to be something like the following:

Public key is
0024000004800000940000000602000000240000525341310004000001000100adfedd2329a0f8
3e057f0b14e47f02ec865e542c2dcca6349177fe3530edd5080276c48c6d02fa0a6f67738cc1a0
793be3322cf17b8995acc15055c00fa61b67a203c7eb2516922810ff0b17cd2e08492bdcafc4a9
23e6fff4caba672a4c2d0d0f5cac9aea95c3dce3717bb733d852c387f5f025c42c14ec8d759f7e
b13689be

Public key token is 96dfc321948ee54c

Here is the end result to make it properly visible:

[assembly: InternalsVisibleTo("AssemblyB, PublicKey="
+ "0024000004800000940000000602000000240000525341310004000001000100adfedd2329a0f8"
+ "3e057f0b14e47f02ec865e542c2dcca6349177fe3530edd5080276c48c6d02fa0a6f67738cc1a0"
+ "793be3322cf17b8995acc15055c00fa61b67a203c7eb2516922810ff0b17cd2e08492bdcafc4a9"
+ "23e6fff4caba672a4c2d0d0f5cac9aea95c3dce3717bb733d852c387f5f025c42c14ec8d759f7e"
+ "b13689be" )]

After this step is done, all reference to internal members are considered "public" for this specific project. This simple trick allows you to complete your tests and don't gives any excuse not to test.

Problem deploying a solution package on a SharePoint 2007 farm?

You have a WSP and you are trying to deploy it inside the farm and it doesn't work. You hate it. You try to look in the Event Viewer, SharePoint logs, etc.

Before you event start looking around everywhere, be sure to know that when you are adding/deploying a solution package you need some specify right.

Here is a small checklist:

• DBO access to the Configuration database (normally end with "_Config")
• Farm administrator of the SharePoint site

But you are probably why it was working on the development machine and not in production?

Why am I not DBO?

Normally when a development machine is created, the developers are Administrators on the machine. Most SharePoint/WSS installations are made on a SQL Server 2005 installation. When installing SharePoint on a SQL Server 2005, all administrators of the machine where the database is installed are DBO. However, in a production environment, developers are given more restricted access and often doesn't have DBO access on the database.

Why am I not Farm administrator?

As for the Farm administrator situation, the user that configure SharePoint on the development machine is automatically given Farm Administrators right which is not the case in Production environment.

Conclusion

It is really important to know which minimum permissions are required to do certain task inside SharePoint 2007. This is a specific case where only trusted users are allowed to make such system wide changes. SharePoint 2007 is configured to be "secured by default" and restricted to disallow any unauthorized user to make changes that could compromise the farm.

Enjoy your SharePoints deployments

Easily enable databindings on a ToolStripButton

I was developping an application lately and I needed to bind the "Enabled" property of a ToolStripButton to my Presenter. I failed to find any "DataSource" or "DataBindings" property. I then decided to make my own button without reinventing the wheel to enable this capability.

Here's this simple class:

using System.Windows.Forms;

namespace TestProject
{
    public class ToolStripBindableButton : ToolStripButton, IBindableComponent
    {
        private ControlBindingsCollection dataBindings;

        private BindingContext bindingContext;

        public ControlBindingsCollection DataBindings
        {
            get
            {
                if(dataBindings == null) dataBindings = new ControlBindingsCollection(this);
                return dataBindings;
            }
        }

        public BindingContext BindingContext
        {
            get
            {
                if(bindingContext == null) bindingContext = new BindingContext();
                return bindingContext;
            }
            set { bindingContext = value; }
        }
    }
}

Once you include this simple class inside your project/solution... you can easily convert any ToolStripButton into our new ToolStripBindableButton.

And I solved my problem like this:

myBindableButton.DataBindings.Add("Enabled", myPresenter, "CanDoSomething");