General Software Development

This past week has been pretty darn busy, actually, so far 2007 has been pretty darn busy. At work we've been cranking away on a pretty large project built upon DotNetNuke. It's like nothing I've seen done successfully with DNN before, so it'll be interesting to see when this latest version goes public how well it does. It's rewarding, but a damn lot of work lately. I can't wait for February. I keep telling myself in February I'm going to start working on my car again,...(read more)

Like most developers, I work with other developers. Most are computer sciency and kick ass when it comes to class design and architecture. The problem with this is that this creates a UI design culture that is not always optimal.

There will always be bigger picture architectural design decisions that need to be made. So much of what we write code for doesn't even involve UI, especially since big systems are distributed and service-oriented. But when someone comes to you with something from a competitor site, and says, "I want to do this," starting somewhere deep in the application is the wrong place to go.

It's pretty easy to see the differences in the real world. Take OS X vs. Windows. I don't presume to know anything about how the development of these products really goes (except to say that Microsoft clearly sucks at it if it takes years of missed ship dates), but the end product makes it pretty obvious. Windows is driven by mountains of legacy and compatibility. OS X, on the other hand, starts with, "I want to do this, so what does the UI look like?" For example, say that you want to run a program. Windows makes you navigate a start menu that assumes too much about what you may or may not know. Try to find Excel on a friend's computer, when they try to keep their start menu "organized." Good luck with that. On OS X, I click the Spotlight icon, begin typing Excel, and there's the icon to click. The evolution of categorized portals like Yahoo to the single simple search box on Google demonstrates similar focus.

Don't get me wrong, you can get out of control. People who start building things in Photoshop or Visio are getting way too ahead of themselves. Scribble something on paper, because it's a lot faster and you won't get attached to it as easily. Start to flesh out what it is you're trying to accomplish for the user, and the fastest way to that point. Figuring out the object abstraction and data access then becomes a natural extension of delivering on that well thought out UI.

I'm going through this exercise right now at my day job (which by the way, I can't believe I've been at for a year, but that's another post). It was also the key, freeing moment for me when I started to rebuild my forum app instead of worrying about how to get my old data into it. It's amazing how much better your software can be when you focus on the task first, and the implementation later.

Or maybe 4.0? Paul Gielens got my brain jump started this morning with a post about DDD support in the C# language. Domain Driven Design can be hard to grasp and even harder to implement. Conceptually it"s easy and makes sense (at least to me). We all read the books and get the theory, but when the rubber hits the road the biggest question anyone has is "how do I write code that reflects this?". Everyone has ideas and if you take a quick search of the DDD mailing list, you"ll see dozens of code snippets all talking about the same thing but implementing it differently. Sure, software development and pattern is like that. Take any one pattern and give it to 3 people and you"ll get 5 different interpretations. However as we continue to dance around implementation, we get confused by the terms and sometimes miss the ball.

Here"s a DDD type implementation using C# constructs so the intent isn"t all that clear here:

Now given the spark that Paul mentioned, here"s the same code written in DDD style:

If you"ve read DDD and internalized Eric Evans" theory around things like aggregates, boundaries, entity and value objects you"ll get this. You"ll see the domain visually (or at least I do) and understand it. No longer would you have questions like "is x an aggregate of y and where should service z live?". The code tells all. Brilliant.

I love C# but it does have its limitations in that it"s just simply regurgitating the language it was based on and has typical constructs like class, namespace, etc. I"m sure (but haven"t thought how you could do it) that say a language like maybe Ruby could support this but that"s an answer for those smart types like John Lam to answer (although with John at the mothership now and working on the CLR team, anything is possible).

I think it"s an excellent idea, my only wish is that something like this could come true someday!

Last week I had the privilege to spend 5 days in Arosa, Switzerland, among a group of people who were way more smarter than I am, for the annual Software Architecture Workshop (SAW). The SAW in Europe is an initiative of Jimmy Nilsson, and uses the Open Spaces methodology to let the participants discuss all kinds of topics during a set of parallel tracks. This year, the organization was done by Beat Schwegler of Microsoft. From the Netherlands, Paul Gielens, Arjen Poutsma (of Spring framework fame) and myself were present. The SAW is an invite only event.

