Fifteen to twenty years ago, FoxPro was a great end-user tool. It was great for developers, but end users could create quick and dirty applications with it. These applications solved real business problems in a short amount of time for little money. But at some point the business person realized they were in over their head and called on professional programmers to add functionality. Yes, the original program was a mess. Yes, it was often easier to start over, but the business user had gotten great use out of their creation, sometimes lasting years before they had to call in the pros. Many times these applications were ones that the business couldn’t afford to hire a pro in the first place. In the end, the use of these home-grown apps didn’t negatively affect the professional developer. In fact, I say it gave us more opportunity.

But FoxPro wasn’t the only tool used. Microsoft also had Access. FoxPro eventually morphed into Visual FoxPro and became a pure developer tool and today is no longer being updated by Microsoft. Access, on the other hand, continues to be sold. Thousands of Access applications exist in the same way thousands of FoxPro apps existed. The business user needed to solve a problem, in a hurry, with little cost. However, Access is morphing. Microsoft is pushing it to become a front-end tool for SharePoint development.

Where is the business user to go? They still need quick and dirty apps at a low cost to solve business problems. To fill this need, Microsoft created Visual Studio LightSwitch. It’s a version of Visual Studio customized for the business user. When you create applications, you use a simple designer to specify your data and screens. The VS templates handle the heavy lifting. The apps are created in Silverlight 4 and can be run locally or over the web. You can connect to different data sources and even export to Office. In reality, there is little difference between what the user can do with LightSwitch and what they’ve been doing for years with FoxPro or Access.

Since the announcment, I’ve been eagerly awaiting the release of the first Beta bits. And today was the day. And my first actual impression is not good. Originally I got compile errors on the Microsoft supplied Vision Clinic walk-through. An assembly or namespace from the generated code was missing. The reference was in the project, but I couldn’t manually modify the generated code. Fail #1.

I decided to try a different machine. I again downloaded the bits, ran the install, and started my way through Vision Clinic again. This time the compile succeeded and I was able get the first part of the application running. Success #1.

The next step instructed me to download the “PrescriptionContso” database from the “Connect” site. So, up to the Internet I went and searched the Connect site. No luck. How about code.msdn.com? Nope. CodePlex? Nope. Bing search? Nothing. Fail #2. At this point, I quit. I won’t go any further until the docs are fixed. Why not just provide a link to the download so people can find it?

I have some other observations. First, creating entities is a bit cumbersome. I have to click in the Add property field. I can’t just tab into it. Second, when you specify a datatype for the property, three of the choices are Int16, Int32, and Int64. The average business user won’t understand the difference between these and could actually choose the wrong one. I also got the properties in the wrong order. I put LastName before FirstName when creating the Entity. I couldn’t find a way to move them. Because the generator puts the properties in the order specified in the Entity, this is a problem. Finally, the walk-through has you create a couple of  things callled a “Choice List”. It’s really a pick list mechanism. The first time a Choice List is specified, you are instructed to use values 1-3. The second time it’s 0-2. No explanation as to why this is different. Again, an average business user won’t understand this. The walk-through should provide some type of explanation about what the values mean.

I understand this is Beta 1 and changes will be made, but right now, I’m stopped because the docs are not ready to go. I still have great hope for LightSwitch and see it as a valuable business tool. I just hope Microsoft at least gets the documentation fixed soon.

The most important thing to remember when working on a Brownfield project is “Context is King”. In other words, always ask yourself, “Self, why did they do things the way they did?” By asking this question, you’ll understand much about the project and how to best enhance it.

Step 1 in your process is getting an automated build going. This is the single biggest thing you can do to improve your process and improve the application without touching the code. I’ll come back to this in a moment.

Step 2 is to run automated tests. Many QA departments run automated tests, but do you have automated unit testing? You nott have any unit testing or very little or not testing the proper areas of your code. Identify the trouble areas of your code first and devise unit tests for them.

Step 3 is to get your release package inot your automated build. Creating and testing the release package should not be a manual process. There are too many things that can go wrong in a manual process. It’s too easy to miss things or even include things that should not go out to the customer. Also, make sure your install scripts and other release tools, scripts, and artifacts get put into source control.

Does your product include a database? Are you managing it well? Do you have scripts to create and alter the database schema, create stored procedures and functions, security, etc? Are those scripts in your source control? Do you have automated testing setup on those scritps?

How is your development environment setup? Do you have it virtualized so that one version of the application doesn’t interfere with another?

