Mikester's Blog

More on Productivity - thoughs on TDD and CodeGen

I took a class last Saturday on Test-Driven Development (TDD)- an all day affair sponsored by the local dotnet user group.  I enjoyed it very much and learned a few things, but perhaps not as much as I hoped.  It was supposed to be very hands on.  The room was full of geeks, perhaps 100 of us, nearly all with laptops, simultaneously typing away.  At least for the morning anyway.  I was not unschooled in test-driven development and in fact, I've read quite a bit, but I have not written tests before I start coding very often.  This is of course a central tenet of test-driven development.  You don't do design or much design.  The design evolves as a result of the development and testing you do.  The design in a sense is done during development of the tests.  You come up with the perfect API in a test for code that is unwritten. In other words, if you want to write an application that calculates the time until retirement, you would figure out the API you would like to use in a test to verify correctness.  So if you want days until retirement as a result, you might envision a very elegant API that gives you this results.  It might be something like:

Person p = new Person();
p.Birthday = "7/12/1942";
int daysToRetire = p.DaysToRetirement();

Your test would then do some sort of Assert to verify that this calculated result is correct.  I actually find this aspect of inventing the perfect API to be quite useful and one that I really believe has merit.  It helps drive clean code.

The other aspect of TDD that I like is the idea that you elevate the importance of testing to the beginning of a project.  This also has a lot going for it.  It also keeps your code in a working state.  You don't go off the rails for very long.  You test often and if there are problems, you fix them right away.  I do believe this will result in higher productivity in the long run.  It may not seem so when you are doing it, but it will shave off time at the end when you are trying to figure out why something doesn't work.

Now if you've been reading what I've had to say about code generation, you may end up wondering like I am, how this all fits together - or does it?  I do not believe TDD and code generation work that well together.  You derive your design with TDD.  In Code Generation, you start out with a working model that you then use to generate code.  You must have a debugged design in CodeGen before you generate code.  If you d0n't, you can generate a lot of buggy code, which is the wrong direction to go.   We want clean code (generated quickly) that works - that is our goal.

So perhaps you can should use TDD in the development of your templates.

I see code generation in being useful in generating tests, and in fact I've used it this way.  I've taken XML data sets that contain known inputs and outputs and created unit tests this way.  It's a great use for it, but it is not TDD by definition.  In TDD, you write a test, you make it fail, then you make it pass.  This shows that the test itself is bug-free.  Then you write the code implementation and now make the test pass.  At this point, you have something very useful.   You have a test that you can run very quickly to ensure code that you've now written still works - and continues to work as that test is run over and over and over again as development proceeds.

I am making an earnest effort to workout the best practices to create software, in particular software that solves engineering problems.   I am amazed at the varied approaches in development software and it sure looks to me like there is a lot of confusion out there.  I talk to a lot of developers and we all share some common goals.  I believe this is best distilled down to quality and productivity.  We want to develop great products quickly and many say you can't do that.  I disagree with that idea.  I believe it is possible to create quality products quickly and I also believe the best methodologies will get you there.  The think I like about Code Generation is you can get quality code quickly.  You can have an awesome, well-tested model and generate volumes of code with a single click.

In traditional Quality Engineering, there was an idea at one time that quality cost money.  It took a Japanese effort that reinvented the automobile industry to change that idea once and for all.  A man named Taguchi believe that cost and quality are related, except his viewpoint was that low quality was very costly.  I believe the same is true in software and six-sigma efforts are now infiltrating the software industry as well.

As you can tell from my ramblings I am not taking a huge stand here.  This is in part due to the fact that I really haven't used TDD as it was originally conceived.  However, I do not believe it is one or the other.  I think if you are working in a domain that you don't understand that well, it may have merit to derive the design through TDD.  But if you are a seasoned developer, familiar with architecture, design patterns, etc., TDD may not be the best approach.  You may already have a great head start and TDD would just slow you down.  If you know the design and have the code generation templates, well you not only have a great start, you are really well down the road.

