Thursday, 24 July 2008

DB access problems with VS 2008 Database Edition

I've just installed VS 2008 Database Edition to help with managing the new databases for my current project. The DB project templates in VS 2008 DE provide a really clean way of managing all the DB objects and makes it easy to have it all under source control as well.

However I ran into trouble setting up the projects and kept getting the following error: An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified).

In typical Microsoft style there's no help attached to that error; Sorry Mac, you're on your own.

A bit of digging around revealed two things: You must specify a target database for your project (if you don't it'll try and connect to the default instance on your machine and that won't work) and you have to enable the SQL Server Express service on your machine as this DB is used by the project for storing comparison data etc.

Most women will claim that men are reluctant to stop for directions and to read the instructions for the gadget they just bought. Maybe so. I didn't bother reading the tutorials on setting up the project. But blimey, it could certainly be made more intuitive!

Anyway, this post is more of a Note To Self - but if it helps you, too, then great!

Saturday, 19 July 2008

Automatic properties; a great idea?

A little while ago I had a conversation with another guy about coding standards and the subject of member variable prefixing came up. I'm a real fan of underscore prefixes like private string _firstName; and suggested that this be included in the coding standard so as to avoid problems stemming from sloppy coding and member names varying by case only.

I've come across many a class where the coder intended to access the property FirstName but - possibly because of IntelliSense or other code-completion shenanigans - ended up accessing the member variable firstName instead. If member variables are consistently prefixed then this isn't a problem. I like the underscore because it stands out, it's just one character, and it kind of anchors the variable to the class or scope.

Anyway, the chap I was speaking to said "sure, we can use prefixes but it really isn't so necessary because we'll just use automatic properties instead."

Hmmmm..... Simpson, hey?

Today in C# you've the ability to declare typed properties which hide the underlying variable. In other words, there's no longer the need to declare a private member variable and expose it explicitly through a public property. Now all you have to do is create the property itself, like this:

public class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
}

It is a pretty cool feature. But it's really limited as well. If you want to do anything but expose a variable on your class' interface, you can't use automatic properties. You can define the setter as private but that's about the flexibility you have.

Once you start to tamper with either the getter or setter your property is no longer considered automatic, so you're back to good old normal properties. It seems to me there's not a whole lot to be gained from automatic properties because in my experience and, more often than not, you typically want to do something other than access a member variable (at least in the setter) when the property is called.

Oh, and another thing: Automatic properties aren't debuggable. You can set a breakpoint on an automatic property but it will never be hit. Boo.

I reckon that in the future we'll be able to have another kind of automatic property where you actually can access the get/set variable, validate, or do whatever you like.

For now the automatic property is nothing but a bit of syntactic sugar. I'm on a diet (ha-ha!) so I'm likely to stay clear.

Friday, 18 July 2008

Exploitative software

At the Rotterdam Central metro station last weekend they were having some trouble with their ticketing machines. Have a close look at the OS names.

Seems they've one for your every day tickets (the purely fabricated prices) and one for special occasions... like festival weekends for example. Fire up the Exploitation OS, sonny!

Thursday, 17 July 2008

Go Wordle yourself


I just had to try this. Very cool idea. Check out Wordle and get your own graphical representation of the stuff that comes out of your head and onto the page. Judging by this picture my blog certainly does not look very technical. Why "Address" is so prominent I've no idea. But I like the idea, and it looks kind of cool, no?

I just can't shut up about it


Agile. I use that word so many times a day now I'm starting to sound like a salesperson. Not good. But I'm deliberately keeping my vocabulary small (keeping it simple) so that at least what people hear is consistent.

I have been interviewing business analysts lately and it's important to me - surprise, surprise - that they have experience with both analysis and project management in an agile environment. As it turns out, the guys that I've liked have a similar idea to mine about agile methodology: One should be agile about that, too!

What I mean by this is that if you're truly agile you don't lock yourself into one single methodology for running your project. It's better to mix and match, pick and choose, chop and change. Construct your own methodology from a set of others and make it fit your situation, your constraints, your experience.

Why is this important? Because the less you impose process, the more nimble you are.

I've had some interesting discussions around this recently. I'm leading a new project, a new and exciting build. It's the ever elusive greenfield. A chance to do something new, something different, to try different shoes on and throw away those that don't fit. This is why I accepted the challenge, because of all these opportunities. And I have been adamant that we should be nimble, flexible, agile all along, and that we should use this opportunity for all that it's worth to try new things.

But my ideas were almost stopped dead because the company that I'm working for currently has a massive IT initiative underway to put in place required processes to manage their rapidly growing development team (which is up by 300% in a matter of months) while at the same time refactoring and rebuilding an aging and highly coupled trading platform.

The team undertaking this work is already so big and now growing so fast that they need process. I argued that the team that I'll be leading is so small that we really don't need all that process. I argued long and hard and had to turn to many different people before I could finally convince the IT leadership that it really is OK to go light on process and tools and support systems when you're in the early phases of something like this.