I assume you are using Source Code Control (SCC), but are you using it properly? Do you know all the capabilities of your SCC tool? Do you know how to do everything the SCC tool does? What about branching and merging? Is it simple? Can you do it? Does it case great pain? Is it difficult to merge code from one engineer with that of another? How often do you check in? By checking in frequently, you will reduce merge problems.

What is your automated build, or even better, are you practicing Continuous Integration (CI)? [Note: I am coauthor of the book "Continuous Integration in .NET"]. You’ll get immediate feedback on your project, which will reduce risk and help you make a better product for our customers.

If you take on a new Brownfield project, the first thing you should do is look at the build script, release management processes, etc. You’ll learn alot about how the application is built and prepared for the customer. Next you should run the tests in the code. This will show where code issues may exist. If you get lots of problems with these items, odds are you’re in trouble already on the project.

When fixing bugs, identify the pain points and devise unit tests. Look for fear in the eyes of current team members when you suggest modifying code in a particular module. This fear tells you that they don’t want to touch that code because it is very brittle and will break with the smallest of code changes. These are areas that can benefit most from unit testing.

Do you have unit tests and are your running code coverage to know that the unit tests are really testing the code efficiently?

Are you doing proper defect analysis? Things like bug counts don’t tell you much. You need to look at areas where bugs come from. Does one module get more bug reports than another? Are bug reports coming from QA or from customers. These are the things that tell you the most.

Is the application well architected? (Odds are it isn’t according to today’s standards.) When you hear about three tiers, that refers more to a physical layout. Layers is more logical. Look at Domain Driven Design to help out here as it greatly simplifes complexity.

The UI layer should use a standard UI design pattern such as Model-View-Controller (MVC), Model-View-Presenter (MVP), or Model-View-ViewModel (MVVM) in the case of Silverlight and WPF.

The business layer should be divided up into different layers itself with Services (connecting to external resources, but not data), Translators (data processors), Domain Model (business rules), and Repositories (data access/store) making up the main concerns and aspects cutting across them. For example, a logging utility, that’s needed by all the concerns. In a .NET environment look at something like Castle Windsor to make it easier to handle aspects.

What kind of data repositores are you using? Are you using a relational store, and if so, do you use some type of an Object Relational Mapper (ORM) such as the .NET Entity Framework or NHibernate? Are you calling web services? Is the data RESTful? Is the data in plain text, XML, or .ini files?

WOW! That’s alot of stuff to consider and deal with. So, how do you cut through all the chaos in your Brownfield application? You have five options:

• Horizontal layers – not very appealing from a technical standpoint.
• Module by module – not a small undertaking
• Bottom up – In this case, you start to update the data access layer and move up to the UI
• Top down – start at the UI and move down to the data access layer
• Slicing – probably the most appealing. Take one very small piece of functionality, for example, save a patient record, and rework all the code needed to do that, from UI to data access.

What about your code? Is it good? Is it DRY? Are you practicing YAGNI? How about SOLID? Do you practice Separation of Concerns? These are all techniques to make your code easier to read and maintain.

Do you use Design Patterns? Do you stay away from the Singleton pattern, that is probably the most elitist pattern in the world?

Finally, are you improving confidence that your code, and the application are good? Here are some things you can do:

• Reduce regression errors
• Make it know that what you’re doing is difficult
• Do integration tests
• Refactor your code
• Add unit tests
• Know that it’s 100% fallacy that you will ever get 100% of your code under test. And you shouldn’t care. You only need to test the things you need confidence in.
• Set your direction and know where you are going form here.
• Do code katas to improve your coding skills

If you want to know more about Brownfield development, there are two books that have very valuable information. The first, Brownfield Development in .NET, is by the guy that presented the seminar, Donald Becham. Don’t let .NET in the title scare you away if you aren’t doing .NET development. All the concepts apply, it’s the tools that are different. The second book is Working Effectively with Legacy Code by Michael Feathers.

You can survive Brownfield development. With the concepts and tools these two books present, survival may not only be easier, but you may thrive in a Brownfield application.

Our first event is the Visual Studio 2010 Community Launch, Thursday May 20 from 1-4 at the Microsoft offices in the International Center. You need to register to attend. Here’s what you need to do:

1. Go to www.utahgeekevents.com
2. Sign in or join as a member
3. Register to attend VS2010 Community Launch

We’re working on updating the rest of the web site and working on other events. Some ideas we have are SQL Saturday, Day of .NET, and Utah Fall Code Camp. We’re open to suggestions if there’s a community event you want to see. Just let us know.

Watch for Chapter 10 to come along soon.