As i’m sure most of you have noticed, Ayende recently started an NHibernate Donation Campaign.  I was against the idea from the beginning and even though this post will probably piss off a few people (like i ever cared about that, right?), i wanted to share a few of my thoughts on this with you.

The idea of sponsoring an open source project and helping out financially is definitely nice, but there are some very important practical issues that need to be kept in mind.  Those practical issues are IMO being ignored by this campaign (which honestly feels like a publicity stunt more than anything else) … some of them were mentioned in the original mailinglist discussion but no resolution has been offered.  There are probably more issues that we haven’t even thought of yet, but the most important ones are (again, IMO):

• Who’s going to decide how much of the money will go to the committers, and what will that be based on?  Will it be based on past contributions? Future contributions? The complexity of the contributions? Total number of contributions? Total time spent on the project?  We can’t even measure some of these things, so this is bound to either raise some discussions sooner or later, or might even upset some people.  I can certainly imagine that some contributors from the past (like, the ones who did most of the really hard work in the beginning) could feel that they’re entitled to some (or most) of the money.   Discussing how to spend the money on committers is just going to open a can of worms that could possibly cause much more problems between committers than it would solve. 
• There has to be some legal entity (or at least a person) who’s in charge of the bank account where the money will be deposited.  At this point, we have no formal structure or organization to deal with something like that.  I’m no expert on legal matters at all, but i can’t help but think that this isn’t something you can just decide on in a mailinglist… Some level of formalization is most likely required here.
• Taxes… if the money goes to committers, then they will have to pay taxes on it based on the laws of the country they’re living in.  Tax laws obviously vary from country to country, but i don’t think it’s unrealistic to claim that between 25% and 50% of the money will simply go to the government(s) instead of actually benefitting the project.  You might wanna keep this in mind before you donate…

These are just 3 big issues that could come of this, and i don’t really see a true benefit to the whole thing.  The people who in the past have spent time on NHibernate either volunteered to do so, or were paid by someone (or some company) to spend a certain amount of time on it.  Without donations, it will just go on like that and i don’t really think there’s anything wrong with that.   While resources are certainly limited, this approach probably causes less problems than one that distributes donations amongst committers.

Now, just to be absolutely clear on this… i am one of the NHibernate committers, and i don’t feel that i’m entitled to any of the money that will be raised.  For one, i haven’t committed anything in the past 6 months, and the things i did commit definitely aren’t worthy of a donation.  If we are going to accept donations and spend it on people instead of infrastructure, i believe any money that would be raised should go to the people who originally started NHibernate and worked hard to get it to a state where it actually became usable in the .NET world.  If it weren’t for their efforts, it never would’ve been in a position to become the de facto ORM in the .NET world, regardless of who’s working on it right now.

Ayende recently wrote about how most software development processes ignore the actual building of software.  Which reminded me of an excellent post written by James Shore over a year ago, and that i commented on as well.  What James (and Ayende) are saying is that if you don’t actually take care of the way you build the software, no process can guarantee that any kind of perceived progress in the beginning can be sustained over the long run.  Sustainable progress takes effort, and you’ll never keep it up if you don’t put the proper practices in place to enable it.

The sad (and typical) part is that the methodology which makes everything sound easy and prescribes the least amount of effort required is the one that took off the most.  Obviously, i’m talking about Scrum.  Scrum makes no mention whatsoever about technical practices that are required to enable sustained progress and Scrum proponents will proudly proclaim that it doesn’t need to since it’s about product development instead of software development.   You can easily become a certified Scrum master while you might not know anything about real-world software development.  In fact, i’ve seen plenty of people boasting that certification on their resume and their linkedin profiles while they really shouldn’t be involved in any kind of professional software development to begin with.

And since Scrum is simple enough for middle-management (you know who i’m talking about… the ones that are usually not competent enough to promote to upper management) to understand, they jump on it as well and before you know it, they’ll be talking about the Scrum concepts as if they actually knew what they’re talking about.  Teams and even entire departments in large corporations are told to be ‘agile’ and follow the Scrum rules and concepts for every new project.  And they do.  And it works great… for a while.  We all know what happens after that.