There is no need for a full blown Team Foundation System setup with all its bells and whistles. Subversion does the trick, and it does it beautifully. There's no need for meetings about every aspect of what we are about to embark on. There's no need to define processes for this, that, and everything in-between. In my case, we're kicking off a proof-of-concept project that later will - hopefully! - end up becoming a large scale development with full IT and business backing. Right now, we just need to get on with our POC with minimal hassle and minimal interference. Later on, when the business says "Yes this is great! Here, have a wad of cash", that's when we should start looking at any extra processes and tools and systems we might need to put in place.

I've spoken before about things being a problem only when they are a problem. Anticipating a need for process months prematurely just creates a problem from a notion of something that doesn't exist. Remember that. YAGNI applies not just in best-practice coding guides, it applies to everything that can be labeled as agile.

So, in final words and a note-to-self: Shut up and do it!

Tuesday, 8 July 2008

More and more about agility

I'm on a bit of a roll with agile thinking at the moment. As you can surmise from a previous post, the thinking in my current environment has traditionally been anything but agile.

It's not uncommon. While agile is a buzzword and everybody's talking about it, there are still a lot of people to whom the concept is still vague, unfamiliar, strange, alien - just not something they understand. It's been the case here, and it's now slowly changing.

I've talked about M before. M's smart. He's sharp. He gets things. You show him an article on a concept he's never heard about before and he'll grasp it within an amazingly short amount of time. This happened when I showed him the Getting Real book by 37Signals. He got it.

Though, he doesn't always get it entirely. And I am not one to blame him in this case. Moving on from your typical waterfall, specify-in-entirety-then-develop-till-it's-done approach to a an approach that says "let's just do what's right for right now and then see what's next" would demand a lot from most of us. So in M's case going agile so far means going from one iteration to three iterations.

That's a far cry from being agile because if you're truly developing in an agile manner you have no idea how many iterations you'll need. More likely, you'll have an infinite number of iterations.

