But there are some things you need to watch out for in any organization which takes estimates seriously. Most development shops have estimates at the task-level. These task-level estimates are often used during the planning of the next iteration, but were most likely also used in the initial total estimate of the project. I certainly don’t doubt the importance of those task-level estimates, but i do think they should be used cautiously.

If too much importance is placed on staying below the estimates, or at least not going over them, you run the risk of growing a culture where developers let the estimates have too much influence on the quality of the work they’re doing. Some developers will strive hard to routinely stay below the estimates. Some developers will work in fear of going over the estimate. In both cases, it leads to technical shortcuts that will be taken. Those shortcuts will consist of skipping some tests here and there, skipping a bunch of tests altogether, decreasing willingness to refactor code that could use it and worst of all, no longer keeping a clean design in mind. Granted, i’m painting a very bleak picture here but it does happen with some people and the negative results can not be underestimated.

Let’s consider the overall effect of these shortcuts. A shortcut here or there is not abnormal in some circumstances, but it should be exceptional. It should not become routine, it should be frowned upon and i’d even go as far as recommending a “no shortcuts allowed unless the team approves of it” policy. A shortcut here or there doesn’t take a lot of effort to fix and because of this, it can often be done as soon as the original reason of the existence of the shortcut (typically: a deadline) is no longer an issue. An accumulation of shortcuts however leads to not only an obviously bigger workload to fix all of the shortcuts, but it also impacts a lot of other code that shouldn’t have been impacted in the first place. Once this happens, you’ve got yourself an unhealthy code base and it’s only going to get worse until it eventually dies at a younger age than it could have reached.

Now, imagine a culture where estimates are given as much importance as quality. If you’re approaching the estimate and you’ve still got a lot of work left to fully complete the task (and with fully completed, i really don’t mean watching it work on your machine as you manually test it), then you consult with the rest of your team members. Estimate how much time it would take to fully complete the task, and see if the increased time over the original estimate is doable. If you’re already behind your overall schedule, it’s probably not doable unless there are many subsequent tasks that are dependent on this particular task. But if you’re ahead of schedule, you’re probably better off accepting the fact that you’re going to go over this task’s original estimate in order to do it right. If you do so, the extra hours you spent on this task should (in most cases at least) not lead to extra hours on future tasks. Conversely, if you’ve finished a task well below the estimate, it might actually be a good investment to refactor some ‘bad’ code that you’ve come across while working on your task. Or to add some missing tests here or there. That certainly doesn’t mean that you need to spend all the available remaining time you have but you shouldn’t run to start on a new task as soon as humanly possible either. Follow the boy scout rule here… you won’t spend that much extra time on it, but overall quality can improve greatly from this.

In fact, i’d even bet that the time it takes to do it right will in a large majority of cases still be less than the sum of the original time that was spent on a task hastily done and the time that will be spent on bugs that resulted from that hastily done task, not to mention the impact it could have on the development of future tasks simply because of the suboptimal implementation of the hastily done task.

Finally, it’s also important to think about why there was a need to go over an estimate. There can be a variety of reasons for this, and one of them is that the task was simply badly estimated. If that indeed turns out to be the case, make sure that you learn from it to prevent this from happening in the future. When we find bugs in our code, we try to prevent those bugs from ever occurring again. We should have a similar attitude to our estimating practices as well. If an estimate was simply too low, make sure that a similar task in the future won’t be estimated too low again or you will again introduce a possible problem in your (future) project.

And that, in my opinion, is also a good reason to decide to go over the estimate if you can. If you go over the estimate and all people involved learn from the bad estimate, then everyone basically benefits from it. Future estimates should become more accurate, and no code was harmed in the process. You might have lost some money on it, but at least you only lost it once instead of losing it over and over again in similar future circumstances.