Then take a look at Extreme Programming (XP).  It’s been around for a while now.  And it unfortunately doesn’t have a good, catchy name.  In fact, its name is probably one of the biggest reasons why it never took off the way Scrum did.  XP prescribes a lot more than Scrum, and even details the technical practices that you’ll need to enable sustainable progress.  And while you don’t need every single one of them, they all provide major benefits and the more of them that you do use, the better off you’ll be.   So what is the problem with XP?  I never really understood why so many people jumped on Scrum, and now Lean (until the Toyota recalls that is) but never really got into XP.   Well yeah i do understand.  XP takes more work and effort to understand and apply.  And that, my friends, is the price you’ll have to pay for sustainable progress(*).

*: i’m talking about the actual effort and work, not XP in itself

Just read an interesting post from David Tchepak about the lessons he learned from his long-term agile project.  The post itself is interesting but there was one point in particular on the momentum of his team that caught my attention:

This probably sounds a bit touchy-feely, but I think dismissing it on those grounds is ignoring a fairly fundamental part of human nature. If every day, every task is a thankless struggle, the intertia will pull down your team’s morale, motivation, concentration, and reduce their creativity and ability to innovate. On the flip side, once the team gets up a bit of steam and starts churning through stories, seeing visible progress as they move across the task board and into the Done column, the team’s enthusiasm and creativity soars. They start kicking around new ideas on how to remove some duplication from the code and reduce some overhead for future stories.

David is right, but i’d go even further than that.  I’d assert that good team dynamics are essential for achieving high technical quality that is sustainable in the long term.  I think we can all agree that people work better together if they actually like working with each other.  And i’m pretty sure that many of us have experienced first hand how a negative relationship within a team can have a pretty negative impact on the technical quality of a project. 

Have you ever been on a project where you were looking at a piece of code thinking “wow, this really ought to be cleaned up… but i’m not touching it since John is gonna get all pissed over somebody touching his code”.  Or worse, “wow, he really made a mess of this but i’m not touching it… let him live with the pain”.   I certainly wouldn’t be surprised if many of us have at one point (or more) in our career had this exact thought about a certain piece of code written by a teammate at the time.  That is a perfect example of how negative team dynamics can have a pretty serious impact on the technical quality and thus, i’d argue, the long-term viability of the project.   See, the thing is that it won’t end what that certain piece of code.  Sure, code rot has been introduced.  But even worse, team rot is being introduced by this behavior as well, even if you are just trying to preserve the peace by trying to avoid a possible confrontation.

This kind of team rot will not end there.  If you don’t actively try to get rid of it ASAP, it’ll eventually spread throughout the team, as more and more people gradually get into the same mentality.  Eventually, even the strongest, most positive personalities can fall victim to it.  When new people join the team, they’ll quickly pick up on it as well and there are very few people who are willing to stand up to such a situation when joining an existing team.  As i’m sure you can imagine, nobody really likes working in such a team.  A lot of people in that situation will get into a “i’m just gonna look out for myself and to hell with anyone else” mentality.   They will try to do their job in a way that they will not be blamed for anything.  Communication will drop to a ‘nothing-more-than-necessary’-level.  A lot of issues will be ignored until they are actually found by end-users.  A lot of time and effort is going to be wasted in general.  And you’ll probably end up with a pretty high turnover rate of team members.  Believe it or not, these kind of teams truly do exist.

On the other hand, if everybody on the team gets along everything seems to go much more smoothly.  People won’t be afraid to make changes in other people’s code if everyone understands that it’s for the best of the project and if they know that it’s not gonna lead to a bitchfest from a difficult team member.  Discussions will be about actual facts and merits, not about not-wanting-to-give-in-to-someone-you-no-longer-like.  People will alert their team members when they notice something that could cause problems later on.  People will be much more likely to maintain their technical discipline when there is positive peer pressure to maintain high standards.   People will help each other when they can.  Essentially, those people will form a true team instead of being a collection of coworkers who are unfortunately working on the same project together.

As much as many of us strive to improve our technical abilities and skills on a continuous basis, we also need to ask ourselves the following questions regularly:

• Am i a good team member?
• Would i like to work with someone like me?
• What can i do to make people enjoy working with me more than they might do now?

