Steve Eichert

The Million Dollar Blog

Is It Time To Give up on the blogs.msdn.com Feed?

Getting Started with Ruby Links

• http://poignantguide.net/ruby/
• http://www.ruby-doc.org/docs/UsersGuide/rg/

Cross Platform Photo Software Recommendations

For Christmas my wife got me a Buffalo LinkStation Network drive.  It won the Coolest Gift of the Year award which made my wife pretty happy.  If your looking to buy yourself a Christmas present I’d definitely recommend it.  It’s real easy to setup, plugs right into your network, has a print server, and is way cool, what more could you want.

Anyway, one of the reasons I wanted the LinkStation drive was so that my wife would be able to easily gain access to the photos and music that I have on one of my other drives from her Mac.  Obviously a LinkStation isn’t required for this but it made for a good gift idea so just go with it.

I was hoping that I would be able to get iPhoto to “index” all my photos on the network drive so that from her Mac my wife could browse the photos on the network and then print or email them as needed.  Well as far as I can tell iPhoto isn’t down with this type of setup.  It wants the photos on a local drive which of course isn’t what I’m looking for.  So to finally get to the point, does anyone have any recommendations for photo software?  I want something that provides the following:

• Is cross platform (WinXP, Mac OS X)
• Allows photos to be grouped and organized
• Allows the photos to be tagged
• Makes it easy to print & email
• Rich client (unless the web UI is really slick and easy to get photos into)
• Doesn’t require my to take out a second mortgage

I’ve been using Picasa on my XP machines which is perfect except that it doesn’t have a Mac version.  Any recommendations?

Designing Service Contracts with WCF (Indigo)

ThoughtWorks does Rails

Thoughtworks just won an $800k Ruby on Rails bid.  Maybe this Rails thing isn’t all hype after all?

I still need to find a little project to do some Ruby & Rails experimentation.  If only there wasn’t so much Avalon (WPC) and Indigo (WCF) “stuff” to dig into I’d be in business.

Fluent Interfaces

Martin Fowler has an interesting post about Fluent Interfaces.  I’ve recently had some positive experiences with some mock frameworks that have fluent interfaces.  The major advantage of a fluent interface is that it reads and flows much smoother then a “normal” interface.  The major drawback is that methods named in a fluent manner don’t exactly make sense when standing alone.  Martin does a good job of pointing out the positives and negatives so I won’t rehash them all here.  Do you like “fluent” or “normal” interfaces best?

private void makeNormal(Customer customer) {
        Order o1 = new Order();
        customer.addOrder(o1);
        OrderLine line1 = new OrderLine(6, Product.find("TAL"));
        o1.addLine(line1);
        OrderLine line2 = new OrderLine(5, Product.find("HPK"));
        o1.addLine(line2);
        OrderLine line3 = new OrderLine(3, Product.find("LGV"));
        o1.addLine(line3);
        line2.setSkippable(true);
        o1.setRush(true);
}

vs.

private void makeFluent(Customer customer) {
        customer.newOrder()
                .with(6, "TAL")
                .with(5, "HPK").skippable()
                .with(3, "LGV")
                .priorityRush();
}

Is building software like building a house?

Jim doesn’t think so:

For as long as I can remember, people have been comparing software to construction.

"Continuous design is impossible. You can't add a foundation to a house after you've built it."

"Would you build a bridge without planning it carefully first?"

"I'm an Architect."

At the risk of being rude: Software development is nothing like construction. Nothing!

The Not so Perfect Estimates

String.IsNullOrEmpty()

ReSharper 2.0 still not ready for prime time

Do Agile teams Think?

The development practices of an agile team are different from a non-agile team.  Non-agile teams typically start a project with a long “thinking phase.”  The thinking phase includes thinking about what features the software should provide, how users should interact with the software, as well as how the software can be built to ensure the development phase goes as quickly and smoothly as possible.  All this thinking usually leads to a requirements document, a detailed set of wireframes, and a bunch of UML diagrams outlining the design of the system.  The hope is that all this upfront thinking will reduce the amount of thought that has to take place throughout the project.

An agile team doesn’t spend all this time up front thinking.  They don’t write big long requirement documents, they don’t wireframe out every possible user interaction that could occur within the system, and they don’t produce big UML diagrams outlining the design of the system.  Additionally an agile team uses test driven development to design their software so the perception is that agile teams don’t even think when they start coding, they just let the tests lead them…no thought necessary.  So if agile teams don’t spend all that upfront think time, and they don’t think when they code, do they think at all?

As nice as it would be if we didn’t have to think it just isn’t t he case.  Agile teams think, in fact they’re required to think all the time.  At every stage developers on an agile team should be thinking hard about the design of the system and whether or not things need to be altered to improve the overall design.  And although it isn’t stressed as much as it should be the first step in the test driven development cycle should be thinking.  TDD is a design tool, and design requires thought.  Developers need to think about what the API of the objects being developed should be, they need to think about the things that could go wrong and ensure they account for them in their tests.  As each test is written and each red-green-refactor cycle begins more thought should be included to see if things are headed in the right direction.  TDD isn’t the only agile practice that forces thought.  Pair programming forces a steady flow of thought throughout the day.  Rather then cruising along coding without thought you need to ensure your pair is on the same page and that what is being done makes sense.  Often times a pair will question how something is done which again requires that brain to kick into gear.