What was so great about the event was that all 40 participants were considered equal and everyone was able to setup a session about a topic (related to software architecture of course) in the slots on the parallel tracks. It was a blast, I can tell you. Not only was it great to finally meet Jimmy Nilsson, Mats Helander, Sebastian Ros and others in person but the event itself was awesome as well, with every session giving you a big set of ideas, insights and visions on new directions in software architecture and software engineering. Because a lot of the participants (I think 25-30 people of the 40 people participating) were Java oriented architects, as a .NET software engineer I learned a lot of new insights in how things are done on other side of the fence and also how they look at how software should be archtectured.

Mats Helander describes on his weblog one of the sessions, which was about O/R mapping. The participants who were working on O/R mapper frameworks agreed on the fact that it"s not about O/R mapping anymore, it"s about managing domain objects/entities in a complete system. Mats explains it better than I do so please pay his article a visit .

So what did we discuss, which topics were hot? Of course TDD/Agile, however this year DSL"s were the core topic in many sessions. It"s amazing how much you can do with them and how little current technology actually lets you use them and combine them at full power. Other topics were Behavior Driven Development (BDD) presented by Dan North, Event Driven Architecture, code generation, Service Oriented Architecture, REST, Aspect Oriented Programming, Visualization of metrics related to the state of the software, Domain Driven Design and many more.

Eye openers, an example
One of the things that really made me sit there thinking how I could have been so stupid all these years was a session initiated by Dr. Kresten Krab Thorup, about Performance Metrics, what to accept as the "acceptable 0-level" and how to measure these performance metrics during software development and after deployment. What was so great about Kresten"s approach was that he had build a framework (using AOP) into the actual enterprise application so at any given moment fine grained call graphs, performance metrics for every call etc. (think in the graphs you obtain from a profiler). could be obtained from a live running system. The idea is that a big service consuming applications are only truly "done" when they"re deployed which means that any measurement of performance before that point is relatively meaningless.

Because the performance metrics could be obtained at any given moment, so after deployment but also during unit-testing with for example continuous integration, a live visualization could be made with comparisons of older metrics, e.g. graph comparisons of current performance mentrics data and the data from last week. Because the data was fine grained, great insight was obtained in where the hotspots in the live system were located and thus how to fix them properly. Don"t consider the Windows performance counters useful in this case, you really need information about which code actually is taking which amount of the available performance, resources etc.

How many of you decides to build in such a framework so these performance metrics can be obtained later on? And how many of you are actually willing to give in some performance, say 10%, to get the right data to really be able to optimize the whole system properly? I bet not a lot. But think about it for a second... : have you ever even thought about this to build this in from the start? I haven"t, but after I was confronted with the brilliance of the idea and the big help it can be for enterprise applications, I can"t imagine you wouldn"t build it in.

The whole idea is also a great example of how AOP can help you with the engineering of the software you have to create: the performance metrics logic isn"t part of the business domain of the enterprise application however it is part of the whole system when the system is live. This is also an example how much more mature the Java world sometimes is compared to the .NET world: AOP and more in particular Dependency Injection and byte code manipulation at runtime are part of every day"s life however in .NET land, AOP is a technique used by a relatively small group of people, and byte code manipulation at runtime isn"t that easy as Microsoft more and more closes the door on this instead of embracing it in full and making it a first class citizen at the CLR level.

It was a great week and my head still hurts of how many awesome new things I"ve learned. I hope to formulate them in some blogposts in the weeks to come.

While I was walking up the slopes with Frans to watch the World Championships Big air qualifications in Arosa, Switzerland during our annual Software Architecture Workshop, we talked about the support for Domain Model patterns in his product LLBLGen Pro. I shared my thoughts on language extensions and in the workshop, both on and offline, there were a lot of discussion on how to support the Domain Model in our languages, frameworks and tools. Mats wrote a very insightful post on Domain Model Management which covers some aspects of our thinking. Why not take this thought one step further? With all the great language innovations in C# 3.0! What about supporting the Domain Model directly in our favorite language. Imagine the compiler being able to validate the implemented Domain Model.