There’s nothing wrong with putting in a few extra hours occasionally. Sometimes, it just needs to be done. But, as soon as it is required more than occasionally (and with occasionally, i mean every couple of months), something is wrong. First of all, you’re not gonna produce anything good if you’re doing a lot of overtime. At first, it starts with a couple of late nights. The first couple of nights, the work you do is still ‘good enough’. It’s not gonna be great, but hey, it’ll do. After a couple of nights though, if you’re still doing a lot of extra hours, there’s gonna be a noticeable negative effect on the work you’re doing. And you know what the worst part is? You, of all people, won’t notice it. You’re working hard, you’re trying to catch up with the schedule, and you’re doing the best you can. Or at least, you think you are.

In reality, you are hurting yourself, the project and your teammates more than you could imagine at that time. Here’s the deal: there’s a reason why most people are working 8 hours a day on average. If you routinely work more than 8 hours a day, your work is going to suffer from it (it depends on the job obviously, but for software developers, i’d argue that this is definitely the case). If you do a bit of overtime occasionally, then you, nor the project will suffer from it. It’ll just take a little bit more out of you than what you’re used to. But once it becomes a routine, you, as a human being, will start performing worse and worse as time goes on. Inevitably, that deterioration will become very noticeable in your work. And here’s the sad thing: you’re putting in the extra effort to catch up with the schedule. But by doing so, you’re actually performing worse and you’re hurting the schedule. Here’s what happens: you spend a few late nights at the office. At first, things go ok. You’re getting things done and it appears to be working. You keep spending late nights at the office. After a few days (really, it happens that fast), the quality of your work starts deteriorating. And you won’t notice it until you get back the next day. So then what happens? You start cleaning up the mess you made the night before. Which only means you’re getting even more behind schedule. So then you’ll need even more time to catch up with the schedule. But you’re already spending this much extra time at work, and the problem only seems to get worse! Well, yeah… that’s the whole point that i’m trying to make here. You know what’s the best thing you could possibly do in those situations? Go home at 3 or 4 in the afternoon, go have some fun, relax, and get a good night’s sleep. You won’t believe how much more productive you’ll be the next day.

But where is this need to do overtime coming from? I’d argue that, in the large majority of cases, this is due to management mistakes. Either the wrong things were promised to the customer, or your management doesn’t have a clue of what is really going on. So, if you find yourself in a position where you routinely need to do overtime, you really need to start asking yourself whether or not you’re working for the right company. If you routinely need to do overtime to reach a deadline, that tells you that the project management (and highly likely, every kind of management beyond that) is pretty messed up. I don’t know about you, but i really don’t want to work for people who don’t know what they’re doing. If you’re doing a lot of overtime, your management is either clueless or stupid. Probably a combination of both.

As for the developers who are proud of their 60-80 hour work weeks… what does that tell you about them? There truly are very few people who can keep on producing great results beyond the regular 40 hours a week. Something tells me that very few of those developers who brag about their extra hours really fit into that category. If they really did fit into that category, they’d let their results speak for themselves instead of needing to brag about the amount of effort they’re putting in.

And indeed, if you browse the web to find the reason why application pools are configured to recycle automatically periodically, you’ll be hard pressed to find a reasonable answer that doesn’t pertain to memory issues.  It’s like the community in general has pretty much accepted the fact that our web applications (or service layers hosted in IIS) will need to be recycled to avoid memory problems.  To make things worse, i’ve frequently seen people discuss workarounds on how to keep things working properly after an application pool recycle in mailinglists for various projects.  And again i ask myself: why?

I’ve always been of the opinion that if your code requires periodic restarts to keep working correctly, then something is clearly wrong.  There is a bug in your code somewhere and you need to fix that, instead of restarting the process occasionally to make the problem ‘go away’.  Guess what, it’s not going away, and if the load on your application increases, the problem will only pop up more frequently.  So what are you going to do about that? Make the application pool recycle even more frequently?  Put in another server to share the load?  Perhaps we should focus more on fixing the actual code.  You’re leaking resources somewhere, and that is what you need to fix.

