Simplifiing NUnitForms: functional testing Windows.Forms applications

Recently, me and my team have just finished the development of a web application. There we could enjoy an extraordinary tool, called selenium (http://selenium.thoughtworks.com). Now that I come back to desktop applications, my quest is for a tool to enable TDD in the same simple and powerfull manner.

NUnitForms

In the past, our desktop applications had many benefits from using NUnitForms, an open source Windows.Forms functional testing framework. The way it works is very simple, in order to be able to simulate an action on a Windows.Forms control on a Form, NUnitForms comes with a series of wrapper classes to help.

Each standard control in System.Windows.Forms has a Tester, so for Label we have a corresponding LabelTester, for Button, ButtonTester, for TextBox, TextBoxTester and so on. Each of these testers (wrappers) make it easy for us to perform certain actions or interact with the controls, for instance we can Click a button, or type a value in a TextBox.

So if you have a very simple for like this:



where you have , two TextBox-es, a Label and a Button named: txtA, txtB, lblResult and btnCompute.

Now in order to write a simple sum test, for this form, using NUnitForms, we need to extend NUnitFormsTest and for each control we want to interact with on our form, we need to create a tester that helps us interact with that control:


public class SumFormTest:NUnitFormTest
{
private SumForm form;
private LabelTester lblResultTester;
private TextBoxTester txtATester;
private TextBoxTester txtBTester;
private ButtonTester btnComputeTester;

public override void Setup()
{
//show form
form = new SumForm();
form.Show();

//initialise testers
txtATester = new TextBoxTester("txtA");
txtBTester = new TextBoxTester("txtB");
lblResultTester = new LabelTester("lblResult");
btnComputeTester = new ButtonTester("btnCompute");
}

public override void TearDown()
{
form.Close();
}


[Test]
public void CheckOneFour()
{
txtATester.Enter("1");
txtBTester.Enter("3");

btnComputeTester.Click();
Assert.AreEqual(lblResultTester.Text,"4");
}
}



As you can see testing with NUnitForms is fairly simple.

Is this simple enough?

Now going back to web applications, there are two functional testing frameworks, that are possible the best known, for ASP.NET: selenium and NUnitAsp (http://nunitasp.sf.net ). The main difference between the two is that selenium is fit like, where you write tests as simple html tables and NUnitAsp is very similar to NUnitForms, having testers and being a strongly typed VB.NET or C# program. Between our developers and other, where I have shown both of them people tend to be more happy with Selenium. Why? The most obvious reason is that tests with selenium are much smaller, taking less time to write and thus, more maintainable. Another reason, is that with Selenium you can really see it performing the test. With NUnitAsp, you do have the advantage of speed, and you can write your own testers, but speed is very good also with Selenium.

So my idea was: Could we simplify NUnitForms? Could we make it even more appealing by being able to write less code?

With this idea in my head and with the list of selenium commands ( http://selenium.thoughtworks.com/seleniumReference.html ) I thought that my test above could be refactored as:


[TestFixture]
public class SumFormFitTest
{
private SumForm form;

[SetUp]
public void Before()
{
//show form
form = new SumForm();
form.Show();
}

[TearDown]
public void After()
{
form.Close();
}

[Test]
public void Test7()
{
NUnitFormsFit.Type(form,"txtA","3");
NUnitFormsFit.Type(form,"txtB","4");

NUnitFormsFit.Click(form,"btnCompute");
NUnitFormsFit.VerifyText(form,"lblResult","7");
}

}

Is there any reason, I should know about the testers? Couldn't I just add what I want to be done, with the form, the name of the control and maybe some arguments? Well it seems that it is possible. I just added two classes, one with some static methods that I call commands (NUnitFormsFit) like Type, Click, VerifyText, Select and a TesterFactory that can instantiate the Tester I need knowing the form it is on and it's name:


public class NUnitFormsFit
{



public static void Type(Form form, string controlName,string text)
{
TextBoxTester tester = (TextBoxTester) ControlTesterFactory.GetControlTester(controlName,form);
tester.Enter(text);
}
public static void Click(Form form, string controlName)
{
ControlTester tester = ControlTesterFactory.GetControlTester(controlName,form);
tester.Click();
}

public static void VerifyText(Form form,string controlName,string text)
{
ControlTester tester = ControlTesterFactory.GetControlTester(controlName,form);
Assert.AreEqual(text, tester.Text);
}


...


}

and:


public class ControlTesterFactory
{
public static ControlTester GetControlTester(string name, Form form)
{
ControlFinder finder = new ControlFinder(name,form);
Control control = finder.Find();

string typeName = "NUnit.Extensions.Forms."+control.GetType().Name+"Tester";

Assembly asm = Assembly.GetAssembly(typeof(ControlFinder));
Type t = asm.GetType(typeName);
ControlTester tester = (ControlTester) Activator.CreateInstance(t,new object[]{name,form});
return tester;
}
}


Only the first step ...

Some tweeks can be done like caching the testers once they have been instantiated, handling more controls with the same name , handling modal forms (which are all supported by NUnitForms, by the way) and integrating with NFit. Now how hard will it be to extend ActionFixture to enable us to simplify us to have a test like:


open || SumForm()
type || txtA || 3
type || txtB || 4
click || btnCompute
verifyText || lblResult || 7


Conclusion

Well, the code is quite simple and the extensions don't seem to be very hard to do either and I belive this can be a good step in the right direction of simplifiing NUnitForms and functional testing on Windows.Forms applications. Or maybe we will be helped by SharpRobo ( http://confluence.public.thoughtworks.org/display/SHRO/Home;jsessionid=6C4D450855CCFDC30EE0D4305D5603CE ) ?

Building better business software: the scientific methods point of view

The problem

In order to be able to build better software for our customers, we need to be able to discover are their needs and how our software could address those needs. This means applying a scientific method which involves the natural steps of: observation hypothesis and experimentation.

The first thing we need to do is observe what the client or potential client does and from that extract some hypothesis and deductions about what he is doing and see where the shortcomings might be, what his needs are. Then based on those needs analyze them and select those that can be addressed by software. Based now on this experiment by building the software, deploying it and starting with the scientific method's steps again, by observing how the software is used and whether it is useful for the client to achieve his own goal, whether the software helps the client. Again based on these observations, modify and improve the software to help the customer.

Where does software help business processes?

Let's make a short experiment and go back to the roots with software in businesses, to see when and how software can help a client's company business processes. At first most companies did everything on paper, and some of them were very efficient at doing this. A very good study about the big transition from paper based processes to software based business processes has been done by nobody else but Bill Gates in his book: Business @ the speed of thought, the book being his observation and deductions of large companies and corporations especially. The experiment and its results can be seen on NASDAQ or by looking at out computer screen, Microsoft on top everywhere.

Going to the back to withdraw (not ATM) money you see the employee there writing all your details on a withdraw form, then printing it off and maybe asking you to sign it. For performance reasons, I noticed that the amount of time spent to write all those details on a piece of paper or on the computer are about the same, so where's the benefit of using software if using it and not using it in this activity is almost the same. The benefit is in reporting. The benefit is that when you have an audit asking you what you did with the money, or you your boss is asking you how are the same for that particular item, in July this year compared to July last year, using software is infinitely faster, as this report can be given back to you in seconds instead of having days and weeks of looking trough the
piles of paper. Not to mention human error.

Information extraction more important then informatrion gathering?

After this small observation, my hypothesis is that software is beneficial in business processes mostly for getting data out, then for putting it in.

In order to be able to be organized in a business, you need to have information available to you: fast and reliable. In order to improve your business processes you need , as a customer of software to be able to observer, draw conclusions and deduct facts based on these observations and experiment in improving the business processes. So, the most critical part of the business software is the part that gives information for the people that can draw conclusions from it and be able to improve their business. So that's where the software should really point at.

I recently emphasized this in a blog entry Do we, programmers, build sellable software? in the part that says: sell to managers. These are the decision makers, so help them apply scientific methods on their businesses with your software. Help them improve their own business by giving them the relevant information they need fast.

Unfortunately a lot of software is being built and "incredibly" for me, sold, although this theory of mine is not applied. Usually the developers make the program, where the client can add data easily, and from usability point of view the reports are left behind. Now the reports are the ones that decision makers can use for their observations, and these should be standing out for them. They shouldn't have to click seven times until a report is shown. Information should be accessible very easy, because that's what they need.

Experimenting on this hypothesis

Some of the programs lately have started with the dashboard or home page concept. When the user opens the application, the most relevant information for him is being displayed with no clicks for him. An example is Microsoft Outlook, where the home page shows you your appointments and not a form where you can add a new appointment. Many websites also have this concept, so when you login as a user you're presented with a home page where relevant info is summarized and displayed for you. However I think this view is still in it's beginning, although steps are being taken in the right direction.


The idea for adding the scientific point of view to the way we can improve business
software, making it more usable and more sellable, came to me after reading in Kent Beck's book: Extreme Programming Explained: Second Edition, the chapter entitled: Taylorism and software. Kent Beck says that the first man that applied scientific methods to industrial production was Frederick Taylor. He was the first that applied the 3 steps in industrial production, calling his methods: scientific management: observation, hypothesis, experimentation. After reading this chapter, I realized that people that want to improve their business processes apply the same steps, and that our software should be adapted to this need. I reached this conclusion by applying myself the 3 scientific steps, observing how management and decision makers need to use software, drawing the conclusions that info out is more important then info-in, and experimenting in the latest programs I designed, where getting information out has a much higher priority.

Final words ...

Applying the scientific method steps, I realized that in some areas our software must help our customer apply these methods for his business and goals. I strongly believe that software must be build with a goal in our minds, and probably my conclusions about building software that helps decision makers in applying scientific methods are mostly appropiate for products being build and then sold by a software company, but maybe the domain is even larger ... this hypotesis can only be confirmed by experimentayion, isn't it? :)

Is code generation an agile technique?

Code generation friend or foe?

Usually in the agile world code generation is considered wrong. In order to be able to contradict this belief we must go to its roots.

In my opinion, code generation has two main reasons why is usually considered wrong:

1: Tools that generate uncontrollable code

Throughout the years, many IDEs and tools generated code. For the beginners and for marketing people this was the panacea but experienced developers quickly came to the conclusion, that these tools were doing more damage then good. This was usually because the generated code either underperformed, or was poorly written, generation could not be properly controlled or as soon as the application was getting more complex, the generated code was far from a solution. Debugging and changing generated code was difficult. This led to the raise and fall of CASE tools.

The only code generation tools that seem to have lasted over the years are the UI designers, although there are still disputes whether you should do the HTML 'by hand' or using a tool like Dreamweaver or FrontPage. My opinion is that probably as in most cases, the truth is somewhere between. Use the tool, but also control everything by hand.


2. People generate code before they can afford it

Sometimes, beginners start generating the code before really understanding what it must do. For instance, recently I saw a few fellow developers adopting a new ORM and found out that there is a tool that can generate the mapping xml files. They started with the tool, but as they didn't really have the knowledge to understand what should be generated, how this mapping files really work, ended up in redoing the mapping files by hand and taking everything step by step just to understand how it works.

The good

In my opinion code generation should be applied in a totally different
way, and this way is in my opinion the agile way.


Steps to use code generation as an agile technique:

STEP 1. Develop by hand and get a very good understanding of the domain and
of the code
STEP 2. If the code can be generated, then why not.

Code generation, can drastically improve the speed of a project. This is a very powerfull weapon that developers can use, but is preferable to be carefully studied before starting to shoot it. Just like any powerful weapon, if used wrong it can have devastating effects.

It is very useful in changing environments, when parts
or the code when a change is done is generated. This is especially
useful in testing user interfaces. Much code can just be regenerated,
when the interface changes, which makes maintainability much easier, and thus automating user interface tests much more friendly.

Conclusion

Because code generation, can help in changing environments, can help the speed of development I think that code generation is the big missing agile technique from any methodology. But like most agile techniques that are also very powerful should be approached with care , remembering that it does not replace coding manually , just help it and it can by no means be used in environments where the base knowledge has not been acquired yet.

List of available code generators for .NET:
http://sharptoolbox.com/Categoryb4d647ba-2494-485a-b75b-8f8f3046d3ab.aspx

Self training

In a world, where because of the globalization, there are people that don’t get a very good night sleep, the quest for efficiency is more acute then ever. In the world of software development, efficiency can be gained by two primary factors:
-reuse
-improve your developers

If for the primary, the best answer lies in front of you and comes from Microsoft, (just think about why IE couldn’t be removed for good from Windows), for the second there is still no clear and single answer.

Short “knowledge spreading” meetings

One way to improve the knowledge level, that proved very useful to us, is to have short meetings where different things, from pure technical to methodology practices, are discussed in front of a whiteboard. Agile teams, where everyone has something to offer, make this technique very beneficial, as combined with osmotic communication (See Alistair Cocburn's Crystal Clear), it is a great way to spread knowledge. When doing this kind of meetings, from the experience we have, there are a few things that need to be taken into consideration:
- meetings must have a plan of what will be discussed
- meetings must be short
- everyone can propose subjects to be discussed
- everyone has to be involved
- have a whiteboard
- make sure you really have something to talk about (ideally probably you should have one meeting every week, not less)

In any agile team, open communication must be encouraged at the maximum. This is one very good technique of doing it.

School like sessions

One problem I noticed after adopting a new technology (NHibernate – http://nhibernate.sf.net – some of us were familiar with it or other ORMs), and using it in several small web projects, was that although it was used for quite a while (two months) it was misused, as not too many things about its possibilities were known. I also felt as if with each new project and team adopting this new technology, the knowledge was weaker and all misusages from the early projects were propagated to the others. We even got to a point where a colleague told us that he doesn’t really like using it and we saw that he was reusing some badly written pieces of database layer code, from earlier projects. I saw then that the problems were not with the technology but with lack of knowledge about it.

The reason for this might be time pressure (I don’t really buy this one) or , a more plausible one, that the developers of the second project took the code from the developers that developed the first one, as “good”, as a reference of how thing with NH should be done, trusting the first team and reusing the “misused” code.

Then I decided that it is time for a new meeting looking trough the code one day, but then it stuck me: how about making a school like activity, where everyone reads about a thing, then have a small test to see what the understood from it, and if the level of understanding isn’t satisfactory re-explain everything. Said and done. I decided that at first I should make a small introduction about the most basic things in the technology for the people that haven’t used it yet, then give everyone an article/book chapter that seems very relevant when you want to explain a new technology, going deep into it, then after the reading session is over, everyone gets questionnaire, and sends back the answer to see if they understood correctly what was needed, and if they really found the hot spots in the material. After analyzing the answers, from everyone, all the answers were discussed with everyone in front of the whiteboard, to make sure that everyone understands what needs to be understood.

Is it worth it?

The results were very pleasing. For two reasons: everyone after only a short time had a good understanding of the new technology (transient/persistent/detached states, moving an object from one to another, hql, criteria api, eager/lazy fetching, associations etc) and since it is not a requirement to memorize everything , at least, when confronting a problem, the developers will know where to look for, they will have a good image of the documentation, and where to look for specific answers. I strongly believe that even if that this meeting can take a couple of hours, this time is very quickly recovered by having people know what they do and have less bugs and problems the kind we has with misusage.


Another very interesting fact, was that after two such sessions, everyone felt very happy, knowing something new, or some intimate details, making them more motivated and more keen to start working with it. It made developers happy. Remember my article about sharing the thrills?

The knowledge wiki

At the suggestion of a dear friend (which can be found in the comments), we installed a wiki. Actually it is not a wiki, but an simple CMS system, developed internally, where people can share information, and where information has something that is lacked in the first two approaches: persistence. A wiki, has the main purpose in my opinion to keep the links where people can read more, a common place for links, a common 'favourites' system and also, and most importantly, a place where the hard to find information can be shared and persisted, information like, bugs and false assumptions about new technologies, samples for different internally developed technologies or other deep things.

Whether this will be a sucess or not we will definately see, but although the system has been installed, just for a few hours, it seems to be a success, as everyone seems very interested in both reading and writing content on our wiki, and even suggestions about extending it with a forum appeared.

Some screenshots can be found at:
Wiki and Administration

I certainly hope that besides this techniques, there are others that wait to be discovered in our big goal of become better, by self training and better knowledge sharing, and that this discussion does not end here ...

Agile databases - embrace change

Ever changing databases

In a world where we have to adopt new processes to develop software in order to adapt to ever changing environements, what happens to our databases. Do our databases, keep up the rhytm with the code in changing conditions?

Although we made big progresses in 'becoming agile' we are still at the beginning although instant results were seen ever since we started. But although there are lots of materials about agile processes, about agile techniques that are focused on making agile processes work like unit testing and TDD, refactoring, continuous integration, frequent delivery, evolutionaty design etc there are few materials over the web that deal with databases in agile processes.

I would like to say that mostly we are confronting ourselves with simple databases (<=50 tables).

The questions I have are:

1. How do databases deal with changes?
2. How to develop tests that are easely maintenable in these conditions?

1. How do databases deal with changes?

After adopting a two week iteration technique, we were confrunted with many versions of a database, one every two weeks. The database was evolving and often changed. The problem is bigger if the system has gone live. You must make an update to the live database with every new version. In the first iterations of a project, usually until a 'stable' database schema is adopted, it changes a lot, but if the system doesn't go live this is a minor problem as old databases can be just dropped and rewritten. After the stable version is reached, the updates from one version to another can be done more easely with alter scripts.

From time to time the client told us they were having difficulties with the new version we just sent, as it just crashes immediately after start. We noticed that this is usually because the database scripts haven't been run and the program is the new version, but the database is old and it the application just crashes at some time. This has given us a lot of sweats and afterall,clients that came to see the new version and see it crashing remember that your software is buggy not that this has something nothing to do with you.

Versions table and update scripts

A way to deal with this was the versions table and update scripts. Each modification in the database from one version to another version is made with a script and not directly. The database also contains a Versions table the logs all these updates. This way we can know what is the current database version, when was it created , what modifications were made (a comments field) who did the script and when it was actually run. How do we know this? By simply putting an insert line into our update script that puts in this data into the versions table.

After applying this techinque we thought about putting in the application installer, a part of code that runs the update. And we did it, but new problems arrived. A client managed somehow to override a live database, although we put in a lot of messageboxes asking to confirm whatever he did. So we thought of adding a line in the configuration file of the application which says which version should the database have in order to start the program and unless the database has the right version, the program won't start. Now noone forgets to make the updates.

Automating the update script creation

This is a simple solution that seems to work well. However a problem with it is that manually creating the update scripts is taking a lot of time to do and to test. This problem brought to our attention a product, build by RedGate, that knows to generate the update script after comparing two databases. This greatly reduces the amount of work, needed to make the update scripts, we can now make them manually on a test database then with the tool generate the update script.

2. How to develop tests that are easely maintenable in these conditions?

Everyone teaches us to make our database related tests, data independent. The most used techniques are made either by having a separate database used for testing , creating the test database with data on setup and dropping it on teardown and using a rollback technique (database server rollback or using Entreprise Services). Each of these techniques have their own problems, although seem to solve the problem of making the database tests independent from the data in the database. But are they easely maintenable if the database stucture changes often?

ORMs

It seems that using ORMs makes database access code more testable and easely maintenable, as errors after a change was made is detected fast. Some ORMs even know how to generate the create, and most importantly the update scripts themselves. If you have the unit tests related to the ORM's persistent objects the errors in tests can be detected very fast, first just by compiling then by running them so that query problems are revealed. ORMs seem in my opinion more agile then other approaches as using ADO.NET connected and disconnected database access. Is this the solution for all problems? No, however they seem to embrace change more easely.

Regression query integrity tests

Whether you are using ORMs or not, when making a structure change to a database you need instant feedback to see if you broke anything. It is very important to know that at least,that all sql queries (queries/stored procedures etc) work. Not that they work ok, but that they work. It is very important to know this immediately after making the changes. So maybe one technique is to make a test suite that just verifies validity of sql queries and not functionality. I call these regression query integrity tests.

My idea is to create a list of very simple tests, that just run the queries, to see if they break or not. This can be easily run each time, a structural change in the database is done, to see if something was broken or not. Some of the code for this kind of tests can be generated. Code generation, is in my opinion the great missing piece from any agile metholodology's list of practices, as by using code generation, productivity can dramatically improve.

Conclusion

Although we develop projects that are quite simple, from a DBAs point of view, we must keep in mind that it is very important to have techniques that enable us to change the database code, just as easy as the code itself, otherwise this can rapidly become the big bottleneck of our project, that 'embrace chage'.

How much code do we reinvent? Is this productive?

The problem

Many times, we have found ourselves writing a piece of program that in a way we felt, it would have been better just to get it somewhere and discover later that it was written, the problem was adressed previously, even more professional and that we have wasted important development time on a solution that just reinvented the "cold water".

The possible causes

Well, it seems that there are more perspectives:
- background
- didn't know
- I know better

Let's take each.

Background is the cause discovered by Alistair Cockburn, in Agile Software Development. He said that we are taught in each stage in school, not to copy from other but to come up with our own solutions. This is basically a good thing ... in school, but in the business of software, we are hired to deliver software on time. Reusing is a critical thing, so many times instead of reinventing is just better to look around for existing solutions and possibly use them.

Didn't know

Most of the times, we didn't know that the problem was already discovered and adressed by someone else. So, instead of looking around , we start direcly to develop the code, come up with our unique perspective, as taught in school and mentioned earlier. This combination of the two factors above can be damaging to the project as important time is missused.

Did know, but ignored as I know better

This is probably the most damaging behaviour of all. I believe people can come up with better solutions to particular problems but what I want is to take a good look at the alternatives, before deciding that they are not usefull. Just think that the chinese empire sent out on the sea some explorers on the beginning of the XV century, which had major competitive advantages to european expolorers (They built ships 4 times the size of Columbus's). But after 4 years, they were withdrawn from the seas, thinking the "the outside world doesn't have anything to offer to China". Well, it looks as Columbus just looked a little better before deciding, doesn't it?

Don't take me for a fan of "copy/paste" programming. I am a big fan of balance. I do not want to go into the extreme of copy/paste as probably this might be the main obstacle for invention. I am a fan of balance, a fan of getting the appropiate solution for the situation, which may be either "copy/paste" or write from scratch.

Conclusion

I believe that a solution would be just to take a closer look before making the decision of writing or reusing, and this must be made publicly known to every programmer. Every programmer must know that is it allright to copy/paste, but not make a purpose out of it. Every programmers must be told about the two alternatives and incouraged to use them, as in time he will get experience and will balance this choise better and better.

Do we, programmers, build sellable software?

Sharing the thrills with the customer: the good

Programmers want customers to use their software. Some of them want to be given feedback in order to improve the software. Most programmers, want even, their customers to be thrilled by their software, if they are thrilled by it. They want their client to share this with them. This is a good thing, it makes us developers proud, knowing that the software is being used, that the customer shares our enthusiasm for a solution we thought of, doesn't it? This is good.

Sharing the thrills with the customer: the bad, the ugly

Unfortunately, programmers want more, and like any excess it ends up bad. The programmers want the client to be thrilled by their technical accomplishments, by the 'smooth' things in the solution, techincally speaking, by how ingenious the solution was developed. They want the customer to be excited that the programm works 28 times faster then another solution. This is bad and ugly. It is naive. We programmers like logical things, but this is against logic. At least at the beginning.

The customer will only be thrilled by a software if it will improve his life, if he can achieve his business goals faster. It doesn't matter if the product was ingeniously build but whether the product is an ingeniuos tool for him. He doesn't care whether it is faster 28 times faster then another technology, unless the second was slow by his standards, he doesn't care if you used n-tier , unit testing or automated builds, 'healthy' approaches or not. He only cares if he can be more efficient with his new tool, your software.

So where is the problem in sharing the thrills with the customer?

Programmers and customers are both thrilled by being good at what they do. This is the common thing. The problem is that they act in completely different areas (mostly), so 'at what they do' means completely different things. Let me give a very simple example: management likes reports about what developers do, so sometimes as a programmer you're not very happy at the end of the day to fill in a report about your activity. Well that data makes them happy, but takes time out of your programming time. They even sometimes, show you the reports very enthusiastic believing that you would share that too, but do you?

Software is a tool. Just having it doesn't make your customer happy

It's not that easy to be thrilled just by the fact that you have a tool. You'll be thrilled only by achieving a goal. If achieving this goal, involves using a tool, you will be thrilled by the action of achieving the goal and not by the fact that a tool helped you achieve it. Just having a tool or using it without meaning doean't make you happy.

Let's say that you're a mobile phone manufacturer. You want to sell your customer mobile phones. If you sell them mobile phones, they won't be thrilled by how good you phones are. They will only see their potential when they'll achieve the goal of speaking from everywhere. They will be thrilled by the fact that they can go everywhere, and still be able to be called and call anyone they like. This is the first thing they will notice, this is their goal, to be mobile and not to own a mobile phone. They won't care if it is GSM or CDMA, if it works on triband or not. Fortunately, as the time goes, they'll start realising that in order to achive their goal of mobility better, they depend on the mobile phone. Some will even notice, that it works on three frequency bands. They will see that they can be more efficient at their primarily goal by improving their tools.

Turning priority lists arround

If you have real good marketing people, you might find out that at a time, this goal changed, they care more about having powerfull mobile phones with color display, calendar, mp3 player and camera more than speaking from everywhere. People become addicted. Another example would be skiing. At first you don't care about what helps you ski but about the action of skiing.

Unfortunately, we as programmers often missunderstand the approach we need to use. We think that proirities are already changed, and we show the client how great the software is compared to another, and not how it will help him. We assume that the customer is already addicted.

Show the client not how to use your software but how your software helps him

Think about car manufacturers (and salesman), 2-3 decades ago, when they suddenly realised that there a huge new market: women. So, the salesmen turned their entire arsenal towards women. They started showing women mustangs and corvettes, impressive V8 engines, incredible horse power, the beautiful roar of the engine, how fast and powerful they are, how fast they go from 0 to 60 miles per hour, how cool the cars were.

Cool vs Chic

Well, this meant nothing to women. They didn't want cool they turned out to want 'chic'. Women had no idea what V8, 5s 0-60, 160mph, roars etc meant. The first thing they wanted was a mirror to be able to powder their noses, check the makeup, a place to put their purse?, colors to match the shoes etc. Of course, I am kidding, but I am trying to emphasize that women had completely different expectations about cars. They didn't want 'cool', they wanted 'chic'. They didn't want to show power and masculinity , but independence.

The reason behind this strory is to explain how important is to know your market. Men knew how to sell cars to men. We programmers try to sell software to clients as if they were programmers, when instead the client has completely other objectives, just like women did with cars.

Sell to managers

I noticed that many presentations of a software solutions miss their target, because instead of showing the customer representatives there, which are mostly management people how the program works for managers, how to extract the info, because this is what managers want, they show them how the application can add and save data to a database.

The managers see the purpose of a program as getting THE information needed now. This gives them what they want: power by controlling the information. If you present a software to managers, show them the manager's dashboard that displays the instant data, the main reports and not how your application puts the data in (unless they ask).

I strongly advise you to look at Google. It is so sucessfull not by being a search tool, but by giving you the info you want. Everyone feel the power of getting information instantly at Google. They sell the solution because they know that the clients don't want to search, they want to find.

Conclusion

I hope to have achived to explain you that us programmers ofter put techincal ingeniousity before customer demands, we ofter tend to tell the customer what he wants instead of letting him tell us what he wants. I believe that because of this reason we do not build sellable products, but we tend to build expressions of our egos in our software, to show the other programmers how good we are and not the customers.

The beauty of MVC (article/technology)

You can download the sources: Sources

Introduction

I have two very "dear" design/architectural patterns, that I carry around with me in all projects, technologies, boundaries. I might say "their usage should be enforced by law". Just kidding :) One of them is MVC, the other is n-tier/layered architectures, so I decided to share why I like about the first and how I explain it to my friends and coworkers.

Why should we use MVC?

I noticed that most programmers when asked why do they use a method of separating the data (model) from the user interface (view), cannot give unambiguous answers. Some would just say: because it is a good practice or ... because Martin Fowler (or the java) world recommends it. In my opinion this answer is wrong. Wrong because, a technology that is not understood can be easily misused.

So why?

In my opinion each action should, at least try, to have a goal. The goal of this separation (ui from data) is achieving the other goal of delivering the customer, useful software fast. Now let's get back to the each (as each framework, technology etc describes that using it you can deliver faster:)) and explain why.

-debugging is much easier. Firstly, because by having two files, you can watch the code easier, because it is smaller, and you get tired just from scrolling. Secondly, and more important, because you know what happens where, you can track bugs easier.

-changes can be done easier. You can change some logic without affecting the ui, or change the UI (if you're really good you can even go from web to desktop or the other way round:))

-extensions are welcome - this will bring benefits too (I am sure you can make your client pay:))

Going back to the roots

I remember when I started programming and I had to do all kings of very simple programs to solve a simple problem. Sometimes not even programs, just algorithms and pseudo-code. Nothing displaying a "hello world" MessageBox, nothing mixed with either UI of database (persistence code). Well, let's go back to that.

The simplest program I can think of is one that computes a sum, of two given numbers:

public class Sum
{
private int a = 0;
private int b = 0;
private int result = 0;

public void Compute()
{
result = a+b;
}

public int A
{
get{return this.a;}
set{this.a = value;}
}
public int B
{
get{return this.b;}
set{this.b = value;}
}
public int Result
{
get{return this.result;}
}

}

It could have been solved just be making a static method, buy I wanted to use properties. I will show you why later.

Now this is our simple program, but of course the user has to have a form of using it, so an UI is needed. Let's try a Windows.Forms approach, like this:

Screenshot

In it we will have an instance (reference) sum of Type Sum the databinding code :

this.txtA.DataBindings.Add("Text",sum,"A");
this.txtB.DataBindings.Add("Text",sum,"A");
this.txtResult.DataBindings.Add("Text",sum,"Result");

and the button is clicked:

this.sum.Compute();

Now, everything works. Just as simple I could add the UI for ASP.NET.

The controller

Now, we have exposed Sum as the model, and we have seen the view. What's the controller for?

In some cases you don't want to mix UI interface create/layout etc code with the code that actually handles the user events. You could just make a class to do that, and include there all UI logic code.

One advice, don't let the model know about the view or controller. If you really need to do something that can't be resolved through the controller or data-binding, user events that are raised by the model and captured and processed in the controller. Another advice is that you shouldn't forget that the model is in the UI layer. Make it communicate/use/encapsulate classes (datasets etc) from the business layer.

Steps in applying MVC

First listen to what the user wants in that form then you adopt one of these strategies:

1. Bottom up - code the model as if it were the simple program that I told you about, then add an interface to it
2. Top down - design the interface with the user, when he's ok about it, think about a simple program that can handle the data you send from the UI designed and be able to send the result back.

I would recommend using both, depending on the situation.

Conclusion

So the beauty of MVC in my opinion is that it allows me to see software like a game of mind again, as when I started developing, and not like something completely automatic, where you act like a machine dragging and dropping controls, datasets, adapters etc and seeing them work. MVC is one of those things in software that when applied is both beneficial technically and mentally. It is beautiful :)

The GAP between what needs to and what is

The gap applied on an agile process: who was guilty?


After being a software developer for more then 4 years, working directly and indirectly with customers, I had the opportunity in the last two months to become a software customer. This experinece was quite beneficial, and "the gap" problem is one of the things I encontered direcly.

Both I and the developer, came in and stayed troughout the project with the best intentions. But there were still missunderstandings, that we successfully overcame but I wanted to get to the bottom of them. Many times, I was very occupied at work so I didn't have the time or was too tired to be able to update specifications, answer to questions in useful time. This disrrupred the main thing affecting any good collaborative project: communication.

Having other more important things to do all day, just increased the gap and might have comporomised the entire project, even between a customer and a client with the best intentions. This was mostly my fault. And probably every customer, thinks (rightfully) that he had nothing to do with the failure, because he had more important things to do.


The closer the customer, the better the software


The customer must make a good compromise between his job and the time he can allocate the developers , to answer questions, kill ambiguity in specifications, give feedback, "steer" the development.

This lack of time, or more urgent things to do in their day to day activity, will always happen with the customers. This is the thing that must be overcome but any agilist, people that try to get the customer involved as much as possible.

Sell this to the customer. The need to be as colose as possible. The need to reorganize some activities in order to be close to you when you need him. Probably this is the hardest thing that must be sold to the customer, along with the software, if you want to embrace an agile methodology, but is well worth it. Afterall, the closer the customer, the better the software.


Conclusion


Even with motivated parties involved in a project, a gap between what must be implemented and what is implemented wil always appear. Keeping this gap, as small as possible cannot be done in a single step, and must probably begin when you first contact the client, "preparing" him that his attention will be very necessary, even though he's got a lot of other more important things to do. Then by using an iterative/incremental development process, applied with small iterations (2-4 weeks), and with frequent releases to the users, that won't let the gap grow, . After all, if you try to cover this gap after 6 months, you might not be able to do it anymore ...

The two visions about n-tier/layered systems

The best of two worlds.

The problem of ORMs has longly been reseached and debated. In order to make programs, the best proved to be OO languages. In order to persist/retrieve data the best proved to be relational databases. They are simple and more importantly fast.
Now in order for these two to work together to enable the end user to achieve his goals through better and better software, in time, two approaches have been developed: The Java world approach and the Microsoft approach.

1. The Java world approach: application servers. Everyone already knows that n-tiered/layered systems are best, especially for entreprise applications. The java world decided to let the user enjoy Java, and disregard SQL and database servers. In order to do this they developed the application servers and the EJB technology. Also, lots or ORM tools. The main concept here is that the user develops the bussiness layer, by using objects and Java in his aplication or in his application server.

2. The MS way: - CRL stored procedures. This is just showing up, and just like .NET, benefits from the Java world experience and failures. Microsoft recognized that n-tier approaches are the best, but instead of building ORM tools and application servers, they had the idea of moving the bussiness layer from the application server to the database server itself, by hosting the .NET framework into their database server and allowing developers to build the bussiness layer directly in the database server, closer to the data and independent from the UI. Suddenly, looking at ASP.NET 2.0 SQL tags, which in my opinion was not a good approach as changing one table meant changing 100 forms, makes a lot of sense. You can use the new CRL stored procedures as your middle-tier, or bussiness layer, and give one application 10 UIs.

Well, I love having concurrency on the market, so that companies are forced to come up with better and better ideas and in the end, products.

Java world , it is your turn now. Let's see your next move :)

Dan

More about CLR stored procedures at: http://msdn.microsoft.com/sql/default.aspx?pull=/library/en-us/dnsql90/html/sqlclrguidance.asp

Encourage a win-win relationship with your employer

Two way, honest and close relationships

I am one of the believers in close and honest two way relationships. This are in my view the best relations even when it comes to work and being professional. This kind of relationships must be kept between you, the employee and the employer - the company.

What is a good job in my opinion?

My opinion is that a good job is a good balance between 3 factors: material benefits,
working environement, career opportunities. I believe that to be able to evaluate how good your job is, means from time to time to give a grade for each of these factors, then sum them and divide by three. You can subdivide the three factors and make the same for each of them to obtain that factor's grade:
- material benefits - money and other material benefits
- working environement - conditions of work, relationships with
colleagues, management, your team, company policy etc -
- career opportunities

The 3 factors applied

Because, one very dear friend told me that in a blog I must come up with more of my experiences, and not only ideas, advices, todos. Following this observation, I must tell you how I came up with this way of thinking about a job. Some time ago, I realised I wasn't happy at the job I had, so like any conscius employee I started to look for the reasons of why this happens. I didn't leave instantly, but only after realising that maybe there was nothing that could be done to improve my, and my colleagues, situations.
Was this courage or cowerdness? Do I feel better now? Do they feel better now? For the last two questions the answers are yes.

What do others say?

Recently, I read a very interesting small article called "Keeping your employees happy"
. The most interesting fact about this article is that is written by an employer. They have a list of things that an employer must do that I tried to divide from my "3 factors" point of view:
- Give your employees autonomy. - working environement - motivation
- Involve your employees in decisions. - working environement - motivation
- Help your employees to grow - career opportunities
- Actively support long term career growth. - career opportunities
- Promote your best employees. - all three
- Get out of your office. - working environement
- Recognize and reward the behavior you want to see repeated. -
working environement - motivation
- Say no when you mean no. - working environement - honesty
- Pay well - material benefits

I must congratulate her for encouriging employees to honestly tell their employers about the problems they have early and honestly. About encouriging feedback. About encouraging win-win situations between employee and employer.

Two way, honest and close relationships applied

Going back to my situation I must congratulate my employer for being the way he is. Should I congratulate myself and my colleagues also for contributing to maintaining this way of relationship, of working environement? Should we rest now, that everythiing is ok. By no means, no. A good relasionship is earned hard and is it based on trust. Maintaining it requires a big effort but it is deffinately worth it.

What to do?

When you are working in a company, the company has different means of showing you what their expetations are from you, what you need to do in order for them to be happy with you. So, if your company constantly tells you or hints you what to do to make them happy, maybe it is time to remind them how to make you happy. Show them honestly your grades. Show them at least the article mentioned above, and where you feel something could be done. Don't demand, speak openly and honestly,incourage a better two way relationship with your employer.

If communication is the main factor in a project's success or failure, and it must constanly be improved. Not in quantity but in quality. One aspect of this is your relationship with your employer. Most time, you need the courage to go forward and improve this communication, not just wait for the other side to make the first step.

Help your employer have a win-win situation with you. It is not always possible, but try first, keep trying , then maybe it is time to say goodbye, if the "3 factors" test fails. Courage is a great tool, just use it right.


Dan Bunea

Estimating - an art that everyone should know?

Fortunately, I am one of those lucky enough to be able to give estimates for my work. My company is mostly based on programmers estimating the technical work, which probably is one of the best things a business can do (just like leaving business people estimating business stuff). But do we really know how to estimate how much work a particular feature will take to implement? Maybe yes in some cases and no in others, but as agilists and perfectionists I think that we must constantly look back and improve.

Ok, so how is estimating done?

The best method of estimating is explained in K.Beck’s and M.Fowler’s book: Planning Extreme Programming: “Say you’ll do as much tomorrow as you actually got done today” meaning that the best method to estimate is to use your own previous experience. If personal experience is not good enough maybe you can use a colleague’s experience or be able to find a thing in the past that was twice as big as what you need to estimate, or twice as small. But be careful , because the further you get from your own experience when it comes to estimating, the lower the precision.

What happens if the work is new? Kent Beck said in the same book mentioned above that when you do not have experience is to fake it. Make a small prototype and estimate based on that prototype.

But why it still fails?

Ok now that I have emphasized how simple is to estimate, is this enough? Why there are still very many people, very good programmers that have big differences in estimates compared to actual time. What influences us when we are estimating? One cause might be that mostly nobody looks back and cares to take a note on how much a feature took to implement and how big was the error in estimate vs actual. The second thing would be in my opinion, either people are too relaxed or too pressured to give better estimates. The third in my list of reasons is that programmers who take pride in their own work usually give estimates in ideal time considering the best possible efficiency they might have. Is this something very wrong? No, I think that in many cases, it only shows the programmers need to outdo themselves, to test their own limits. This is very beneficial in some aspects, but applied for a long time might lead to demotivation and stress as the estimates are far from the actual time, stress that is at all levels, from the customer to the other teammates and even to the one that gave the estimate, who starts losing confidence in himself.

So what should we do?

My opinion is that first people must become aware of the importance of giving not perfect but better estimates, then start doing it, just as the Chinese said that the thousand miles walk begins with the first step. Then the most important thing, like in all agile methods is to look back and improve in time.



What do you think?


Dan Bunea

hello world!

I decided to start a blog and log my adventures into the world of software development. I would like to focus my attention especially on my experiences on working methods, on good and bad practices I encountered and on ideas I got either directly then saw they were invented much earlier but I didn't know about them or on practices I read about in the great world of books, then applied them more or less sucessfully.

Dan