I would love to hear your thoughts on this idea!

coredomain Transportation
{
  aggregate Car
  {
    ..
  entity Wheel
  {
    ..
  valueobject Position
  {
    ..
  repository CarRepository
  {
    ..
  service FuelTransfer
  {
    ..
subdomain Navigation
{
  ..

Thycotic is growing once again – we are looking for another top calibre developer to join our team - this is a great opportunity to practice agile techniques on the Microsoft .NET platform from an experienced team while working on great products and with interesting clients.

We are looking for a highly skilled, motivated .NET software developer to join our consulting team.  We are a unique employer since we practice Test Driven Development and Pair Programming and focus on constantly improving our team’s abilities and communication.

Requirements for this position include:

• You live, breathe, sleep, eat and drink code (preferably of the C# or VB.NET flavor)
• You want to develop using Test Driven Development (that is *ALL* we do!)
• You enjoy or are prepared to try Pair Programming
• You have a good understanding of Object Oriented principles, the .NET Framework, ASP.NET, relational databases and web application development
• You have the permanent legal right to work in the United States
• You have excellent written and spoken English
• You are willing to work in the Washington DC Metro Area

Preferred but not absolutely required:

• You have strong experience with ASP.NET/ASP.NET Web Services and/or WinForm development
• You are very familiar with Microsoft SQL Server - stored procedures, triggers, functions and general SQL
• You have a Bachelor"s degree (or further study) in Computer Science

Intangible criteria:

• Prepared to do what it takes to deliver value to the client
• Work with others in an environment that encourages new ideas and process improvement

About Thycotic:

Thycotic is a developer-minded consulting company and ISV operating in the Washington DC area.  The company is a leader in agile techniques on the Microsoft .NET platform including Test Driven Development and Extreme Programming.  We are a Microsoft Gold Certified Partner with strong involvement in upcoming Microsoft technologies.  We continually deliver successful projects that are on time and on budget to happy customers while developers maintain sensible hours, vacation schedules and drink lots of FREE soda.  Thycotic also offers opportunities to perform training and work on our own software products.  Stop reading about TDD and come join Thycotic to practice it!

The position carries a very competitive salary based on skills and experience.  It also includes an annual incentive bonus based on mutual goals.  The benefits include healthcare, retirement and generous vacation and conference time.  Thycotic always looks to provide the optimal working experience (however possible) to retain the most talented developers. Thycotic’s office is located in the trendy Dupont Circle area with plenty of things to do after work and all the excitement of a great cosmopolitan city!

Please send your resume and a brief summary explaining your interest in TDD and Thycotic to tdd_me_now@thycotic.com

(Sorry, no visas or sponsorship available, no telecommuting or remote working)

(TDD Job, Test Driven Development Job, TDD C#, TDD VB.NET, NUnit Job, NUnitAsp Job, NAnt Job, CruiseControl.NET Job)

Jim (who looks so much like Robin Williams.....sorry Jim but you do :) and James have a short interview on the O'Reilly windows dev center for their Windows Developer Power Tools book. The interview does mention about MbUnit's combinational testing and the book features row and combintional testing. Each section in the book is designed to be a overview to give you a taster of what each tool can do, I hope that folks do want to learn more about each tool featured in the book. I reviewed (along with Phil Haack) the work Jim wrote for MbUnit, I was asked to write the section but a personal matter prevented that and Jim did some great work in giving us a presence in the book.  Yet to make it to the errata but the URL for MbUnit is not longer MbUnit.org and is MbUnit.com instead. I look foward to seeing this book in print!!

As developers, we pride ourselves on our analytical skills and being able to quickly deduce a problem.  Being “engineers” and “craftsmen” we use tools to gain insight and learn about a problem while we determine our diagnosis.  Every now and then, the tools fail.  This evening I was dabbling with some licensing code in one of our dependent .dlls to troubleshoot a problem that one of UK customers is having.  We had our suspicions that the problem is a globalization issue with dates when not running on en-US.

Members of our team know that I frequently brag about avoiding the debugger – this seems to be a rite of passage amongst Test Driven Development developers who seldom require a debugger since they take such rapid but incremental steps when working.  When I am completely puzzled and need to figure out the logic in some code, my first steps are usually:

• Write a few more tests to demonstrate the problem/requirement
• Refactor the code to a form that I can understand (see scratch refactoring)
• Make some reasonable guesses and add some Console.Outs (getting desperate at this point)
• Finally, crumble and add some breakpoints

It was tough to follow this pattern tonight since much of the code is sealed (it is licensing code after all!) and not very amenable to testing internals.  So I started on refactoring the key elements and putting in some strategic Console.Outs based on my assumptions – BUT THEY DIDN’T OUTPUT.  This had me further puzzled so I added some breakpoints and next I saw that it just doesn’t seem to be executing the correct code.  See this…

It is breaking on the “return false” even though an exception is being throw on the line before (plus it never actually hit the earlier breakpoint!).

After deleting .dlls, whacking bin/obj folders, restarting VS.NET, looking for old rogue devenv processes and finally rebooting the box – I am a little more than stumped.  For those interested, I am using Visual Studio .NET 2003 (yes, we still do lots of work in 2003) and with Resharper 2.0 (#259) as my debugging entry point.  I am going to revisit the problem with Kevin tomorrow with fresh eyes (he already confirmed our suspicions about the globalization/datetime issue) and I will report the results from this craziness if they are interesting.

I found this exercising very interesting as it really highlighted how dependent we are on our tools – even though I more or less knew the issue, I was powerless to successfully fix it without my tools cooperating.

Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC.  Thycotic Secret Server is a secure web-based solution to both "Where is the password for this router?" and "Who has the password for our domain hosting?".  Secret Server is the leader in secret management and sharing within companies and teams.

Google doesn't seem to show me any best practices that anyone has put together with FitNesse, which is odd (or my Google skills suck) so I thought I would capture a bunch here that I've come up with to start.

• Keep your wiki test pages small
• Having a wiki test page with 20,000 tests doesn't do anyone any good. First off, it'll take days to load. Second, it's a sea of gobbly-gook looking at it in edit mode and next to impossible to find that one line that you need to edit. Do your team a favour and keep them small. Like development practices, I like to keep my FIT pages down to a screen or two at most.
• Organize your tests so they make sense
• FIT supports test suites and they're useful, especially for organzing things. Having one table with hundreds of scenarios might be good (more tests are always good) but if they're difficult to read or navigate they'll be cumbersome to maintain. Use a single responsiblity principle when it comes to organizing your tests and try to group them together into some kind of organizational category or unit that makes sense to the tests and users. For example if you have FIT tests that are testing accounts, consider writing a table for each type of account; a table for account fail conditions; a table for special conditions; etc.
• Use "Friendly Names"
• Rather than seeing complete namespaces and fixture names, use friendly names with spaces. So this:
  "|MyCompany.MyApplication.MyFixture|"
  can become:
  "|My Fixture|"
  Also you can use the !import table to remove the fully qualified namespaces. This makes it more appealing to look at when you're showing value to the customer of these tests.
• Seed your test pages and engage the authors
• Getting started with FIT and actually having tests can be a big hurdle. To be setup for success, have the entire team not only go through creating the fixtures and tests but work with the authors about what scenarios they can test. For example not everyone thinks about the failure conditions that should be tested (using the fail[] markup) so make sure the authors of the tests know all the different things they can try. The best scenario you can ask is a perfect test author who knows all the things to test, but when adopting FIT you might need to do a FitNesse 101 with them and get them introduced to different ideas around testing, not just entering tables over and over again. Quality not quantity is what you're looking for in the end.

Feel free to add your own!