In my company, it’s just standard procedure to disable application pool recycling on all application pools.  Our applications simply have to keep working without application pool recycles.  It’s that simple.  If we run into a memory leak that causes problems, we focus on the actual problem and we fix it.  We’ve ran into plenty of memory leaks (though it hasn’t really happened a lot in the past year, guess why?) and we’ve fixed each and every single one of them that we’ve ran into.  Side note: i’m talking about .NET code that is running on the server.  While i’m pretty sure that we do better at memory management in our Silverlight clients than most other Silverlight-using-shops do, you just never know for sure with Silverlight, partly because there are so many memory leaks in Silveright itself.  But for .NET code running on a server, a memory leak is simply inexcusable in my opinion.  I mean, it can happen to the best of us (i’m pretty much responsible for most of ours to be honest), but it’s not about who introduced the memory leak.  It’s all about how you deal with it.  And recycling the application pool periodically is not dealing with it, it’s living in denial.

The only viable reason to recycle application pools that i can think of is in the situation of a shared hosting provider.  If you’re offering shared hosting, it only makes sense to recycle application pools occasionally since it’s quite realistic to assume that most of those application pools will not be in use constantly.  If a pool is recycled, it will not consume any resources until the next request for an application in that pool is received.  In the context of shared hosting, that actually makes sense.  In the context of real applications, that makes little sense unless you’re hosting a lot of them and plenty of them are hardly being used.  Still, is that really a good enough reason to enabling application pool recycling by default?  I obviously don’t think so.

In my opinion, we, as a community, really need to start focusing more on memory management in .NET and on making sure that our applications can keep running without problems.

I have a very simple rule when it comes to avoiding hype: if you can’t say something bad about it, you don’t know it well enough (yet).  And until you are able to say something bad about a library, framework, approach, technology, tool or whatever, i simply can’t believe all of the good things you’re saying about it without some form of skepticism.  In life, nothing is perfect.  In software development even less so.  Every single piece of technology or approach has its drawbacks, issues and problems.  And quite often, those things only become noticeable after having truly used it on a real project for a while.  I think most of us will be able to agree on that.  So really, what does that tell you about someone when that person is extremely positive about something, without being able to mention any downside?  That either tells me that you don’t know what you’re talking about or that you’re not even using whatever it is that you’re hyping on something real (hobby projects don’t really count).  So does it really make sense for one to listen to it?  Conversely, if you are very positive about something but are also able to mention the negative points that you’ve encountered (they don’t have to be huge, and can in fact even be minor) then i’m immediately much more inclined to believe what you’re saying. 

Granted, my approach frequently prevents me from being an early adopter.  But if/when i do become an adopter, i will be a pretty informed one.  In many cases i’ll know about the negatives before they bite me, and will either guard myself against them, work around them if i have no other alternative or simply choose to ignore the technology altogether if the positives don’t outweigh the negatives.  The only downside that i’ve experienced so far from this approach is that i’ll never be one of the cool kids on the internet and among the hype-hungry developers.  Then again, that’s probably more of an upside than a downside, come to think of it

Looking back over the past 5 years or so, i can say that i was late in adopting unit testing, agile development, Inversion Of Control, Dependency Injection, ORM, and probably a bunch of other things that i can’t really think of right now.  But i’m pretty sure that i know all of those things pretty well by now.  A large reason for that (i think) is because i took my time and made sure that i made informed decisions before adopting something.  I experimented, thought about drawbacks, tried it in real projects, learned from mistakes that i made, worked around problems that were inherent with the piece of technology or approach in question and only then did i consider myself able to make informed statements about it.  That doesn’t mean you can’t talk about something that you don’t know fully yet.  A lot of very valuable blog posts are written by a lot of people who are learning things or are just experimenting with things.  The smart ones among them though, will be very honest about how much they know about it, how much they don’t know about it, and how far they are in the learning progress.

So, as Public Enemy said: don’t believe the hype!

Get informed instead.