That doesn’t mean you have to become Mr Popular.  It doesn’t mean you have to crack the best jokes.  You can be almost entirely yourself, as long as you realize that:

• communication is extremely important
• treating others with respect is crucial
• nobody likes working with whiney developers
• you can’t expect others to work on their flaws if you’re not willing to work on yours… it’s a two-way street

Quite a few posts have been written lately on the state of the ALT.NET community, or movement or whatever else you want to consider or call it.  I’ve always thought of ALT.NET in 3 ways.

1. it is a mindset
2. it is a community
3. there is a movement

The ALT.NET mindset was originally described perfectly by Dave Laribee:

1. You’re the type of developer who uses what works while keeping an eye out for a better way.
2. You reach outside the mainstream to adopt the best of any community: Open Source, Agile, Java, Ruby, etc.
3. You’re not content with the status quo. Things can always be better expressed, more elegant and simple, more mutable, higher quality, etc.
4. You know tools are great, but they only take you so far. It’s the principles and knowledge that really matter. The best tools are those that embed the knowledge and encourage the principles (e.g. Resharper.)

This mindset still lives on, and will always stay alive. There will always be .NET developers that are continuously looking for better ways to create software.  We might not think there are enough of them, but they are still growing gradually.  Typical ALT.NET topics, practices and principles have become much more popular and more and more people are definitely still looking to learn about them.  I can’t think of a single reason why this would ever cease to happen.

As a community, ALT.NET hasn’t done a good job (IMO) of being accessible to new-comers.  I’ve complained about this in August 2008.  Nothing changed after that post, and nothing will change after this post either.  A lot of the people in the ALT.NET community are still too negative in expressing their views, or have even stopped trying altogether.  Some of them just attacked everyone who disagreed with them.  Things like that will obviously never, ever lead to adoption of your thoughts and ideas.  And after that, they’d complain that nobody was listening anyway and that they were tired of trying to discuss these things with people who didn’t believe in it yet. It also doesn’t help that quite a few people got involved purely for the sake of bettering themselves.  After all, the ALT.NET name was hot and being associated with it and getting involved with it was an easy way to improve your reputation, status and for some even their finances.

As a movement, we’ve failed as well.  Essentially, the ALT.NET movement is about education.  Teaching people the things we believe in.  Showing them that there are better ways to develop software than that what is more accepted in the Microsoft world.  In the early stages of the movement, there was a tremendous amount of interesting blog posts being written with exactly that purpose in mind.  Teaching people.  Showing them the benefits.  Explaining things to them.   After a while though, some of those bloggers didn’t quite put the same effort into it anymore.  A lot of them resorted to one-liners about why approach A is better than approach B and they weren’t really taking the time anymore to try to educate people.  The rise of Twitter certainly didn’t help either since you simply can’t teach this stuff to people through 140-character tweets.  You can’t really show them the benefit of whatever it is that you think is a good thing to do.  And since a lot of those bloggers are spending more of their time on Twitter than on working on their blogs nowadays, a lot of valuable knowledge and experience isn’t being spread as much anymore as it used to.  Now obviously, we can’t tell people how to spend their time so if those people prefer to spend time on Twitter instead of writing good posts that could help more people, that is their personal choice and nobody can blame them for that.   At the same time, they can’t really complain about the current state of ALT.NET as a movement and a community either.

But hey, the mindset still lives and will continue on living.  The best thing you can do is to share your knowledge and experience with as many people that want to hear it.  And trust me, there are quite a few people who want to hear it. 

Something that frequently bothers me is when people/companies create services that are basically thin layers on top of their database.  The service contracts expose the typical CRUD operations for each table, and add some additional methods for specific queries etc.  These kind of services will sometimes pretend to contain a bit of ‘business logic’ but they are essentially just a remote interface into your database with maybe a bit of extra security on top of it.  They effectively turn your database into a remote service.  Now if you’re anything like me, you’re probably thinking “why on earth would people do that?”

There are probably a few answers to that question, but one reason that can’t really be disputed is that a lot of the tooling that Microsoft offers to developers simply encourage this kind of stuff.  Let’s go over a little example.