So to conclude, agile teams do think…in fact they have to be thinking at all times.  It kinda sucks

Looking for feedback on this blog

One of the things I like about having a blog is the ability to get feedback and comments from people in the community.  When I had my blog over on dotnetjunkies.com I used to get a good number of comments from readers.  Since moving my blog to my own host I’ve noticed that the amount of interaction and feedback I get has decreased.  I’m not sure if its because I suck, or because the stuff that I’m posting on is less interesting, or if people just don’t have as much time as they used to for posting comments to blogs.  I put up a quick survey that consists of 5 quick questions that will hopefully make this blog a better place.

1) What do you like?
2) What don’t you like?
3) What would you like more of?
4) What would you like less of?
5) Is there anything that would make you comment more?

If you have a quick minute I’d love some feedback!

Unit testing is boring, doing TDD is FUN!

A couple days ago I wrote about how TDD and Unit Testing are NOT the same thing.  Today I had the wonderful pleasure of going back and writing unit tests for some existing code that was not developed using TDD.  I’d love to point the blame directly at the person who was responsible for such a terrible thing (untested code) but I’m not real big on pointing a finger at myself.   To be fair to myself the code was UI code and was written when I first started at my new gig.  I hadn’t done much WinForms programming at that point and had done zero TDD with WinForms.  Thankfully I’ve recently seen the light regarding how to “do TDD” with a WinForms UI.  Not so thankfully those UI elements that I had written way back when needed to be refactored as part of our migration to MVP and CAB.  Since much of the logic was already written we had the pleasure of cranking out unit tests.  Frankly writing unit tests kind of sucks.  Doing TDD and watching the design of something evolve through tests is much more fun and engaging then cranking out unit tests for stuff that is already in existence.  Rather then copying over all the code and writing unit tests on top of that logic we ended up recoding much of the logic in a TDD fashion.  At times we cheated and stole the blocks of logic necessary to get a test to pass, and at times we just wrote unit tests.  When we were doing TDD things were more fun.

If you want to have more fun use TDD.  If you want to be bored write unit tests.

We have Search!

Tonight I finally got around to upgrading the server that hosts this blog to .NET 2.0.  Along with the update to 2.0 I rolled out a minor upgrade to the software that powers this wonderful blog.  The upgrade consisted of some bug fixes as well as a couple new features.  The most notable being search.  The search feature is powered by DotLucene and is available via the Search box in the navigation of my site.  You can link directly to search results by  appending your search results to the http://steve.emxsoftware.com/search/ url.  So you can search for all agile content by browsing to http://steve.emxsoftware.com/search/agile or perhaps TDD content is what your after?.  Or something else?

I should note that I wrote the search components using DotLucene over the course of a few hours this past week so there are probably a number of bugs  

Keeping it simple

Type Convertion operators by Fritz

TDD and Unit Testing are NOT the Same!

Is it just me or is everyone claiming to do TDD these days?  I think somewhere along the line the definition of TDD got lost.  I’ve come across numerous blog posts, comments, and mailing lists where someone was starting to “implement Agile” by doing TDD on their project.  Of course since they weren’t yet “doing” Agile they were following the tried and true practice known as Big Design Up Front (BDUF).  They were planning out all the details of their application, creating beautiful UML diagrams, and writing big old requirement documents to specify how all the pieces of the system would fit together.  Once they had all the details of the application defined they created their classes and finally begun using test driven development to test their objects.  As they built up the objects within the application they had the nice tests produced as a result of “test driven development” and thus they were doing Agile!

Test driven development is NOT the same thing as Unit testing!  Test driven development is about design.  If you’re designing your entire application before writing a line of code your not doing TDD.  If you’re writing your classes before writing your tests your not doing TDD.  If you’re generating test code using the cool new features in VS 2005 your not doing TDD.  TDD and Unit testing are not the same thing.

Unit testing is a good first step on the way to doing test driven development but it is not the same thing.  When writing unit tests developers often times have the entire object which they’re unit testing coded up.  Unit tests are not being used to drive the design of the object, they’re merely being used to ensure that it acts and behaves as they expect. 

It’s important to remember that TDD is about design.  It is not an synonym for “unit testing”.

Is your next project likely to succeed?

This was a “whitepaper” I wrote for my previous employer.  I’m posting it here to ensure I don’t lose it. 

As a "business professional" you are likely to be involved in a software development project at some point in your career. It may be the development of a content management system for a corporate website, an employee portal, or a custom developed software package to meet the unique needs of your business. It is important that whatever the software project, you are armed with the information necessary to bring the project to a successful conclusion.

By aligning yourself with the values outlined below, you can help to improve the likelihood of success on your next software project. While the values alone won't ensure success, they go a long way to ensuring the vital parts of the development process have the correct focus.

Value Individuals & Interactions