I can only speak from my own experience, but i frequently isolate myself from my coworkers and my surroundings by turning on my iPod and listening to some music while i work.  I don’t do it all the time, and it definitely depends on what i’m working on, or who i’m working with.  Obviously, if you’re doing pair programming then listening to your iPod is pretty much out of the question.  But if you’re all sitting together, do we really need to avoid any kind of isolation?  When i’m working on something complex, and i don’t really need to communicate with my teammates at that time, then there really isn’t anything wrong with listening to some music and getting some work done.  In fact, it often helps me focus on my work without getting easily distracted, helps me get into a good zone, and it would certainly surprise me if i were the only one who thought that way.  If you or some of your teammembers actually produce better results while they tune into their music, then this can’t really be an inherently bad thing, no?

But obviously, there will be many situations where you actually want to avoid listening to music.  Sometimes you might be working on something that requires you to consult with teammates frequently, whether it is about design decisions or to ask some feedback on implications of certain implementation details.  In those cases, you can end up pausing and resuming your iPod way too frequently so it might just be better to refrain from turning it on altogether.  Or when you notice that teammates are discussing something and it’s taking them a bit too long.  It’s hard to tell when a discussion is too long if you’re not hearing what they’re saying but when i notice 2 developers talking for more then a couple of minutes, i’ll often pause the iPod to check out what they’re talking about.  Maybe you can help by offering a different perspective or maybe you know an immediate answer to the question that they’re discussing.  If you can’t help, go ahead and press Play again.

The thing is… even if you do tune into some music at work, it’s important not to tune out of your coworkers completely.  Go ahead and listen to your music, but keep looking around occasionally.  Turn it off when you notice your teammates are talking and follow the discussion to see if it’s interesting to you or if you can help them.  Conversely, if you’re participating in a discussion and you notice that one or more of your teammates is listening to music while they should probably be involved or at least hear what the conclusion or decision was, go ahead and notify them of what’s been discussed/decided/concluded.  Also don’t be afraid to involve people who weren’t involved yet if you think that it might be important to them.  If it turns out that it wasn’t important to them, then all you’ve lost is a few minutes.  But if it was important to them, you might have saved a lot more than a few minutes by pulling them into the discussion.

As for sitting in a separate office… i’m not a fan of that.  I’ve always noticed the best results are achieved when all of the developers are sitting together in the same office.  In some organizations, senior developers, lead developers or ‘architects’ might be sitting in different offices from the people they’re supposed to be working with.  I don’t know about you, but i’ve never actually seen that work properly.  The typical on-the-floor communication that is so vital to successful teamwork is just reduced a lot of if some people are sitting in a different office.  Obviously, when working with remote coworkers, this problem only increases but that’s something i haven’t really found an efficient solution for either.  In some cases, communication through IM works great.  And sometimes it doesn’t.  It depends on how effectively you can communicate through IM, and how effectively the others can. 

But anyway, when you hear people talk about how developers that isolate themselves at work is a bad thing, don’t necessarily buy into it.  Like i said, it can be good or it can be bad.  As with anything in our business, it all depends.

I looked at the new WCF 4 features so i could see how Agatha could benefit from it, but apart from the improved REST support (which Andrew Rea is working on), there’s nothing that Agatha could really benefit from. Perhaps maybe the fact that you can reduce XML configuration for your WCF services but then again, the amount of XML config that you need for Agatha is already very limited compared to typical WCF services and the parts that you do need are things that i actually prefer to see explicitly in a configuration file instead of hidden away in some infrastructure assembly that your project is using.

As for the new language features… i like the whole dynamic thing, though i haven’t found a need to use it yet. The next time i see some old reflection code i’ll probably modify it to use dynamic, but i don’t really need to use tricks like that very often. Optional parameters are something that i can’t really get excited about, perhaps because i hardly ever use interop and more likely because i still believe in meaningful method overloads. In fact, it sometimes makes me think that C# 4 is moving closer to Dysfunctional Programming as opposed to at least being influenced by Functional Programming in C# 3. Named Parameters is something that i can see myself using to increase readability when it comes to using multiple overloads with confusing method parameters but that as well is something that i don’t frequently run into.

