Wednesday, August 26, 2009

The Coding Architect vs the Astronaut one

I just read a post from Shawn Neal about the difference between a coding architect and a non coding architect (NCA). Read it on If I call you a Software Architect, its an insult.

Basically he talks about the "architect" that doesn't code, hes call him an "astronaut architect". He lives too far from the ground and adds no value to the software itself, and only produces Powerpoints and fancy words. Its interesting, and please "no pun intended", really. If you are a NCA, maybe you may wanna check the article so you can examine your role.

IMHO, if you are a technical lead (or a XP coach), you must not leave the sofware coding entirely. Yes, you may think in how to improve your development process and other high level stuff, but I think its important to code. On my daily job, I dont usually code as my daily tasks, but I'm always reading code from others and staying up to date on the technology for improving the way we do things. So, I speaking to myself too: If the tech lead stops programming, he loses the contact with the "real wold" and that is not good.

So, I dont want to be an astronaut, I want to enjoy making useful software and helping others enjoy it too... And you? Do you like writing software?

Monday, August 24, 2009

Is Agile more work? Brief agile explanation

Hi, I just wanted to share an article I just read from Robert Martin. It explains how does an agile team working looks like and how traditional pains (integration hell, bugs, messy code, etc) are avoided.

Thursday, August 20, 2009

SINPE and the Web Client Software Factory

A few days ago, I read that the Microsoft Patterns and Practices (PnP) group is working on a new release for the Web Client Software Factory (WCSF). As some of you know, I work on Central Bank of Costa Rica in the development of the National Payments System (SINPE). We are using the WCSF and I wrote a post for the PnP group to know that we appreciate their work and are interested in knowing about their new releases.

I tried to explain a little bit of how we use the WCSF. The post is on, and if you want to read it, it says:
Hi. I read you are building a list of customers using WCSF. Well, I'm writing on behalf of the National Payments System (SINPE) of Costa Rica (Central America).This system is developed by the Central Bank of Costa Rica ( SINPE offers more than 40 applications (services) and has more than 1500 users, being one of the most important systems of our country.
Currently, SINPE is a Windows Client Application that uses .NET Remoting for client-server communication, but we are developing a number of new finantial services for a new web portal built using the WCSF. This web portal will offer several new finantial services for the people of Costa Rica. Each service is built as a module in the WCSF and operates under a common Framework using EntLib 4.
This new web portal will be publicly accesible thought the Internet (, and we are also building a portal for finantial institutions in Costa Rica that will operate on our extranet.These composite websites are planned to be released on late September, 2009.
As you can see, we use the WCSF extensively and are very interested in knowing more about the roadmap of the WCSF, specially on using EntLib 5.
On my personal behalf, I'd like to see the next features on the new release of WCSF:
- Integration of ASP.NET MVC
- Using of Unity for Dependency Injection
- Integration with EntLib 5
Thanks for your work, PnP team!

Tuesday, August 18, 2009

How to perform an unattended install of Visual Studio 2008

This file explains all about how to perform an unattended install of Visual Studio 2008

Want a summary? This is my 3 step guide. Hope it helps!

1. Create a INI file that contains the configuration you desire with this command:
Run the setup UI and at the end you'll get a "Save settings button".

2. Then, modify the INI FILE this way:
Locate and remove "gfn_mid windows installer 3.1" lines in [PreInstallOrder], [InstallOrder], and [PostInstallOrder] sections of the file.
3. Run the unattended installation:
[VISUAL STUDIO SETUP FORLDER]\setup\Setup.exe /unattendfile [PATH TO INI FILE]
Also, important to know:
Visual Studio Log File Locations

The following log files are generated during Visual Studio 2008 setup:

* dd_error__90.txt
* dd_install__90.txt
* VSMsiLog****.txt (where * is a randomly-generated suffix)

During Visual Studio setup , the log files are located in the %temp% directory. For example:

C:\Documents and Settings\[User Name]\Local Settings\Temp

After Visual Studio installation , the log files are located in the Logs directory in the path that Visual Studio is installed. For example:

C:\Program Files\Microsoft Visual Studio 9\[Product Name]\Logs

After a Visual Studio failed installation or removal, the log files are left in the %temp% directory.

Sunday, August 16, 2009

Oh no, a long method... again...

A few days ago, a fellow coworker asked me to help her in fixing some "legacy unit tests". I'll explain why I call them "legacy", eventhough the code they test is relatively new.

The first test method "TestMethodX" tested MethodX that is located on a Presenter class (we use the Model-view-presenter pattern). We ran it and failed. Ok, lets try to fix it:

1. Following good design principles on the ModelViewPresenter pattern, your method should have just one responsibility so it has only one reason to change. TestMethodX was long, had a lot of data initialization and used Mock classes in a very confusing way. There were lots of repeated statements and wasn't self documented (or had any code comments whatsoever).

2. On an Object Programming style, you should assign responsabilities to different objects instead of having a large procedural method. The way, your design is loosely coupled and highly cohesive. That's a good thing. But MethodX was very long. It used the View class on strange ways and had lots of ifs, whiles and calls to other private methods. When you try to test such a method, I assure you you'll have a hard time understanding it. It's not fun.

Long methods are evil on several grounds:
  • They're hard to understand
  • They're hard to change
  • They're hard to reuse
  • They're hard to test
  • They have low cohesion
  • They may have high coupling
  • They ten to be overly complex
Often programmers ask, how "long" is a long method? A method is too long if
  • you have to scroll down to look at the complete method
  • it takes several minutes to understand
  • you can't easily write an automated test for it
  • you can't state the one prominent purpose for the method
3. The method wasn't developed on a TDD style for sure. TDD leads to simple design and promotes clear cohesive code. So, the programmer that did the tests, obviuously did them afterwards and just as a formalism. The final result was some test code that didn't add any value to the development process and to the product itself. Honestly, the original developer wasted his time doing that tests.

After reading the unit test and the tested code, we had two options:

1. To make the unit test pass and have it constantly verifying a confusing designed class.
2. To delete the unit test and just face the truth that the tested method should be redesigned.

At the end, we decided to delete the unit test cause its existence added no value at all. I'd really like to undeline the concept that Unit tests are a strong resource for helping in your design. The enfasis shouldn't be on Test, but on Design. They are not just a formalism, they are useful and the final result is great code. That's what we are talking about.

So, if you are a developer, please give it a try to TDD, write code in responde to a unit test. Test first, test early. Make small methods and write human readable code. We, the rest of the world, would really apreciate it! :-)