At first M's initial take on agile frustrated me, but then I thought about it and now it doesn't bother me at all. Why? Because of something that I read in 37Signals' book. It says
It's a Problem When It's a Problem
In other words, if you think something is going to be a problem, don't worry about it until it actually becomes a problem. M's three-iterations-is-agile isn't a problem because he doesn't know what the first iteration is yet. Even more to the point, when we've all agreed on what the first iteration entails, he'll see (as the iteration nears it's end) that iteration number two looks a whole lot different than what he thought before we started.

As a friend put it the other night, it's kind of like going through cycles of throwing away requirements. What you thought was a requirement a month ago suddenly no longer applies or has been replaced by three other requirements - all because your small iterations bring you a workable representation of software that is real and tangible. Real and tangible things give you experiences. Experiences can give you ideas about how to make that particular experience even better.

And that's as simple as it is. Small-step enhancements. A few of those, based on experience, give you a whole lot more than one big effort based on assumption.

I should give a couple of examples here on what this means, in real terms.

At my previous employer we had a kind of semi-agile approach to developing software. For the greater part it was good, but sometimes we'd get these over-specified documents that told us not only what the customer wanted but also exactly how it should be done (read: implemented).

Pardon me, but if you're hiring me to build software for you, you're leaving the "how" more or less up to me. Anyway...

So I got this requirements document for a customer management tool. And it had this section in it about the "Address Book" and how it should look and work. Every address should be displayed in a certain way, and if an address was a customer's designated billing or shipping address they should appear at the top of the listing (with the billing address appearing first) and be clearly marked as either "Billing" or "Shipping". And the Address Book should paginate all addresses. And to make a n address a billing address there should be a button to click next to the address listing. And the same applies to making an address a shipping address. These were, more or less, the requirements.

We (the team of developers) had a chat about it. And we dropped the pagination, because we figured not many customers would have enough addresses to really need pagination. And we dropped the "click-button-to-make-special" idea.

Instead we just listed the addresses on a page and put two columns next to them with checkboxes in them, one to indicate that an address is a shipping address and one to indicate that the address is a billing address.

No pagination, no buttons, no automatic re-ordering of the way addresses are listed. Instead we did it nice, clean, and simple.

Guess what? It worked just fine. And when the time comes that enough customers complain that it's not working just fine for one reason or another... well, then I bet they'll change it.

Another example: A different part of that same application required that we could display and validate data according to a client's specific demands. We had one running instance of the application so we did this by extending standard ASP.NET controls as user controls and building a simple templating system around it. It took one of our developers just under a week to do this. It worked. It was nice and simple. But there was one potential drawback...

Because we'd developed this templating solution using user controls we couldn't re-use it in other applications. We thought we might need to re-use this functionality elsewhere, so we talked about re-building it all using server controls and custom configuration blocks etc etc etc. But in the end we didn't. Because we didn't need it then.

As far as I know they haven't needed it since, either. But the day may come when they do need it, and then they'll build it.

These are some key examples on what it actually means to be agile. It's not about being lazy, it's about being smart.


... and now that this is out of my system it's time to hit the sack :-)

Monday, 7 July 2008

A few more words on agility.

I wrote in a post not long ago about the importance of staying agile in your development process, and I thought I'd elaborate a little further. I'm now involved in a project which is getting close to entering the development phase, and the last few weeks have highlighted to me where we go wrong and why we go wrong so often when we've got a good idea for software.

The potential scope of the project I'm working on now is huge. The idea itself is nothing new (I can't go into it here for obvious reasons) but the setting and the "take" on the idea is new, and probably better than what the competition has come up with. The guy that came up with the idea (my boss, let's call him M) soon realized that there is real money to be made in an emerging market, and he's received funding from the company board to set up a new department and get the project off the ground. Everybody is really excited about what's about to happen and everyone is "behind" the idea.

All of that is really good and nobody's complaining. However, all this excitement lead to some problems right from the start. M's idea grew rapidly. Scope creep, anyone? More like scope avalanche/flood/torrent (choose your own appropriate natural disaster analogy). And everyone was still just as excited. Except me, probably. Part of my excitement started turning to fear. I saw that if this thing was allowed to take its natural course, we'd crash and burn. Because, quicker than you can say "Waterfall methodology" M (with my help) had mapped out a system so large and so complex that it simply wouldn't be possible to deliver it on time. It probably couldn't be developed in twice the allocated time. And when I pointed out the fact, things got really scary for a while.

M was incredibly keen on "doing something" (I admire this man's energy and passion for his work, I really do). The business leaders thought the idea was brilliant and wanted it to happen, and happen now (heard that one before?). And the fact that there was too much work and not enough time could easily be overcome. The company makes good money these days, so we could have more allocated to our budget.

More money equals more developers equals more lines of code in a day equals faster delivery. Right? I don't think so. In fact, I know it doesn't work that way. And that's what I had to make M and the others see. Before _anything_ had been produced, the company was - potentially - ready to fork out huge amounts of money to back up a project that had done nothing to prove itself except look good on paper. So I put the brakes on. I spoke with M and expressed my concerns. I told him I thought it is incredibly risky to assume that we know everything about what our customers want and develop something so huge purely on a hunch. I told him we should keep the original deadline and pull back the scope so that we could hit the deadline safely. I told him we should limit the available resource and do as much as possible within the constraints of the original budget and resources available. I asked him to read 37Signals' "Getting Real".

And guess what? M skimmed through "Getting Real" and he got it. He understood the point of what I was saying. And so he slowed down.

But the business didn't. They encouraged us to "think big". So we did. In a four day exercise we thought real big and put together numbers and estimates for what it would cost to deliver M's idea, scope creep and all, by the original deadline. And the cost came in at about ten times the budget for the first year. That kind of drove it home: It's a risky and really costly approach.

It's a risky approach because there are too many assumptions, and the main assumption is that we know what the customer wants. In a new project such as this one, where everything hinges on the customer, you should assume as little as possible and instead listen to what your customers want. Launch with as little effort as possible and be ready to change when your customers demand it. That way you'll have a project that can grow and adapt and be successful because it deserves to be - not because it had amazing funding.

So now we're starting small. Thankfully. And guess what? The first deliverable isn't even going to be an in-house development. We're looking at some third party solutions to launch part of the product and build the rest around that third party solution. That way we can build the product in bits and pieces and work it up as required while the out-of-the box solution we purchase takes care of our first deliverable.

So the project is turning back to a more agile approach, and thank God for that. What these weeks have highlighted to me is that there is a very real and very palpable risk of getting carried away when you're working on something new and exciting. It's easy to forget to stop and evaluate what you're doing. And when enough people get excited about the same thing, crowd control becomes difficult. We must remind ourselves that the _idea_ is only the starting point, and in the end it is really the execution that matters.

What happened in the first few weeks of this project is that there was too much focus on the idea and not enough focus on the reality surrounding its execution. Hopefully we've adjusted that balance now, but I'm sure there will interesting times ahead because "speaking agile" and "doing agile" are two quite different things. And I'm sure I'll be writing more about it here.

Saturday, 5 July 2008

Quick update on the Silverlight plugin issue

In a reply to a comment from Jonas Follesø I wrote
Also, having installed the Silverlight 2 plugin, I find that several of the Silverlight 1 sites from the Silverlight.net showcase either do not work (I'm prompted to install Silverlight!) or work intermittently. This doesn't give me a lot of confidence in the technology right now.
Jonas followed up with a link about this particular issue. Turns out Firefox 3 isn't yet a supported browser!

Thursday, 3 July 2008

Silverlight plugin trouble

How can Silverlight expect to take over the world when there are such serious compatibility issues between the plugin's version 1 and 2? I upgraded my plugin in IE, but not in FireFox. Now FireFox crashes, just simply dies whenever I try to go to a site with embedded Silverlight 2 content. Whether this is a FireFox 3 issue or a Silverlight issue I cannot state categorically - but it's a big issue and seriously detracts from the appeal of building apps with Silverlight 2. I'm also a bit worried about the size of the new plugin. 4.7MB!! That's 3.3MB up on version 1. Not a good trend.