But so far, the best things I've gotten from TDD so far are:

1. Write tests in the beginning
2. Test frequently
3. Invent the API upfront as part of your design

Points one and two can be used regardless of whether you are a big design upfront guy or a TDD guy.  I also think the idea of inventing your own ideal API can be used very effectively in design and it will help you get clean code that works.

Code Generation and FinalBuilder

I have been bitten by the code generation bug since last summer when I read the book Coder to Developer by Mike Gunderloy.  This is an excellent book that has one chapter on code generation.  It is a very rudimentary introduction to the topic, but once I realized I could have used it to create CRUD stored procedures in seconds (rather than hours), I became very interested.  Repeat:  very interested.  I have used a few code generators that are available including CodeSmith and MyGeneration.  More recently, I've been reading Kathleen Dollard's code generation book.  Kathleen describes a technique for using XSL to generate code.  I had only messed around a little with XSL a couple of years ago and found it a bit difficult and since I didn't have an urgent requirement to use it, I put it aside with a "that's useful and I'll keep it in mind for when I really do need it."

XSL is a wonderful text manipulation language and the bright idea that Kathleen had was to use it to generate code.  I doubt the XSL/XML creators ever had this use in mind, but it is a great technology to use.  Why?  Well, you develop templates for the code you want to generate from a code sample, so the template looks somewhat like the code you will be generating.  Second, it uses XML for the meta data.  Even though XML is a bit bloated in some ways, it has to have some verbosity as it must describe the data it contains.  Since database schema are in XML form, you can generate alls sorts of things as a result.  Third, it is a language that allows loops, variables, conditionals, etc.  So it has all of the things you might need.

Generated code comes in two flavors.  There is code that is generated and never edited.  It is used as is.  Further, Next we have code that is generated but that you may need to tweak.  If you use a code generator, it must be able to tell what is sacred or hand-crafted code from the non-sacred variety (which is safe to regenerate).   One of the better ways to do this is create an MD5 hash of the file and if it's been subsequently edited, you'll know it because of the differing hash.  Such a file is considered one of those sacred, handcrafted files.

There is another aspect to code generation that is important - a guiding principle of sorts.  And that is you must be able to regenerate your code with a single click.  Enter FinalBuilder.   Two key aspects of code generation are being able to do XML/XSLT transforms.  FinalBuilder has such an action.  Furthermore, you can mark a file with an MD5 hash (also a FinalBuilder action) so your scripts will know not to overwrite a changed file.  FinalBuilder also has actions to do basic file and directory manipulations, which are also part of a code generation scripting process.   The idea of writing my own engine did not appeal much to me so I was very happy when the idea came to me to use FinalBuilder for this.

This weekend I was in crunch mode on a project and I needed to work out what was occurring with my application.  I use Raize Software's CodeSite product.  It has a custom formatter feature, that allows you to create an output window pane of data values of your choosing (e.g., properties of a class).  I don't write these often and it's always been a trade-off of time.  Now I have a template so I create an XML file of the output I want and run a script to generate the code.  It works like a charm.

I will probably write an XML generator (when I have a few spare moments) for easily creating XML files that I might need for code generation.  This would revolve around my own business needs, where there isn't already an existing data source or XML schema.   Then I can use a FinalBuilder script to use the XML and XSL templates I develop.

More on Test-Driven Development

Test-driven development or TDD is a relatively new practice and one I've only played around until recently.

The space program is always doing things for a first time.   First time in orbit, first time to leave orbit, first time to the moon, first time on the moon - you get the picture.  What is remarkable is their success rate when doing things for the first time.  When we compile a program, what is the likelihood it will compile correctly the first time?  Probably not all that impressive a statistic, but then again, nothing serious is really at stake.  But the space program has a lot at stake - human lives for starters.  So how do they do it?  I do know they do a lot of testing.  They do every conceivable test they can on the ground, in labs, in physical simulators, in computer simulators, you name it.  They have processes, with exact sequences of steps worked out.  They test these.  So when it comes time for the real thing, they've done about every conceivable test you can imagine and have essentially tested the entire system separately.  They also do not make giant steps.  Remember, it was Apollo 11 that first put men on the moon.  There were several missions prior to that.  Docking missions, go to the moon and back missions, etc.  They did one thing at a time and made sure it was safe and sound.

