I was reading a post by Perci Reyes (spanish link) inspired by a Coding Horror post about understanding code. After reading it and all related links (Joel's thoughts and Peter Hallam's post) I have something to add that it seems nobody thought about...

I agree we all of the authors about the current developer's activities statistics... and maybe it's true that we spend a lot of time trying to understand code. By default, programmers are so narcissist that they need to feel they created something, so they are prone to change anything they don't understand to a more suitable and personal solution, under their point of view. Everybody seems to argue about this narcissism and programmers willing to rewrite instead of understanding but I have some doubts about it being a programmer's problem instead of a code problem...

I mean... is the code too complex to understand it? Maybe it is. I've personally seen thousand of lines of code impossible to read and understand because the chosen architecture, data or business layers, presentation model or even UI layer where poorly and improperly designed, or even not present at all. That adds lot of complexity, but you should agree it's not related to the programmer modifying that code. It's related to the code itself. That code was once written by a developer that thought it was the best solution to the business problem (or maybe it was the best suitable solution possible that could be written with the project, developer and solution constraints present at that time; or maybe related to a lack of experience or knowledge in the side of the developer on how to write that code)

I guess that if a team of peers are developing a solution they do it the best way they can, using known patterns, decoupling code and user interface, and refactoring classes and methods. Following some simple rules you should be unable to find something like a 400 lines method or a class with only one method and 2000 lines of code. And I swear this kind of code exists, I've seen it lot of times.

In that case I would obviously replace and rewrite the smelly code. Not because I prefer it my way, just because it's so poorly designed that it will drive us mad while developing the solution; but most important, it will frustrate working hours of future developers maintaining that code.

So, my point about all that thread of posts was simply to include that developer's are narcissist but they are also able to read understandable code. The problem is introduce by poorly designed software, that actually is pretty common to find anywhere. We need to have in mind that any software we develop will hit production sometime, and it will be supported by a team of developers (maybe not the same team who wrote it) that will need to understand it.

So, my personal advice is (and this is what I actually do when I wrote code in a project) that every developer out there should write the code the best way possible but always making it perfectly readable and understandable. The code must talk by itself, not through the use of code comments, and you should refactor and simplify it until you get something readable and understandable by mere humans. It's not that hard. There are lot of practices to achieve this goal and it will also, under my point of view, make you a better developer; but my favorite statement about this is:

"if you feel the need to add a comment, just refactor your code so it the comment seems superfluous; this way your code will be simpler and easier to understand"

It was time to get a Commerce Server version up to nowadays technologies. This was my first thought a while ago when listening to Ryan Donovan, Product Unit Manager for Commerce Server 2007.

In the past I had the chance (or bad luck) to deal with Commerce Server, and I was missing a lot of features. In last version, the migrated most of the code and content to ASP.NET but it still required all the classic COM componentes used in previous versions. This has completely changed. Finally.

The actual model is completely developed over ASP.NET 2.0 and on top of it you can find the object model (catalogs, orders, etc...) presented by Commerce Server... there is a new extensibility layer over all those components exposed with web services and a new .NET API that supports all the managing and updating content options.

The most interesting part seems to be the integration of web controls inside ASP.NET that allow to develop e-commerce site dragging and dropping ASP.NET 2.0 templated controls. This was impossible until now. There are more new features like virtual catalogs, integration with Biztalk 2006, support for Membership, Themes and Masterpages, integration with Sharepoint 2007 and support for Active Directory Federation Services (more to come about this)

The Agile note of this presentation was: “The included Starter Site includes a complete set of unit tests“ .. Than you. Really.

There's nothing new in Test Driven Development. We all should perfectly know by now what it means. It's the process of developing a feature of a project driven by unit tests -  period. That should be all. There are slight variations in the process among TDD practitioners. The most commonly used is the Red-Green-Refactor. It's repeated lot of times in the development cycle of each feature (user story).