The greatly improved support for parallelism looks very nice, though i haven’t really needed that either. The new thread-safe collections look nice too, though every time i want to modify some code to make use of it, i notice that i typically need my locking to be just a bit more coarse-grained than what i can get from the new collections. Unless i haven’t looked hard enough of course, which is certainly possible.

As for Visual Studio 2010… from a performance point of view it is somewhat better than i expected but i really can’t say it’s an improvement over Visual Studio 2008 (again, from a performance point of view). I occasionally notice about 25% CPU usage (on a quad core system, so that’s pretty bad IMO) coming from devenv.exe while it isn’t actually doing anything. I can’t really say that i’m happy about that. The default color theme looks butt ugly IMHO, but at least there’s a plugin to change that. Which i haven’t actually done yet though

Now the thing is… maybe it’s just because i haven’t looked hard enough, or that i’m missing some cool new stuff, but isn’t this very different from when .NET 3.5 came out? The Linq extension methods and the ability to use Expressions was highly welcome and i guess a lot of us kinda went overboard with it (and some probably still do). But at least that showed that those new features were not only highly welcome, but very popular and in general just great new additions to the C# language. But with .NET 4 i really find it pretty hard to find anything to get really excited about. And just to be clear on this: that’s not to be critical of Microsoft or anything like that. But i’m just wondering: “is it just me or is this really not that special?”

So what do you think? Are there great new additions to C#/.NET that i’m probably missing and that you are enjoying a lot? What are your favorite additions to the platform? Or are you, like me, not really all that excited about the new stuff?

In this post, i’d like to take the chance to explain the downsides to exposing entities through services.  Though i’ll probably miss quite a few of the downsides (feel free to add to the list through comments), the ones i will mention are IMO important enough to take note of.

Exposing entities to clients means your clients are very tightly coupled to your service(s)

Entities are a part of your domain.  These entities in your domain can change for various reasons.  Sometimes because functional changes are required, but quite often also for optimizations (whether they are for performance reasons or to improve the clarity and maintainability of your domain).  Functional changes can impact your clients, though that is not necessarily the case.  Optimizations hardly ever have an impact on your clients (other than possibly improved response times from your service calls obviously).  If your service layer accepts and returns domain entities, each possible change is highly likely to have an impact on your clients.  And this impact is not cheap.  In the best case scenario, it means updating your service contracts, regenerating your service proxies and redeploying your clients.  In the worst case scenario, it means making actual changes to the code of your clients.  And for what? Because of changes that shouldn’t have impacted your clients in the first place?

Ideally, your clients are as dumb as they can be.  They should know as little as possible about the actual implementation of the domain because that implementation is simply not relevant to them.  They should present users with data and give them the option to modify that data, to trigger actions and to perform certain tasks.  They should focus squarely on those tasks and pretty much everything else is typically better suited to be done behind your service layer.  If you build your clients with no real knowledge of the actual domain model, but of DTO’s and possible actions to be performed then you can reduce the level of coupling between your clients and your services substantially.

Many of the people who prefer to expose entities often claim that going for the DTO approach introduces too much extra work and too many extra, seemingly unnecessary classes.  For starters, they don’t want to write code that maps entities to DTO’s.  First of all, the amount of code that this requires is in reality very small, not to mention very easy.  Secondly, you can just as well use a library such as AutoMapper to take that pain away from you.  And contrary to what you might think, there is a big performance gain to be had from returning DTO’s over entities, but i’ll get to that in the next section.

Entities are hardly ever the most optimal representation of data

I think we can safely say that most applications need to show data in the following 3 ways:

• In a grid view, either as a total listing of all instances of a certain type of data or the result of a search query or some kind of filtering action
• In dropdown controls or anything else that lets users select pieces of data
• In edit screens where a piece of data needs to be displayed in its entirety, perhaps even to be modified by the user

There are undoubtedly more ways in which data can be presented to the user but i think it’s safe to say that most business applications will certainly rely on the following 3 ways quite heavily.