I wanted to see what some of Microsoft’s recommended tools would create for me if i wanted to create a Silverlight application which uses a database.  Obviously, a Silverlight application can’t use a database directly so the application will need to communicate with a service.  The service obviously does have access to the database.  RIA Services is a solution that Microsoft seems to be pushing a lot for this specific scenario so i figured i’d give this a shot.

I created a RIA Services Class Library project in my solution and tried to add a ‘Domain Service Class’ (as the RIA Services templates call it) to the project.  If you already have a DataContext or an ObjectContext defined within the same assembly, you can immediately select the database tables that you want to expose.   So i canceled the dialog and quickly added an ADO.NET Entity Data Model to the solution for which i selected my Chinook database.  I tried to create a ‘Domain Service Class’ again and got the following window:

Well, now that sure is easy isn’t it? I can immediately select all my ‘Entities’ and i can even check whether i want to be able to edit them through the service, and apparently i can also generate associated classes for metadata (which would be useful for validation according to the tooltip).  I checked the Album table, and left the ‘Enable editing’ option unchecked.  This created a service with the following code:

I don’t know about you, but i love those TODO statements.  After all, you really do might want to consider constraining the resultset that could be returned by the GetAlbum method.   Who knows, perhaps you have certain use cases where you don’t want all of the ‘entities’ in the Album table to be returned by your ‘domain service’.  Hopefully, this service will be used by developers who are smart enough to realize that they should modify this method, instead of using client-side LINQ statements to filter the returned Album ‘entities’ as i’m sure we’ve all seen in too many Microsoft demo’s already.

It gets better if you recreate the service and check the ‘Enable editing’ option.  Now you’re ‘domain service’ will also contain the following methods:

Man, this sure is easy, isn’t it? I now have a service that offers me full CRUD access to the Album table in my database.  If i wanted to, i could now start implementing a screen in my Silverlight application which allows my users to list the albums, edit them, delete them, create new ones, etc… and i wouldn’t even have to change anything in my ‘service layer’.   The problem is that too many developers actually will do exactly that.   After all, why should they doubt any code that was generated by a tool which comes from Microsoft?  If the tool can generate this, then certainly some people actually want you to use it like this, no?  If not, why would it even generate code like this?

I’m sure this kind of stuff gets a lot of ooh’s and aah’s during the product demo’s at Microsoft events, but other than that, what good does this really bring?  Is this really the way you want people to develop their services?  Do you really want developers to pretty much expose the database as-is to remote clients?  And those TODO statements simply won’t cut it, you know that all too well.  I simply don’t think there’s any good reason to generate code like this because a lot of people will simply take it as is and use it like that directly from their client code.  Oh sure, most of them will hook up the authentication but i’m willing to bet that very few people will actually put real business logic in there.  Why would they?  The message that a lot of people will get from the resulting code is that a service is merely a way to provide CRUD for your database tables.  What’s business logic to these people?  Right, the stuff they’ll implement in their presentation layer because this service doesn’t really encourage people to consider implementing it there.

The only benefit that i can see from using RIA services is that you don’t really have to deal with your service contracts, and your operation contracts or any of that stuff.   No, we won’t be doing any of that.  We simply use a [EnableClientAccess] attribute and we’re done!  I don’t really consider that a benefit, though i can certainly understand why people would not want to deal with the pain of classic WCF services.  RIA Services is simply a solution to the wrong problem.

I haven’t looked at ADO.NET Data Services (which will be renamed to WCF Data Services in .NET 4.0) yet, but i suppose it’ll be more of the same: something that makes it incredibly easy to create services directly on top of your database data.

Seriously though: who on earth actually wants that?

I have no doubt that there are some people out there that are using RIA Services in a responsible manner and are sticking by responsible architectural guidelines.  I also have no doubt that those people are ignoring most of the tooling that is offered by Microsoft around it.  So really, why not get rid of this kind of tooling, and spend the effort that normally goes into those tools (or anything else which encourages bad practices for that matter) on providing actual guidance to the developers of your platform?  The last thing we need are more developers who think that this is ‘ok’, or projects that have been delivered based on this kind of ‘architecture’, or customers that are turned off by .NET projects because “they all have maintenance problems”. 

