difference between architect and developer

As we see things, an architect is, among other things, a better and more experienced developer. We don’t believe there’s value in having architects who just speak in UML and Visio and leave any implementation details to developers. At least, we’ve never found it easy to work with these people when we’ve crossed paths with them. 

Dino Esposito & Andrea Saltarello in “Microsoft .Net Architecting Applications for the Enterprise”

I am a big believer on "an architect is a better and more expereicned developer”. but what characteristics separate an architect from his fellow experienced developers? 

an experienced developer know how, and an architect know why besides know how.

in my working experience I came across an “architect”, for the convenience of writing, let’s call him G, G knows how to do lots of stuff, among all he knows, he is a big fan of “Software factory”. the other buzz words often seen in his writing are “unit test, dependency injection, architecture governance, spec catalogs …” he favors code generation over well designed code using inheritance, abstraction, encapsulation and polymorphism. let alone SOLID principles. with him as the “lead Architect” the technologies were implemented into the system. but those technologies did not deliver the timeline he promised, the project overrun original timeline more than 100%.  there is nearly no unit cases in the codebase as he promised when he introduced “Dependency Injection’. the last time I checked was the project is close to be aborted by the client and his last technic he deployed was “blame the developers” 

an experienced developer might know how to implement dependency injection using Unity or Ninject, but he might not know when to use it to deliver business value. an qualified architect should know. 

an experienced developer might know how to implement spec catalog, but he might not know what kind of code the factory should generate. a qualified architect should know.

An experienced developer knows how to implement the techniques  and an architect knows how to drive to those technical decisions based the requirement.

in my working experience I came across an lead developer, for convenience of writing, let’s call him J, I wanted to develop J's architect skills, so in a small project I position myself as “Product owner” and position J as the “architect”. In this setting, I make requirement related decisions and he makes architecture decisions.  this is what happened during the project:

while there is a developer working on database schema,  J decided to ask another developer to work on Entity Framework using “Code First” pattern.

when the database developer changed the database model based on UX design instead of entity relationship, asking him reviewed the new database model and his response is “it looks good” before even reading the requirement document.

on the other end, he instructed the team to implement Unity  for dependency Injection, without knowing what requirement it is address to.

this reminded me what Dino and Andrea said about what an architect does in their book “Architecting Applications for the Enterprise”. 

• Acknowledging the Requirements
• Breaking down the system
• Identifying and Evaluating Technologies 
• Formulating Specifications 

Among 4 major responsibilities of an architect, number one of them is acknowledging the requirement.  all architecture decisions must be driven from requirement, functional and nonfunctional alike.  All team members, especially the architect need to read the requirement document and fully understand what they mean to the system. 

Approving data model changes without understanding the business domain entity model, is not a qualified Architect should do.
“Code First” might be a cool technology, but it needs to fit into the team structure,

“Dependency Injection” is certainly a cool technology, but implementing it without knowing what requirement it is addressing is not a cool thing to do for a qualified architect.

int.TryParse and CA1806

I have a method coded as following:

public int ConvertDirect(string input)

        {

            int result;
            int.TryParse(input, out result);
            return result;
        }

And when I ran the code analysis I got the following warning:

CA1806 Do not ignore method results
'Class1.ConvertDirect(string)' calls 'int.TryParse(string, out int)' but does not explicitly check whether the conversion succeeded. Either use the return value in a conditional statement or verify that the call site expects that the out argument will be set to the default value when the conversion fails.

I then did a google search on int.TryParse  and found that when the conversion failed, zero is output to the out parameter. And this is what I want it to do. So technically speaking, the code block at the question is doing what I want it to do. There is nothing wrong about it.

So I went to suppress it. By doing so I added an attribute to the method. The method become the following.

        [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Usage", "CA1806:DoNotIgnoreMethodResults", MessageId = "System.Int32.TryParse(System.String,System.Int32@)")]

        public int ConvertDirect(string input)

        {
            int result;
            int.TryParse(input, out result);
            return result;
        }

I felt uncomfortable about the suppression I just did.  The fact is that by doing what I am doing here, if I make another call to another function and ignore the result. Even if it could produce unintended result, it would be also suppressed as the suppression is done in the member level. But I also do not want to write more code. With that I was settled with the following code block

public int Convert(string input)

        {
            int result;
            return (int.TryParse(input, out result) ? result : 0);
        }

With I ran the code metrics, I get 3 lines for the original version and I got 2 lines for the modified version of the method. On the other side, I got 2 Cyclomatric Complexity for the modified version and only got 1 Cyclomatric Complexity for the original version of the method. But on the maintainability aspect, the modified version offers 84% in maintainability index while the original version of the method offers 81% in in maintainability index. Considering all aspects mentioned above, I am in favor of the modified version. How about you?

 public int Convert(string input)

        {

            int result;
            return (int.TryParse(input, out result) ? result : 0);
        }


Another option is to provide a extension method just do the conversation. but as the input parameter is of string type, the extension method must be made on string type. as such, the name of the method need to indicate the target type it try to parse. (TryParseToInt)  this raise another naming warning. "CA1720: Identifiers should not contain type names"

IMHO,  the best solution would be  Microsoft add a static method in int class, TryParseWithDefault or it changes the implementation of Parse so that it does not throw exception when parsing failed, instead it provide default value as output.

CA2204 in Visual Studio 2013

From this link, you will find that CA2204 Literals should be spelled correctly 

https://msdn.microsoft.com/en-us/library/bb264488.aspx 

is categorized as Usage Warning.

 

From the screen shot above, you can also find it is categorized as naming Warning 

If you did not spend much effort try to export  CA warnings into database to further process them you may not notice the discrepancy between IDE and the MSDN documentation. 

But if you plan to capture them and store them in a SQL/Server database, you may want to know this discrepancy. For me, in order to make the metrics generated from my database matches to the metrics produced by Visual Studio, in my database I set CA2204 as naming warning. 

Not a big deal, but it took me a while to figure out the root cause of the discrepancy between my database and the IDE, I thought it would be great if MS keep them align to each other.