In the case of a grid view, you’re frequently showing data that is related to more than one entity.  You’ll often need to include the name or the description of some associated entities.  So what exactly is it that you want to do in this situation?  Do you want to return a list of the main entities of the grid view, which all have their required association properties filled in so you can display the columns that you need in the grid view?  Do you actually need all of the properties of these entities (for both the main entities and the associated entities)?  Odds are high that you’re going to be returning a lot more data to the client than you actually need.  And that is what is realistically going to hurt the performance of your system.  Any piece of unnecessary data that you transmit to your clients has a cost associated with it.  The unnecessary data is retrieved from the database.  The entities are then serialized at the service end.  Then they are transmitted to the client.  Then they are deserialized by your client.  All of this is pretty costly, so the more unnecessary data that is included in this operation, the more your performance and the responsiveness of your client (not to mention your database and your server) is impacted negatively.

In the case of dropdown controls or anything else that lets users select pieces of data, you typically only need very few of the properties of that piece of data.  In many cases, the primary key and a name or a description are sufficient.  Do you really need to transmit the entire entity every time for usages like this? Again, keep in mind that all of that extra data that will never be used by your client needs to be retrieved, serialized, transmitted and deserialized again.  Surely, this is an awful waste, no? 

And then there’s the case where a piece of data needs to be displayed in its entirety.  In these cases, you will almost always need all of the properties of the entity that is displayed, but you’ll most often also need to show other data (things that can be selected, or linked to the main entity).  This other data will in most cases fall into the previous category where you’ll only need very little information about the actual entity.  If you’re smart, you’ve chosen the DTO approach to retrieve this data for the data that can be selected, and in that case, you already have all of the infrastructural code in place to project entities or data into DTO’s.  So you might as well reuse it for the main entity as well since you already have the capability to do this.

Always keep in mind that your entities will frequently either contain more data than needed, or less data than needed.  As such, it just doesn’t make much sense to expose entities to your clients since they are hardly ever optimal for client-side usage.  If you really want to think about performance, stop worrying about the supposed cost of mapping to DTO’s (which is truly negligible) and start focusing on what your actually sending to and from your service because this is far more costly than any kind of DTO-mapping really is.

Must your data really come from entities?

If you are displaying data to your user, does that data really need to come from your domain model?  Does it really need to be retrieved by populating a collection of entities to then return them to the client?  Again, keep the form of the data in mind when thinking about this.  In many cases, as i mentioned above, an entity is not the most optimal form of the data that your client needs.  So why even retrieve it through entities? Sure, asking your ORM to retrieve a set of entities based on a set of criteria is often the easiest thing to do, but if the easiest path were the best path, the overall quality of software projects wouldn’t be in the sad state that it’s in today.  If the form of the required data is not identical to the structure of an entity, it’s often far more optimal to simply populate a DTO directly from the data.  With NHibernate, you can easily do this by adding a list of projections to your query and then using a ResultTransformer to populate the DTO’s based on the direct output of the query.  In this case, no entity instance ever needs to be created when you’re just retrieving data, and no extra mapping between the entity and the DTO’s needs to be performed.  Your data access code simply retrieves the resulting data from a query, and puts that data directly in your DTO’s.  There’s no reason why usage of an ORM should prevent you from doing this.   Once again, this approach will offer far more performance benefits than avoiding DTO mapping at all costs ever can.

What about the behavior of your entities?

Do your entities have any behavior in them?  If not, they are already more of a DTO than a true entity.  In fact, if your entities have no behavior at all, you could even wonder why you’re using an ORM in the first place.  Now, behavior can mean many things.  It could mean lazy loading of associations.  It could mean actual business logic.  Obviously, lazy-loading doesn’t (and shouldn’t!) work client-side, but what about your business logic? Do you have business logic that can be executed client-side? Or is it business logic that should only be executed behind the service layer? If so, how do you make the distinction between this to prevent client-side usage from these entities? Whatever you do, you’re pretty much opening up a can of worms that really is better avoided in the first place.

How are you going to deal with technical issues?