Little over a year ago, i wrote a post which had some career advice for young software developers. That post was mostly based on things that worked for me, but obviously also on mistakes that i had seen other people make. Now, a large percentage of posts in my ‘Opinions’ category are directed at people that i know personally, and this one is no exception. I typically don’t mention names or actual situations in those posts, but in this post i am going to talk about a certain situation, though i won’t name names. I am going to contact the person in question so he knows full well that this post is directed to him. If he doesn’t like that, that’s his problem. Hopefully, he’ll appreciate the advice though.

Every year we work with interns from the school that i and many of my coworkers come from. We’ve been extremely lucky with the interns we’ve gotten from that school so far, and many of our best developers actually come from that school. We basically expect to get really good people from them and when they do good during their internship, they usually get offered a job and most of them accept it. Last year, we had 5 interns from that school. Two of them are now working for us. There was another guy who i would’ve loved to have on our staff. This kid was 21 (maybe 22, not sure) years old, and i quickly noticed that he was exceptionally talented. I don’t know about you guys, but i rarely get to talk with anyone who really makes a great impression on me (on a technical level) who i’m not already working with or who i’ve haven’t worked with in the past. I was very impressed with this kid even before i saw his code. He knew a lot of stuff that most of us only learn after a while, and he seemed to be a very all-round talent.

I was very curious to see how he would complete his internship and i was already hoping that he would be working for us once he graduated. He took on a leadership role of his team (which admittedly, consisted only of interns) but he really managed them pretty well. He took care of most of the technical challenges, and he made sure the others were productive in their tasks. If he wasn’t sure of certain technical issues, he didn’t mind asking for advice or help. The skills and the approaches he demonstrated at his age were truly exceptional in my opinion. No matter how good you think you are right now, think back about how you were when you were 21, 22 years old. I thought i was pretty good back then, but i didn’t even know a fraction of what i know right now. And i don’t just mean on a technical level, but more about how businesses work, how you need to deal with people and situations, stuff like that. Most people simply don’t have a clue about how to deal with that at that age.

This kid knew, though. Not everything obviously, but at least a lot more than most people would at that age. He’s smart, he’s talented and he knows how to apply his skills. The one thing he doesn’t know yet, is how to deal with previous mistakes. And that is something you only learn once you’ve been working in a professional environment for a year or two, and if you’re lucky enough that people will challenge you and confront you with your mistakes. He may not have liked it, but i once caught him breaking the build and i told him he needed to fix it. He said it was a problem with subversion and that something must’ve gone wrong with the commit in question. I showed him that it was impossible that it could’ve been due to a problem with subversion and that he simply made a mistake in his commit. And while he probably still won’t admit it, he knew that i was right and that he was wrong. Now, there’s nothing wrong with a situation like that per se, but it was clear that he wasn’t used to a situation like that.

Think about it. You’re gifted. You’ve got a lot of talent. You’re pretty much better than anyone you’ve ever had to deal with at school. But the thing is, true improvement comes from learning from your mistakes, and you need to be in a situation where people aren’t afraid or too intimidated by your skills to be able to tell you when you’re wrong. If you don’t get confronted with your own mistakes, you are going to miss out on a lot of opportunities to improve yourself.

This guy made it very clear from the beginning that he wanted to pursue another degree after he graduated. And he’s currently doing that. The thing is, with the skills that he has, and the ability to convince other people of his skills, combined with the extra degree that i have no doubt he’ll earn this year, it’s very likely that he is going to end up with some large company in a very comfortable position. The thing that worries me though, is that a lot of people in those kind of companies aren’t very honest with their employees. Especially the ones they consider to be ‘high-potentials’. I doubt that he’s going to be around the kind of people who are going to be honest with him when he makes mistakes (and he surely will make them, as everyone does). And no matter how good you are, no matter how well you learn from your own mistakes, a very large part of self-improvement comes from being confronted with your mistakes by others.

So finally, we get to the ‘advice’ part of the post. To him specifically, and anyone else who recognizes himself (or herself) in a story like this i would advise the following:

• Do not automatically assume that a fancy position at a large company is the best situation for you. For most of these companies, you’re only valuable as long as you’re willing to play along with their game. It’s their game, their rules. You either play along, or you fold after a while, and believe me when i tell you that it is going to end up bothering the hell out of you.
• Learn to appreciate criticism. If you handle it right, you’re only going to end up better from it and you will truly learn from it.
• Status or position doesn’t mean anything if you suddenly realize you’re surrounded by idiots.
• If you don’t really need the extra money you can make while working for people who truly couldn’t care less about you personally, you certainly don’t need to subject yourself to all of the crap that will come with it.

I received an email from someone who wanted to let me know that she noticed that a coworker of her used all of the code from my Build Your Own Data Access Layer Series in their project without any notice of where it actually came from. The code in that series was posted using the Creative Commons Attribution license which only states one simple condition:

You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).

First of all, i don’t really get what this person was trying to achieve by notifying me of this. What am i going to do about it? Ask them to add a notice? Should i even care about it? I don’t, actually. If anything, i’m glad they’re using it and i just hope that it works for them and that they don’t run into any issues with it. If i didn’t want people using it, i shouldn’t have posted it. And as for adding a notice… that would be nice, but it’s not going to make any difference for me whether they do or don’t.

I think it’s different when you release code as an open source project. Then i obviously do want people to respect the license, but for blog code i don’t really care what people do with it. I did mention a license in the original post, but that’s pretty much only because some people don’t want to use it if there is no license mentioned. Which is correct, theoretically. But the vast majority of code that i list on this blog never has a mention of a specific license. It’s just too much of a bother IMO, and there isn’t anything that i can realistically do about it if people use it without respecting the license anyway.

So for future reference: feel free to do whatever you want with any code that i post on this blog, unless of course that code comes from an open source project. Would it be legal? No. Am i going to do something about it? No.

Michel Grootjans recently left the following comment on a post where i discussed a really stupid mistake i made:

Been there, done that, but never had the courage to post it.

That got me thinking.  What exactly is courageous about being honest about a mistake you made?  I mean, everybody makes mistakes and nobody is an exception to that.  Why do so many people try to hide this fact?

I used to work at a large financial institution where a lot of the people weren’t very honest about mistakes they made.  When things went wrong, a lot of them came up with excuses or denied outright that they had made a mistake and blamed it one someone else or on some other event.  That’s one of the worst things you can do if you ask me.  For one, it reduces your credibility and people will be less likely to trust whatever it is you say once they realize that you’re not entirely honest about such things.

One of the biggest mistakes that i made there led to learning one of my most cherished lessons.  I once accidentally truncated 4 large tables in a production database.  It was very early in the morning and parts of my brain must’ve still been sleeping.  I knew that the database operations guys were going to spend a lot of time on trying to fix things, and that it would be a very unpleasant situation for me.  When i called them, i just told them outright that i had made a really stupid mistake and that i needed their help.  It was pretty obvious that they weren’t used to someone actually telling them that and to my surprise, they were very cool about it.  They restored the 4 tables rather quickly and the whole situation was resolved without too many problems.  I told my superior about what had happened and that it was my own stupid fault that the application was down for a few hours.  He too took that rather well.  From that point on, i’ve made it a habit to just be entirely honest about every mistake or screw up that i’d make. 

For one, why on earth should i worry about what people will think of me because i made a stupid mistake?  Like i said, everyone makes mistakes and as long as you don’t make too many of them too frequently, there is nothing wrong with it.  And anyone who will think differently of you because of it is really just a hypocrite.  In fact, most people will respect you more if you are just honest and open about it.

As for writing posts about them… there are a few reasons why i do that.  First of all, by writing about them you are more likely to remember the mistake and you’ll hopefully won’t make it again.  Secondly, it’s typically an interesting opportunity for others to learn from as well.  Last but not least, by posting honestly about them i can hopefully show people that there really isn’t anything wrong with being honest about it and who knows, maybe even encourage them to do the same in the future when it happens to them.

But is it courageous? I don’t think so… If a certain action doesn’t justify any fear, then there’s no reason to consider doing so courageous either.

Oh, and if you want to read up on more of my mistakes, check out the following posts:

• My 2 most cherished mistakes
• How a simple foreach statement can waste an afternoon
• Do not dispose in the prerender event
• The importance of releasing your components through Windsor

Come to think of it, there should be plenty more of those… guess i gotta start posting about them more often

A mistake that you commonly see developers make (especially young ones) is to try to achieve perfection when they need to design something.  Whether it’s just a reusable base class, a component, or even a small library or framework, a lot of people get too caught up in details that don’t really matter in most cases.

It is understandable though, and i think most developers have gone down that path quite a few times in their careers.  Especially early on.  You know how it goes… you need to create something that is going to be reused by others, and you want to make sure that it is just perfect.  That nobody can say anything bad about it.  That everyone will agree without discussion that that piece of code is simply great.

So a lot of people in that situation start thinking about things like:

• Shouldn’t i seal this class? Nobody’s ever going to need to derive from this because i’ve left plenty of other extensibility points
• Shouldn’t i seal this method? After all, nobody should ever change the way this particular piece of code works
• This class will never be used by anyone outside of this assembly, so i probably should make it internal, right?
• This particular method will be a bottleneck so i should really make it as fast as i can
• Whenever i can pull some common logic in a base class, or introduce more base classes i should do so!
• Etc…

The reality of the situation is that despite your best intentions, focusing too much on details like that will quite frequently lead to very inflexible code that a lot of people will find hard or annoying to use.  Unless you are very experienced with this kind of stuff (and for the record, i’m not saying that i am) you’re very likely to get these decisions wrong if you think about them up front so it really isn’t worth spending so much time on ‘details’ like that.  In fact, the best thing to do is often to keep things as simple as possible until you actually have a reason to make them more complicated.  Making things more complicated than they need to be in advance never works, and you’re probably going to over-complicate things in places where it turns out not to matter.  If you’re really unlucky, that will actually make it harder to modify or extend other parts that over time really do need to be modified or extended in some ways.

Generally speaking, i think you’re better off focusing on the following goals/principles:

• Avoid writing classes that are slutty
• Make sure that your consumers primarily communicate with your classes through interfaces.  Though you don’t need to put everything behind an interface either… pretty much anything that people might need/want to change in some way typically are good candidates.
• Use Dependency Injection so implementations can easily be switched with others
• Use virtual methods unless you can think of a really good reason not to
• Don’t make your classes internal unless you can think of a good reason to do so (and keep in mind that we can still do whatever we want with them through reflection, and will do so if that turns out to be the best way to get something working the way we need it to if you failed to provide proper extension points)
• Do not seal classes unless you can think of a really good reason to do so
• Do not worry about performance up front, unless for those places where you are going out-of-process (remote services, databases, file systems, etc…)
• Keep your classes small and focused
• Learn about the SOLID principles, and apply them. Keep in mind that going for 100% SOLID code is typically not worth it either.  Go for the 80/20 rule here.

If you keep those things in mind, you will typically end up with code that is flexible to use, and easy to change.

Obviously, all of this assumes that you are in a position where you can go back to the code and make changes.  If you’re releasing frameworks/libraries/components that will be used by a lot of people and can’t afford to break backwards compatibility, then you probably need to be more strict about these things because then you can’t always just go back to change something.  I don’t think it’s a stretch to claim that most developers are not in this situation however, so most of us often don’t need to waste time thinking about those things in advance

A lot of us develop business applications, right? Ever got tired of the same old boring and traditional user interfaces that are used for these applications?  At Item Solutions we like to do things differently from what other companies are doing, and we apply that principle to our user interfaces as well.  One of my coworkers recently created a couple of screencasts of some of our Silverlight applications and i figured you might find them interesting.  You’ll see that in most cases, the way the data is presented isn’t quite how most applications do it, and the way you interact with the data is often different as well.  Not only is this more interesting to work on, most users actually love the user experience that these interfaces offer them.

Check out the movies, and if you want a bit more information on what these applications do, just click here.

CRM from itemsolutions on Vimeo.

Genesis from itemsolutions on Vimeo.

Glance from itemsolutions on Vimeo.

Emmaus from itemsolutions on Vimeo.

Synergy from itemsolutions on Vimeo.

Nokeos from itemsolutions on Vimeo.