I've been actively working with TDD during the last 2/3 years using open-source tools, like NUnit. But this practice has been around much much longer. To the vast majority of .NET developers out there it simply didn't existed till Microsoft released Visual Studio Team System and a new option appeared in their Visual Studio main menu. So now, it's popular and famous. And this is good!

Team System has a comprehensive set of tools that help to create unit tests in our projects. They are not perfect yet, it's version 1.0, but they will improve. Sure. But there's one option that really makes me feel scared. An alternative to TDD directly from the Microsoft labs that most of those developers (the unit testing newbies) are using a lot. It's the automatic Unit Test Generation tool.

If we use that option, then there's no benefit in the "design" side of the code. It promotes the following behavior:

1. Create your code the way you are used to
2. Generate automatic unit tests for your code
3. Review the generated tests
4. Check your Code Coverage
5. You are done

It doesn't promotes the Red-Green-Refactor pattern. It just promotes the creation of unit tests but I personally think it doesn't improve quality of the code as "code"... maybe a slight increase of performance is shown in runtime and bug detection (this is the magic of regression testing with unit tests) ... but the most important to me: It doesn't change developers mind into a test driven design of objects. So, no design will emerge from unit testing.

:(

I'm sad to see how people is using this feature. The worst thing is that they think they've improved their development cycle, but I'm not sure if they really did.

Why do the Team System team included this feature? Is there any obvious reason that I'm unable to see?

Phewww... once again a long time without any post, but that doesn't means I've been completely idle. I recently moved to new projects because the previous work at Adecco has been finished. But the most important thing is that I also changed my role a bit, so now I'm doing some different kind of stuff in my daily work.

At Ilitia, our bosses decided to open a new business line based on a recommendation I did some weeks ago, a kind of experiment that I'm now responsible for. The new business line is focused on advanced development training to customers interested in new methodologies included in Visual Studio 2005 or Agile environments. Our approach is based on workshops and hands-on labs that are used to build training offerings to our customers. I will be posting more detailed info about this during the next weeks, with information about the available workshops.

As far as it concerns me, I will be travelling over the next 6 weeks to visit 4 different clients and deliver our first training offerings. The offerings I'll be delivering include Visual Studio Team System, Continuous Integration, Test Driven Development and Team Based Development some of them both in Java and .NET...

This afternoon we will held the February meeting of Madrid .NET User Group. I'll be there with Tomas talking about how to set up a Continuous Integration environment for .NET projects... It will start at 19.00 and end around 21.00, if you are nearby don't hesitate to pass and visit us!

We have prepared a guide of the most useful tools and how to integrate all of them in Cruise Control .NET to provide a really agile and immediate feedback environment.  The tools included: Cruise Control .NET, NAnt, NUnit, NCover, VIL, SourceBrowse, FxCop, NDepend, Simian and NDoc. Everything will be eminently practical, setting up a real environment, with all those features. So expect an afternoon full of xml configs, nant tasks and compilations.

We all can become better developers. I've been thinking about some tips that would be helpful to accomplish our daily task with increased quality, performance and productivity. I apply them and they seem to work. Some of them may sound obvious, just applied common sense, and maybe similar to some of the eXtreme Programming principles.

1. Do the simplest code possible 
Do the simplest solution, even if it seems so stupid that you won't feel like doing it. If you do the simplest it will provide you with a better maintainability and readability of your code. 

2. Use the simplest technology
Do not try to research a new technology to solve your problem. Use the simplest one you know of. It would be better for you and your team, don't over-architecture your code just to have more of a fashionable environment.

3. Focus on your actual task
Do focus on your current issue. Do not think about possible issues that may appear in the future and of course, do not write code for those possible issues. You only know what's actually happening, so focus on that.

4. Do not write temporary code or it will last forever
If you know how to solve something the right way,just do it. Do not write temporary code to solve it, instead of the real solution. There is a very high risk of keeping that temporary code forever in your app.

5. Invest time to think about the best technology and approach to use
Think. Think. Think. Think about what you know, possible technologies, possible approaches to the problem. Talk to those who are most familiar with the problem and technology and ask for their opinions. Once you have it as clear as water, go and implement your code.

6. Apply design patterns and good OOP principles
There are proven solutions for known problems, why not apply them?? Don't reinvent the wheel, just use Design Patterns and apply good principles of Object Oriented Programming.

7. Write semantic code
Your code must talk by itself. Try to not over comment your code, and make your code as simple as possible, to be followed by anyone without having to read any documentation. 

8. Do not be afraid of saying "I don't know"
We can't know everything. If you don't know how to solve a problem, just say it. Talk to your peers about it and they may help you to solve your issue. You won't be worse than others if you don't know how to code every algorithm available - we are developers, not memory chips.

What you think? Are they useful? Any tips missing?

We are currently reaching the final milestone in our client. We've met all the deadlines in fashionable good time; so, now we have entered in this new phase where quality is the main goal. But, why now? Wouldn't it be easier to control quality during the whole development process? Sure. Yes.

During the last year, I've been working in a team that shares a complicated mission: create a really complex web application using ASP.NET where graphic design and usability wasn't a requirement or a goal to accomplish, neither to improve. We just had to revamp a legacy application created in ASP and Javascript to the brand-new and powerful .NET platform, using services as Biztalk 2004 to define the enterprise workflows... There was no functional design, just old C++ code where we can have a look to directly infer its purpose to the new dotnetted code.

I guess that the original purpose of the software re-architecture was related more to performance or scalability rather than to usability or a better user experience. But, if the client wants to persist its old-fashioned ASP page behavior and design why move to ASP.NET? It's a complete different model. It can't simulate exactly the same user experience.

Nevertheless, we did it anyway. It was Product Team decision. It has to be done exactly that way. So we did it. And we are finishing now.

Most of the test cases that the Q&A team have created iterate over the application functionality through a tedious manual process to check if everything is working correctly (correctly is defined as "exactly the same results as the legacy application") ... and consequently, most of the current bugs are derived from the UI.

I've been in charge of all the controls' architecture. I've designed and coded almost every control in the application; custom controls add specific behavior that mimics the legacy application, and increase developers productivity by abstracting them to a set of properties that can be used to produce that mirror application. But, if we've changed every control, added some AJAX functionality, and created a whole sea of javascript code... How can we now test all this UI to check that it's correct??

It's a pain. It's dangerous. It's almost impossible to do it automatically because everything changes in every postback.

Common UI test framework didn't worked at all... In example, NUnitASP works perfectly for simple sites and controls, but we cannot test our pages because custom controls, UIP, Biztalk, WebServices and WSE are included in the package. I've even thought about writing a custom UI tester, something that could be integrated into our Cruise Control.

The best tool the Q&A team is using to automate this process is Mercury's LoadRunner, but it's a pain to rewrite every script when we change anything in any page.

My conclusion, and my advice, is that it's better to design software with testing and quality in mind. It's better to assure quality while you create new software than try to do it as an static phase of the development process... Quality and testing should be present in all the iterations of your project, whatever methodology you use (we've been scruming) it should be agile enough to provide you with the stats and quality that your product managers need. So if you plan to test the UI, please, design your pages to be testable. It would save an incredible amount of time. Talk to your managers, tell them about the testing and quality importance.

Unit testing has been widely adopted thanks to TDD and agile processes... but UI testing is not so easy to adopt, that's the reason why it should be included as early as possible in your applications in case you really need to test it and unit testing of your business logic is not enough.

Interesting related readings :
Don't make me think (2nd Edition), 2005, Steve Krug
Designing Web Usability: The Practice of Simplicity, 1999, Jakob Nielsen
Web ReDesign 2.0: Workflow that Works, 2004, Kelly Goto

Testing processes for the UI:
NUnitASP Testing Framework for ASP.NET Applications
Lightweight UI Test Automation for ASP.NET Web Apps @ MSDN Magazine (April 2005)
Unit testing of ASP.NET Pages, Base Classes and Controls by Scott Hanselman
Integrated ASP.NET Web Application Testing with NUnit, Ruby and Watir by Travis Illig @ CodeProject
Testing ASP.NET Applications with NUnitASP and NUnit @ The Server Side

NOTE: Please, update your subscription to use the new feed at feedburner: http://feeds.feedburner.com/migueljimenez

I was updating my self reading and reading what's been up in the scene, and I ended up in a post by Peter Provost telling how he use to play (yepp, play play) when doing pair programming during his daily work. Worth reading and quite funny.

Have a look to it at http://agileprogrammer.com/geeknoise/archive/2005/08/29/7377.aspx

Last Tuesday I switched to a new project @ Adecco. I've spend all the week installing the new development environment, reading documentation, requirements, use cases, etc...

The project seems quite interesting from the technological point of view; it's a composite system with ASP.NET, Web Services, Oracle, Biztalk 2004 and a legacy application that we must integrate within the whole thing. I was a bit scared with this project, because after 1.5 years working on agile/xp projects I didn't really wanted to go back to a "normal managed" project; luckily this wasn't the case, and I'll continue working with Agile methodologies, because they use a Scrum variant to manage the project and test driven development with continuous integration (with nunit, nant and cruisecontrol) on the development area.

Browsing the code and tests, I've realized that they have a very smart way to perform unit testing of Biztalk 2004 orchestrations with a home-made biztalk-testing-framework relaying on a custom adapter. And, also on the Biztalk side, they've created good nAnt scripts to perform deployment and undeployment of orchestrations, ports and services.

On the dark side, I'm sad to see that I can't fully trust the unit tests they've developed; a lot of the developers where completely newbies with TDD and there is no consistence between the tests created and the real tests needed. There is such a lack of good unit tests that the whole thing has been removed from the build script used within CruiseControl, so there is no risk to break a build if any test fail... but... heyyy'ya... wasn't that the purpose of unit testing? I guess I should provide some kind of advice to the new developers on how to perform tests and what should be tested; and of course, one of my firsts "real" tasks is to help repair the unit tests (lot of them are caused by null types and the lack of nullable types prior to whidbey) so they can be included in the build process (yeaahhhh, i'm loving it)

I've been reading Mike Roberts' series of posts about How to Setup a .NET Development Tree and in the last project I worked we created a very very very similar tree to host the whole project. This seemed to be the most useful way to achieve a perfect development tree:

• Create the folder that contains the whole project (same as Mike's)
• Create a separate folder for each kind of file that will be stored in the project (src for source files, docs for documents and design files, etc..)
• Create a solution in the root folder of the source files, and a folder for each project included in our solution (same as Mike's with the same VS.NET problems... This solution is also much better for performance using Subversion and PushOK or Ankhsvn)
• Create a separate project for Unit Tests projects (same as Mike's, but we had a separate test project for each project)
• Create a separate folder for third party references and tools within the root project folder and include nant and nunit there (same as Mike's)
• Create web projects as Class Libraries and modify VS.NET schemas to support web items in Class Libraries (this is much better to follow Mike's approach and avoid IIS conflicts with folders and Inetpub)
• Automated the build process with nant and created folders to hold the current build and archives of each build under the project root (not included in Mike's approach, but sure he's doing it this way)

This seems to be a pragmatic way to create a development tree, and I agree with this way of creating it. When I joined the project, Rido asked me for my opinions about the project tree and I guess I never told him that it was amazingly easy to use and install, but it was. We had only one issue and was that the project root must reside in an specified folder in drive D: (this is not a problem unless you don't have a D: drive, like me :) .. and even if you manage to create one with subst it will fail sometimes with web projects because IIS doesn't allow subst drives to be used as home folder of sites)

Mike's has also created a small console tool called Tree Surgeon that helps you in creating this development trees. I've tested it and it's fairly simple and in a very early stage to be really useful, but it can become a powerful tool that helps you in creating a development tree...

Anyway, I don't really like command line tools for the purpose of creating a development tree because it's a very visual task, and I would prefer to have a visual tool where I can specify all the options I need and perform the necessary tasks to create a development environment for me. If I feel brilliant enough about this idea maybe I'll try to create one.