Accepting and returning entities from services introduces a host of technical issues that can be quite substantial.  Serialization and deserialization specifically are issues that you need to be worried about.  If you’re using an ORM which does lazy-loading of associations, this will certainly cause serialization issues that you need to work around.  You can either disable lazy loading, or you can make sure that your entities are always fully initialized (as in: always have their associations fully loaded) before they are sent back to the client.  Disabling lazy-loading will cause performance problems in your service layer, either in places where you don’t expect them to be or in places that you haven’t thought of before it’s too late.  Fully loading your entities and their associates before returning them is another performance nightmare waiting to happen so that’s really not an ideal solution either.  You can try to hook into the serialization process or even the lazy-loading features of your ORM but whatever you do in that case will be a hack that will cause issues sooner or later.  And again, all of these problems can very easily be avoided with a solution which, i hope you realize by now, offers plenty more benefits than any solution where you accept/return entities in your service.

Conclusion

Every single downside to exposing entities through services are issues that i have myself encountered in past projects, either ones i’ve worked on myself, or ones that i’ve seen other people work on.  If that’s not enough for you, then maybe you’ll find it interesting to know that some of the brightest and most respected people (like Udi Dahan and Ayende for instance) in the .NET community also actively recommend against exposing entities through services because of the same downsides that i mentioned, though they could probably give you even more downsides that i forgot to cover in this post.  These downsides are not figments of anyone’s imagination.  They are very real, and you really, really ought to think twice before dismissing this advice. 

My architecture at works requires a web app and a windows app to talk to the application server via WCF. The Application server being where all the Data access and Service libraries live. I intend to implement NHibernate into the project. But wanted to get some pointers if your approach above is recommended for Web and Windows clients alike when sending and receiving data via WCF?

The short answer to that question is simply: It sure as hell is!

But you know i always prefer the longer answer .  The type of client always has an impact on the usage patterns of the service(s) that it needs.  A web client will often have a different usage pattern than a windows client or a mobile client will.  Each client should be able to consume the service in the manner that is most suitable to its requirements and constraints.  A web client is (or should be) completely stateless so a service that is meant to be used by a web client is typically geared towards that stateless model.   Windows clients or mobile clients are typically not entirely stateless and as such, the way they could use a service in the most optimal way often differs from how a web client would use the service.

One of the most important SOA principles is that there should be no implicit coupling between a service and its client(s) at all.  Generally speaking, coarse-grained operations are favored over fine-grained ones due to the cost of the communication overhead.  Yet, that easily conflicts with the usage patterns of different clients.  Since a web client is stateless, it often needs more coarse grained operations than a windows client which can retain data in its own process memory and thus, might benefit more from calling a fine-grained operation here and there.

Obviously, my solution to that problem is Agatha which makes it possible to implement each operation (or call them actions or commands and queries or whatever else you can think of) in the way that just makes the most sense, no matter what kind of client is going to call them.  Each client can consume the service operations in a manner that is optimal to the client, without the typical design impact and overhead that you have with traditional WCF services.

We have a few services that serve multiple types of clients.  ASP.NET pages.  Silverlight applications. Windows Services.  WPF tools.  Outlook add-ins.  And guess what?  Those services don’t have a clue as to who or what is using them and they are all implemented in the same way.  And it hasn’t caused a single problem or difficult design decision (as to the service API) yet.

If you’re a company or an individual who’s looking for an easy way to make a few extra bucks, just create your own certification! The only reason certifications exist is to make more money and there is no reason in the world why you wouldn’t be able to do the same.  Want some proof?  People are paying money to go to a 2 day course which ends with them being proclaimed Certified Scrum Master.  Obviously, most people who’ve actually given it some thought know that it’s a pretty meaningless certificate but hey, plenty of people are willing to pay for it, so why not take advantage?

Suppose you’re a developer who’s primarily interested in getting a nice cushy job for some company where it’s easy to get away with incompetence or an actual lack of demonstrable progress.  The best possible thing for you to do is to get yourself a couple of buzzword-laden certifications, apply with some big companies who’s core business is not software development and that’s it.  You’re pretty much set for life if you want to.