The most important success factor in any software project is the individuals involved in the project. Despite this fact, many organizations put all of their focus on developing a well defined process for their software projects to follow. This process, mind you, is typically designed to commoditize the people involved and treat them as pluggable components. The best tools and most refined processes will not ensure project success, however, having an excellent team of project managers, programmers, testers, and business sponsors will.

If you're looking to build successful software the last thing you want are pluggable components. Instead, you should seek out talented and skilled individuals that work well within a team environment. Do everything you can to provide them with what they need to be effective. Empower them, let them know they are valued and appreciated. Give them a reason to make your project a success.

Value Working Software

The most valuable thing that you can get from the team developing your software is a working version. Many organizations spend months and even years developing requirements and design documents, and while valuable they don't provide what you really need. Without a working version of your software you can't determine how the software will respond, nor can you foresee what features might need to be tweaked or changed, and you certainly won't be able to determine what will provide the real value.

To help get your hands on a working version of the actual software as soon as possible, you should ask your development team to take an iterative approach to developing the software. Choose the features that will provide the most business value and have them get started on developing a working version. Although this may sound dangerous, remember that you have the best individuals you could find on your team. You didn't just select a bunch of pluggable components; you selected a set of highly skilled individuals that have been empowered to work together to reach a common goal—delivering you valuable software.

By taking an iterative approach you are able to get a working version of your software much earlier in the game, thereby enabling you to determine the best next steps for development. After each iteration you can re-evaluate where you stand and what remaining features will prove most valuable. Have your development team deliver early and deliver often. The more you get your hands on your software the more likely your software project is to succeed.

Value Customer Collaboration

The "customer" of the software should be placed at center stage. They have the knowledge and practical business experience necessary for developing great software—more than anyone else, they know what is of value.

Encourage the "customer" to be closely involved with the project team. Close interaction and collaboration between the customer and team will help everyone realize where the real value is. Make the customer part of the team and have them collaborate with programmers, testers, and designers.

Getting the customer collaborating with the people developing the software will help the team see the project as more than just another project; they will begin to see the real value. Your development team will like to see that what they are doing matters, and will probably be motivated by it.

It is always good practice to have the customer review the software after each release. After viewing the current state of the software, you should also review the requirements not yet developed to determine which will add the most value and which requirements may need modification. Continual collaboration between the customer and project team will positively enforce the most valuable features of the software and significantly decrease the amount of re-work after the final product is released.

Value Responding to Change

Traditional software development processes are predictive in nature rather than adaptive. They use a detailed project plan based on a set of identified tasks & requirements to predict how the development of the software will occur. Unfortunately, software development is a very unpredictable endeavor.

Changes are inevitable, so why not embrace them? Instead of trying to take a predictive approach to your projects, try to make them more adaptive. Setup your project to be ready to respond to changing business needs and requirements. Allow customers to change requirements as their understanding of the problem evolves and manage those changes in requirements at the beginning of each iteration. Find ways to make your process responsive to the change—you might as well because it is inevitable.

The values outlined in this article may seem like common sense, however, the majority of software development projects are not in alignment with these essential values. Give your next software project a better chance at success by aligning yourself and your development team with these values—you won't be disappointed with the results!

Interface design in distributed solutions

Ralf Westphal and Ingo Rammer are having an interesting discussion about Interface design in distributed solutions.  They start by talking about how to design components, and ponder whether interfaces are the appropriate way to define contracts for components.  They talk about how coarse grained interfaces should be, discuss whether factory methods are a good way to provide run-time decoupling, and whether interfaces are good for times when there is only one implementation. They then move onto discussing service contracts in the context of Indigo (WCF).   One of the topics that I’m particularly interested in is whether data contracts should be kept completely seperate from the data objects used by the components and data layers in the application.  If they’re kept completely seperate then at the service layer there will be a good bit of translation logic that will take data contracts and convert them into the data objects that are used by the components that live behind the service layer and perform the “real work”.  On the other hand if you decide it’s ok for your data contracts to be shared with your components then you don’t have to worry about the extra translation.  Instead you have to worry about how much of your intenal implementation details will be exposed to the outside world due to the tight coupling between your servics and components.  They hit the nail right on the head when they state the followign question and answer:

 Do you believe in strict decoupling and service autonomy and is this desired in your solution or are you just using a service as a means to an end (for example to avoid deploying database clients to your users' PCs)?

I'm a believer: Manually creating the message's content will be a second nature to you anyway. I think you are already wondering why we might even suggest anything else ;-)

I'm just being pragmatic: You're welcome to use a simple solution (like items #1 or #2 in my previous reply) if you really only use a service as a means to a specific end.

So if you are a true service oriented believer then you most likely want to have seperate data contracts that are only used by your services.  This will result in having some duplication in objects (one for services, and one for your components) but will make the overall design more de-coupled.  If your just being pragmatic then you might use the same objects within your services and components.  This makes your services a lot more fragile since changes in your components and data layers will effect the contract of your services.

Are you a true SO believer or are you just pragmatic?

MSBuild Community Tasks Project