Wednesday, August 12, 2009

Stop writing bugs...

I read somewhere that the best way to solve bugs in our software is to avoid introducing them in the first place.

Too obvious?

Well, if you think about it, the one responsible for writing a bug is the programmer itself. Software doesn't breed bugs by itself. Humans put them there, and humans suffer the consequences: ugly code, broken builds, unhappy users, stressed programmers.

So, IMHO, the best way for avoiding bugs is to do TDD... In Test Driven Development, you write software according to a specific automated requeriment (unit test) and nothing more. Your design becomes more cohesive, simple and mantainable. I love automation, so I've always liked the idea of having code verifying code. I remember the first time I used JUnit (2000? maybe). Wow, the simple example of automating the tests of a calculator java class made me realize that there was more to writing software than just compiling and nice screens.

TDD is about automated requirements, good design, cool automation and fewer bugs. If you like the idea, maybe you can benefit from How to write good tests. Top 5 considerations to build software without defects. Oh! And if you can, please read James Shore The Art of Agile Development. Its really good in showing the big picture of what software development is about and how eXtreme Programming can help.

Saturday, August 8, 2009

Why do we still do it the waterwall way?

Everybody knows that the waterfall way of developing software is very risky. You spend a lot of time writing requierements documents, and then a lot of time programming, and then you get a lot of software to a testing phase... and then you show a lot of software to your users...

In many cases, that leads to a lot of misunderstandings on the requiremetns documents, a lot of bugs in your software and unsattisfied users 'cause they got something they didn't ask for.

I just want to ask myself and maybe make you think about it. Maybe it works for you! Maybe not, and your current stress tells you that. Alberto Gutierrez says on this post:
Waterfall only works if you follow all of its steps and if you don’t make any change to the specifications when you start coding, when a waterfall project fails, most of the times is not because waterfall is wrong but because waterfall doesn’t adapt to the type of software they want to build, Waterfall doesn’t work with software that evolves while it’s been built.
Maybe you only develop this type of projects: everything is sequential and there's never surprises on the way. Most of us don't. So, maybe you'll like to read a little more and examine how are you developing software... as an engineering process or as a craftmanship? Check

Just one final thought: "Waterfall" is called that way because rivers never flow backwards... contrary to softwre development.

Thanks for reading!

Tuesday, August 4, 2009

Don't you love Continuous Integration?

Done right, Continuous integration (CI) can make your software development efforts to be more fun and enjoyable. Some bassic thought we should keep in mind about it:

  • Avoid any guess work by using an authoritative version control repository. Don't leave anything to the mind of any person. They may not be with us tomorrow.
  • Stop doing tedious tasks manually (stop wasting time)... Instead, automate, automate and automate all you can. Automate compilating, testing, code inspections and installers creation.
  • Think in deploy since the first day.
  • Be sure to have trustworthy and frequent feedback about your code base.
But also! Don't forget the human touch of manual testing. After all the code has being compiled, tested, inspected and deployed automatically, use the software as a real user will do. Check the layout, images and the stuff that real users will pay attention to.

I've being reading a lot about CI lately, so, I just wanted to make a brief about what I should keep in mind while designing a new CI environment.

Finally, you may want to take a look at this funny but clear video about CI. Got any comments?