Suppose you’re a developer who’s primarily interested in interesting work.  Simply stay away from every job that lists one or more certifications in its requirement, or even hints that certification might improve your chances of being hired.  Ignoring those kind of jobs probably improves your chances of interesting work by a significant amount and as a bonus, you relieve yourself of the pain of having to deal with people who value certifications.

If you’re a company who’s looking to hire somebody or some other company to develop some software for you, while you have absolutely no idea where you should go, what to look for, and simply don’t want to get fired, then just hire the company that can show you the highest number of certifications.  The software that will be delivered might suck or it might not.  But one thing is for sure: you will not get fired if the software turns out to be a mess.  After all, you hired certified professionals so surely, you can’t be blamed for this fiasco.

As you can see, the certification game really does provide plenty of positive opportunities for a variety of people and interests.  The only people who don’t benefit from the certification game at all, are end users and consumers.  But then again, this industry has a very strong history of not caring about them anyway, so that’s not really a problem we should care about, right?

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.

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

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

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. 

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”. 

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.

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.

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

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

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.

In the software development industry, many of the large corporations have been quite busy on the software patent front in the last couple of years. Every single idea or innovation that those companies could get patented has probably been patented by now. And for what? What’s the large scale benefit that has come from it? Some small companies have won patent suits against big companies. And who benefited from that? The consumer? Not really. A very large minority of people benefited from software patents on a financial level at best. Our industry sure didn’t benefit from it. The consumer sure as hell never benefited from it.

I’ve always compared software patents to nuclear weapons. Every large country wants them, yet nobody truly wants to use them unless they have no other choice. If a large country ever uses nuclear weapons, they know that retaliation will occur and that there is no true benefit. In the case of nuclear weapons, once they are used everybody loses. It’s pretty much the same thing with software patents. Some small companies who are only interested in a quick profit will be glad to use them, but only if they know damn well that they can’t get hit with a counter-suit for patent infringements that they might have been guilty of. But big companies? How many of them have truly benefited from them? The only value they’ve shown to have so far is as a defensive measure. As in: if you sue us for patent infringement, you know damn well that we will counter sue you based on the patents that we have and that you are surely violating. A nice example of that is the current Apple-Nokia dispute which will end up costing only Apple and Nokia money and not a single consumer is actually going to benefit from that. The only people that will truly benefit from it are the lawyers representing both parties.

So really, what’s the point in software patents? Microsoft has amassed a boatload of patents in the past 10 years or so, and what do they have to show for it? They lost one patent dispute which prevents them from selling certain version of MS Word and none of the patents they hold is going to save them from that particular ruling. In fact, can you name any situation where a big company truly benefited from a software patent they hold? Sure, Amazon has its One-Click patent but that didn’t really prevent other e-commerce sites from offering a highly usable alternative. I can’t really think of any other situation where a patent has really benefited a large corporation.

The only people who’ve truly benefited from software patents so far have been niche companies who happened to got lucky, and lawyers representing both sides in the disputes. That’s it. If a small company or individual happens to have had a certain idea or implementation patented at the right time, they could simply wait long enough until they could sue a large company for infringing on their patent and watch the money come in. The large companies (you know, the ones we buy our products from) simply add their expenses to the cost price of the products that we buy. Does that sound fair to you? And before you go all “we should protect individuals and small companies” on me, think very carefully on how many of those patents have been awarded in a fair manner. I don’t really follow software patents that closely, but as a former Linux user who was concerned for some of his favorite software projects, i’ve seen my share of awarded patents where there truly was quite a bit of ‘prior art’ that should have prevented the patent from ever being awarded in the first place.

The thing is… if you have a great idea and want to profit from it, then you need to market it right and provide the best possible consumer experience. You know that countless competitors are going to copy your ideas, and most of them will do it without being guilty of infringing your worthless patent. No matter how valuable your idea is, it doesn’t mean anything if the total package doesn’t entice the consumer to purchase your product over someone else’s. So why even bother with software patents in the first place?