I look at TDD as a methodology to take baby steps with 100% certainty.  Your system nevers gets into a state of confusion because you never let it get that way.  When systems become unwieldy it is because they are in a state of confusion to greater or lesser degree.  TDD is the stable datum that tells you that your system is working - it is the green light, the go ahead that it's safe to launch.

TDD does take discipline.   This is not a negative.  It just is what it is.  What I like is you make a test fail by default and then it is your job to make it pass.  That makes sense.  You are saying it is safer to make the test fail from the start and then I have to prove it passes.  That's acknowledging that Murphy does exist and you are taking him into account.

So what are the steps to TDD?

1. Write a test.
2. Run the test. It fails to compile because the code you're trying to test doesn't even exist yet! (This is the same thing as failing.)
3. Write a bare-bones stub to make the test compile.
4. Run the test. It should fail. (If it doesn't, then the test wasn't very good.)
5. Implement the code to make the test pass.
6. Run the test. It should pass. (If it doesn't, back up one step and try again.)
7. Start over with a new test!

One part of TDD that I have not fully accepted (yet) is you write your tests before you really have a design.  I think the idea here, which I do agree with, is to determine what the test is based on the requirements - that is a good thing.  For example, if we are writing a program to calculate the boiling point of water at 300°F, well we should have a method that tests for the correct answer.  We do not need to know yet how this is implemented.  As developers, we look at testing what we have already written, but we should be testing what the user is expecting to get or see or whatever.  So in that case, a test in the absense of a design is acceptable.  However, there is a point where we do need to get more granular.  Is my list returning the correct count of items in the list.   So I think there are both types of tests that need to be written.

TDD involves doing small, baby steps - just like the space program.  It involves testing everythinng separately and thorougly, just like the space program.  It is thorough and I'll be sharing my actual, real life experiences with TDD over the next few months.

Test Driven Development

Test-driven development  (TDD) is a programming technique heavily emphasized in Extreme Programming. Essentially the technique involves writing your tests first then implementing the code to make them pass. The goal of TDD is to achieve rapid feedback and implements the "illustrate the main line" approach to constructing a program.

That is the definition that appears in Wikipedia.  I have stuided Extreme programming quite a bit but writing tests before hand has never been something that seemed that exciting to me.  I am in the middle of a project and I decided I needed to write some unit tests to augment the build process so I have some confidence the code is working well as I continue to work on it.  So I decided to use DUnit which is a testing harness for Delphi XP.  I've used it before with good success and I've managed to integrate DUnit console tests with FinalBuilder.  I like doing a build and knowing that my tests are passing. 

Well I managed to write some tests the other day that didn't pass, much to my surprise.  So here I am writing all sorts of mundane tests and I'm finding out I actually like doing it, much to my surprise!  For one thing, I found a few bugs that I may not have found for quite awhile.  Not to mention that finding them would have been done after some weird bug was found.  Finding a bug may take one minute or it may take one week.  I wasn't looking to find bugs. I was looking to write tests and when I found out they didn't pass, well I was testing at a fine enough level that it took very little time to find the source of the problem.  That's what I like about this technique.  You are testing something at a low enough level that if it doesn't pass, you'll find the bug right away.  In many respects, this is so much easier than doing it the old way and it's proactive.  You aren't waiting for a bug to bite, you're getting rid of the rascals before they can do their damage.

Well I'm sure I'll be learning a lot more but I wanted to get that much documented.

So I'm more sold on this idea of writing tests before you get very far. 

Source Control

To tell you the truth, I'm not sure of the origins of source control.  But it is a good practice with a lot of merit.  In the old days of DOS development, I would do things like backup my project whenever I started to do some new work on it.  That way, if I really messed up, I could revert to where I started from and the only thing I lost was some time.

Have you heard about people that get in the kitchen, experiment, turn out something fantastic but are never quite able to duplicate it?  They are in some ways operating without source control.  They certainly didn't document what they did which makes it virtually impossible to recreate.  But I'm sure master chefs have some sort of admin system worked out where they do experiment and have good documentation of what worked and what didn't.  That way, they can roll back to a successful recipe and have happy customers.

Source control is quite a topic for developers.  But datum number one is use source control.  Even as a solo developer, there is much to be gained.  In a team environment, it is absolutely essential.

Source control or version control or software configuration management are more or less synomyms for the same thing.   Regardless of the product, there are two basic concepts that hold true.  There is a repository, which is the vault where you source is kept.  It is not only the current version of your source, but every single version of it from when you first created it.  The other part is called the working copy and it is what a developer will have on his machine.  So right away, there are two copies of the source code, making this infinitely more valuable than the case of no source control.  If you have a team of developers, each one will have a copy on their computer, so now your source code is widely disseminated among several computers.  It is unlikely that you will ever lose much source code in this way - and we haven't even talked about backup processes.

The other thing about source control is it gives you some confidence.  You can trash your working copy completely and then just checkout again and you are set to go.  The working copy is not sacred at all.  In fact, do whatever you need to do.  When you have it working correctly, you then check in or "commit" your changes and the repository is updated with the latest bit of your work.

Having a central repository also enables you to perform regularly schedule backups.  The source is all in one place and most source control systems have an easy mechanism to backup the repository.

What do I use and why?  I am using Subversion, which is an open source product.  The price is right (free) and it seems to be very well regarded.  I did not do an exhaustive search but this product in my own test drive, did everything I figured I would ever need to do.  Also, I did not want to spend a lot of money.  I have Microsoft's Visual Source Safe (VSS) and played around with it.  But I didn't much care for some of the public experiences with it, most notably being that it is apparently very slow over a network.  In fairness to Microsoft, the source control system with Visual Studio 2005 is supposed to work well over the wire.  But there were problems at one time with repository data corruption and this is something I am not able to risk.  With all the accolades that Subversion has gotten, I figured I would at least learn it well enough to get some good experiences with it and if it didn't work for me, I could always go to something else.   It has done well for me.  Perhaps the only thing I'm not crazy about is the setup that is involved for remote access of a repository.  It seems the easiest way to do this is to use the Apache server, which I did not want to do.  But installing Apache is actually not that difficult and setting it up to run side by side with IIS is also straightforward (hint - just use different ports!).

Where should the repository go?  Well I like to put it on its own computer or own drive.  Right now, I am using a 400GB Buffalo Link Station.  This is a very smart hard drive that has a linux kernal in it and has some nice configurations for security and users.  It can be accessed by drive letter or FTP.  And using the Apache Server on a PC, you can access the repository through a web browser.  So it's pretty useful.  I can also plug in another drive to the link station through a USB connection and then backup that way or just make it a larger drive.

Source control is very useful for a lot of things besides software development.  You can version word documents, excel, anything where you want  a record of its complete history.  It's quite useful in that regards.  I use it for HTML websites, so I can version what the website looked like at various times during its history.

Anyway, use source control and improve how you do business. 

Introduction to Best Practices

In my Best Practices section, I will be discussing what I consider to be the best practices for various aspects of software development.   Some practices are not really subject to debate, having been time tested by legions of developers and companies.  Other practices are perhaps more open to debate.  I accept that.  The purpose here is to outline how I do it and hopefully, it will provide you some useful information.

Borland to sell off IDEs

Yesterday was an interesting day for Borlanders.  I have a love/hate relationship with Borland.  I feel the company really knows how to disappoint and thrill its customers.  The management disappoints.  The products excite us - usually.

The history of Borland is a fascinating one.  The first product of Borland's that I ever purchased and used was Turbo C 2.0 back in the summer of 1989.  I made a decision to learn what I needed to produce commerical products.  I discovered that most serious developers used the C programming language.   Well I am still on that quest to learn how to develop commercial products.  I had heard of Turbo Pascal some years earlier and I almost got that compiler instead, but opted for the C compiler.  I sure don't regret having done that.  It was easy to go from C to Pascal and C is the basis of so many other languages (C++, C#, Java, PHP).

I loved Borland's products.  I used their C, C++ and Pascal compilers.  I also used some of their other products such as QuattroPro and SideKick.  I loved SideKick - it was so simple and elegant and the first real kickass PIM.  It was of course a DOS program which ran as a TSR (memory resident).

Well Delphi was another product that transformed the development environment.  I have used it since the 1995 version 1.0 release.

Here was one revelation I had after having done C/C++ development.  I purchased TurboPascal for a particular project.  I learned enough Pascal to get by.  However, I was overwhelmed by the compilation speed.  It was blazingly fast and left any C/C++ compiler in the dust.  Delphi was no different.  I realized this was a superior product in so many ways.

I have developed with Delphi ever since.  I don't do C or C++ anymore.  I do use C# (which was architected by the very same Anders Heilsburg that brought us TurboPascal and Delphi).  C# is similarly elegant.  But for high performing Win32 applications, Delphi is the way to go for me.  My only concern has been the viability of Borland.  The management has done some blunderous things - monumentally blunderous in my opinion.  They price their products in a way that drives away business.  I would have enjoyed playing around with Kylix.  I saw the introductory pricing and said to myself it wasn't worth it.  We as developers were very interested.  But this was new territory and I was not interested in exploring it (hobby mode explore) at the price they wanted.  So I concentrated my efforts on doing plain vanilla Delphi programming.

I upgraded a year ago to D2005 - a disaster.  I tried using it a number of times and it lays there dormant on my machine.  It was unusable.  I also got it without SA (software assurance) because they wanted an arm and leg for the Pro Version SA at the time (they since reverted their software assurance policy).  I upgraded, gave the company hard-earned dollars for what was a worthless product in my opinion (I have lots of agreement on this one).  I can only assume that management wanted the revenue from the upgrades and pushed the product out the door before it was ready.  I have not yet upgraded to D2006 - which I hear is wonderful.  I probably will when I have time to do so.

The management had ideas where the company should go back around 1997 and they lost Anders.  Big mistake to let a guy like that go.  They've lost a lot of talent for sure by trying to be something they are not.  Now they are divesting themselves of the products that brought them the most success they have ever had.

So the big news is Borland is selling off the IDE products (Delphi, C++ Builder, etc.), which will be a separate company with the mission of turning out world class development tools.  I am thrilled at the early news about this.  Hopefully it comes to fruition.

I still get excited whenever I fire up Delphi.  It is a truly magnificient product and we all would like to see more great Delphis in the years ahead, including a 64-bit version to give it new life for years to come.

Code Generation with FinalBuilder

There was an interesting post on another site about programmer productivity and how to measure it.  There was a lot of discussion on LOC (lines of code) or KLOC (thousands of lines of code) and there was pretty good agreement that it isn't a particularly good measure.  My own opinion is measuring productivity is fundamentally very simple.  You measure and reward what you want and you can also measure and penalize what you don't.  The key is figuring out carefully what it is you want because I can guarantee you will get what you reward.  I really believe fundamentally that productivity should be measured so you can make mid-course corrections.  If you know what you just did hurt your productivity, make sure you don't do that again.  But you may never know if it went up or down unless you do measure it.  I will talk at length on this topic another day as I have a lot to say about it but for now, suffice it to say that the measure I use personally is "bug free functions."  I will elaborate in another post on what constitutes a bug-free function but I bring this up because I will be comparing my own personal productivity in the coming months against data I collected in prior years.  Since I have changed a lot of things, I expect the productivity will be much higher.  However, I am most interested in the changes I've made recently because I think I am getting HUGE gains by using code generation.

So - I talked recently about an idea I had to use a build tool (FinalBuilder) to script a code generation process.  Well I used it today for a few minutes - yes only for a few minutes.  Why you ask?  Because I was done in a few minutes!  I had actually taken a database table, generated an ORM class by reading the schema and spitting out some XML, applied a template I wrote recently (XSL) to spit out a very nice looking Delphi class.  It was a good test because it is a table with a large number of fields so there was a little bit of everything there.  I then inherited from the class I generated, added some hand-crafted code, i.e., two method calls to do some custom processing.  I was done.  What I accomplished in minutes would have taken hours.  It is also not the most fun type of programming.  It would have involved typing and cut-and-paste and a lot of silly stuff that is very error-prone.  So instead of doing that the rest of the day, I get to write about it instead - which I might add is very, very therapeutic.  Writing about it also solidifies your own understanding.  I'm sure you know exactly what I mean.

The thing about Code Gen is it is a process.  Just like building an application is a process that merits a script to drive it, so is Code Gen and FinalBuilder is perfect for the job and up to it.  I do know I'll be adding some custom actions to FinalBuilder to do some things but even that doesn't look too difficult.  What I am really enjoying is knowing what I am doing is fruitful because the gains are so apparent.  The gains are not 5% or 10%.  They may well be >1000% type gains.  If you can take a task that takes five hours and reduce it 5 minutes, well you've saved a lot of time.  If you can generate 80% of your app that way, well think about the time to market that just went down A LOT.

No matter how you measure it, I am more productive.  Yes, the computer wrote the methods.  But I wrote the software to write the methods.  So I get credit for all the lines of code, or in my case for all those bug-free functions that I just "wrote."  I don't care how you measure it, with code gen vs. the old way, you are more productive - period.  Henry Ford understood automation, economies of scale, and how vital a factor is this thing called productivity.  It should always increase - it least that is my philosophy.  Every so often, breakthroughs are made and productivity moves ahead by quantum leaps, not the baby steps that are more normal.  Code generation is a quantum type leap of productivity.

I will be measuring this very closely with a couple of applications.  I should be starting application #1 in a week or two at the latest.

Code Generation Part II

I had an interesting idea yesterday.  I have only tried this in a very cursory manner so I'm not sure how workable this is going to be.  But I think it is going to work just fine.

Here is the situation:

Code generation is a process that involves a script of some sort to drive it.  Kathleen Dollard has developed her own script engine - she calls it a harness.  I have not played with it but it is very dotnet centric, which is fine.  I love dotnet.  I also love Delphi.  There is more to CodeGen than just doing XML/XSLT transforms.  There are tasks like checking to see if code is going to be overwritten that shouldn't be, creating directory structures, doing multiple transforms one at a time, etc.  It is a scripting process.  Doing code generation for a product involves several things, but the process includes:

1. Developing XML templates
2. Developing a script to drive the generation

Part two is very much like doing a software build.  So why not use a Build tool?  That was my great idea!  So I was playing with FinalBuilder yesterday and noticed it supports XML/XSLT transforms, among a lot of other actions.  So I played with one of my scripts and got it working pretty quickly.

There's a lot more to do here.  I'm not sure I have my arms around this beast completely, but I think this is a good way to go.  Scripts in FinalBuilder are easy to create.  It's very visual, it's easy to move things around.  It's easy to execute just the steps you want, etc.

I'm also thinking that CodeGen might be part of a build process.  For example, the FinalBuilder Code generation script might be put into source control and the FinalBuilder build script would check out the project which also includes the code generation script.  It runs it and files are generated and the project is built that way.  Sounds like a very cool process and I'm sure I'll have a ton to say on it at some future point.