So as I was browsing through a few possible alternatives for my authentication needs, I started thinking about my thought process when evaluating libraries/frameworks to use. I generally base my decision on the following items, listed in order of importance (to me):

• How well does it work for my scenario? If a library satisfies all other items on this list, that certainly doesn't mean it's an automatic lock. How it works and the impact it has on my code is definitely the most important factor.
• Popularity. I've noticed that I let the number of watchers/forks on sites like Github influence my opinion. If a project has many watchers and many forks, odds are high that there's a relatively large group of happy users as well as people involved with the project. It also increases the odds that the project will be around for a while. Of course, inactive Open Source projects often remain available as well but if nobody's working on it, I'm not exactly tempted to take a dependency on it. Log4net is a notable exception to this, obviously. But when a project has a lot of people interested in it, or better yet, contributing to it, it's a good sign that you'll easily get help if needed, it's only going to get better in the long run and that it might get forked should the original developers stop working on it. As the author of an Open Source project that doesn't have a lot of watchers/forks (Agatha), I'm aware that my point of view on this is rather hypocritical but hey, it is what it is.
• Code quality. I don't have the time to do an in-depth review of the code as I'm sure most of us don't do either. But I do like to glance over the code to get a general feel of the quality of the code. I focus mostly on the clarity of the code and also keep an eye open for sloppiness or downright WTF's. I guess the questions I'm mostly trying to answer when doing this are: "is this code I'd like to try to improve or fix if I need to?" and "how easy would it be to debug this when I need to troubleshoot some non-obvious issues?".
• Location of code and issue tracker. A lot of people will probably take issue with this, but I consider it to be a major plus if the project is on Github. Not just because of my personal preference of Github, but because they truly encourage people to collaborate and contribute to projects and they make it very easy to do so. Also, the site is fast! I cringe when I have to look over issues of projects on Codeplex because it's just terribly slow. And the UI doesn't come close to that of Github either. I've heard that Bitbucket is pretty similar to Github, but I've never even looked for projects there. In any case: I want to be able to download the latest version of the code at any time, or of a particular branch if I need to, as easily as possible. I also prefer an issue tracker which is fast, responsive and easy to search. It doesn't have to be Github, but those 2 requirements are important to me.
• License. If it's GPL, I don't use it. Also, I check whether or not a commercial license needs to be purchased when you want to use the library/framework in production. Pay attention to dual-licensed projects because that Open Source license might not apply to commercial/production use!

I'd love to hear your thoughts on this. Did I miss any important factors? I just quickly put this post together so it's likely that I missed some good ones

The simplest, and probably most effective example is that of giving developers SSD's instead of regular disks. I'm willing to bet that using an SSD instead of a regular disk could save an hour of lost time per day, per developer on average. Suppose the hourly cost of a developer is 80€. Now suppose you have 30 developers in total. That would be waste of 2400€ a day. Now suppose you have to buy 30 SSD's at 300€ each, which would set the company back 9000€.

That 9000€ investment will have paid itself back after 112,5 man-days, which is only 5 calendar days if you have 30 devs. After those 5 calendar days, the investment starts reducing development costs with 2400€ a day (on average), which for a full year (using 220 working days) could result in a yearly saving of 528000€ for the company.

Of course, Operations is usually a separate division from those that are responsible for development, which means that they have a separate budget sanctioned for what they need to do. Now suppose that Operations has to spend about 5000€ per year to replace failed SSD's. And lets assume that the yearly support cost for those SSD's is 20000€. I pulled that number out of my ass, which unless I'm mistaken is standard operating procedure whenever an Operations division gives you an estimate of support costs. Anyway, it would mean that on top of the 9000€ investment, a yearly recurrent cost of 25000€ would need to budgetted. And for what? The Operations division can't demonstrate a single benefit for their division to justify the cost.

Nevermind the fact that the company would save about 500000€ a year...

The biggest problem in the .NET world is that most companies that do .NET development just stick to what Microsoft tells them to use and how to use it. Many .NET developers largely focus on that, because they know all too well that it increases their odds of getting hired. And let's face it: Microsoft has a solution for practically everything. The only problem is that those solutions are rarely the best in what they're trying to solve. But hey, no manager gets fired for going with Microsoft, right?

The result is that there are too many companies and too many developers that focus only on what Microsoft offers. But there's a lot more to software development than what Microsoft offers, or even knows about. There are countless examples of Microsoft being late to whatever technical party is interesting at the time. And when they show up, they certainly don't always make a good impression.

If you're the kind of developer that likes to learn from what other software development communities are doing, odds are high that you're screwed. There is an interesting OSS community within the .NET world, and they frequently produce great solutions, quite often based on succes stories coming from other development communities. The problem is not that .NET developers don't have great solutions available to them. The problem is that the majority of them simply don't know about them only because there hasn't been any Microsoft hype about it, or that the devs who do know about it aren't allowed to use it because their managers are sceptical about it, most likely also because there's no Microsoft backing for the technology or architectural style that is being proposed.

I'm not advocating the avoidance of Microsoft products or solutions. By all means, use Microsoft products if they are indeed the best solution to your problem. But do be aware of the things that are getting attention outside of the Microsoft sphere and use them when it makes more sense to use them. That's the essence of the 'non-typical .NET job' and that's exactly what makes it interesting: using the right tool for the right job.

We mostly cared about getting our assignments working. When you completed an assignment, you moved on to the next one and none of the code of the previous assignment really mattered anymore. Maintainability or even readability were things that never even occurred to us. Maybe a few of the teachers tried to tell us about it at some point, but it certainly didn't stick.

In the final year, we could pick a project to work on for the majority of the year. There were no limits on the assignment, so most people picked something that interested them. I was pretty interested in manager/simulation games, so I figured I'd just build my own Formula 1 manager game. The player would get full control over a F1 team, which in my game meant:

• picking the suppliers for tires, fuel and engines, all of which had varying levels of quality and costs associated with it
• hiring a chief-designer, chief-mechanic and drivers, all of which had a specified talent level and negotiations took the results of the team's previous year into account, as well as the results of the potential hire's previous team, which influenced prices and negotiation tactics.
• landing sponsors, some of which were more than happy to sponsor your team depending on last year's results, or wouldn't even answer your calls and they all had varying budgets as well

I came up with a pretty good formula to simulate realistic race results based on all these factors as well as a dose of luck, or bad luck. If you played for a few seasons, the decisions you made all added up nicely, and gradually. When the project was due, it all worked. Since I loved playing those kind of games, I tested it very extensively by playing it regularly. When issues came up, I'd fix them. When I thought of improvements, I implemented them. I delivered something that worked, and that was large enough in scope and complexity to be impressive for a school project.

But the codebase was truly atrocious. I wasn't using proper structures for either data or behavior and I ended up with a shitload of extensive multi-dimensional arrays. All of my types were in those arrays, as I just didn't know yet that they should've been types of their own. Of course, I listed all of the indices on pieces of paper so I'd know which data properties corresponded with each index. Behavior was all implemented in the UI layer. I was using VB5 at the time, which didn't really encourage me to seek out nicer ways to structure my code. I copy/pasted large gobs of code whenever I needed to reuse something. And of course, whenever I had to make a change, I needed to do it in multiple places. Quite a few places in most cases even. I was using flat files to store data, so I didn't have the opportunity to make a horrendous mess out of a SQL-based data layer but if I had used a database, my usage of it would've surely been epic.

I got a very good grade for the project, and while I was happy to see that all of my hard work was rewarded, it did kinda scare me that a codebase that was so brittle and so painful could actually work, and work well even. It was my first encounter with what is by far the biggest problem with software development to this day: if you keep adding code, sooner or later it might actually work. Luckily, this was just a school project. But can you imagine if this were a project done by a professional company? That codebase would've cost money to develop, and the company would actually have a working project, no matter how expensive it would've been to keep working on it. At the time, I couldn't imagine a company in such a situation that would say: "ah, it sucks… we need to start over". And I think we all know that very few companies would actually do that.

I love that horrendous codebase for the lessons it taught me so early on. I learned a lot about what you shouldn't do when you're developing something that's supposed to stick around for a while, and I'm glad I learned it without it costing a lot of money. Of course, that doesn't mean that every single thing I've written since is all roses and peaches, but it put me on the path of trying to continuously improve as a developer, not only in what I was able to do with code, but also as to how clear I could make it to others.

Note: I no longer have that codebase unfortunately. Really wish I did, if only because it'd be pretty funny going through it after all these years.

Not only is the current way of trying to determine the productivity or quality of a developer rather subjective, it's quite often based on things that are only one part of the equation: what they did, and the time in which they did it. I've always felt that that only really tells you half the story. I don't hold much value on knowing how long a developer took to write a certain piece of code or to complete a specific feature. I also don't really care a lot about the code metrics for that piece of code or that specific feature. All i know is that it took some effort. The quality or productivity of that effort can't truly be measured without knowing how much extra effort will be introduced later on because of that effort.

Suppose you have 2 developers, John and Sally. You give them both the same task and you tell them that the estimated workload for that task is 12 hours. John completes the task in 10 hours, and Sally needs 14 hours to complete it. It would be easy to think that John is more productive than Sally based on this. Especially if results like those were to repeat quite often. But what if John's solution requires an extra 6 hours of effort down the line to fix some bugs, or because his code was such a mess to follow that it slowed down future tasks which required another developer to comprehend the code of John's task? That would put John's eventual total to 16 hours of effort, instead of the originally reported 10 hours. And what if Sally's solution didn't introduce any future effort whatsoever down the line? Hell, maybe Sally's solution saved someone else an hour here or there because her solution was so easy to comprehend or perhaps even to reuse. Her total for that task remains at 14 while at the same time maybe even reducing future numbers. In this scenario, Sally is clearly a more productive and better programmer than John though we wouldn't know about it if we'd based ourselves on the initial numbers.

Consider another scenario though. John again spends 10 hours on the same task, and Sally again spends 14 hours. John kept it as simple and as straightforward as he could. Hell, he actually took a shortcut or two to finish faster. Sally is an outspoken member of the Software Craftsmanship movement and stays up to date with all of the latest and greatest patterns and approaches that are making their rounds on the internet. Sally spent a little bit of extra effort to make sure the code is as great as it possibly can be. It's incredibly readable and uses a great new pattern that all the cool kids on the internet rave about. The code metrics clearly show that Sally's solution is of a much higher quality. Unfortunately, it turns out that the other team members are having trouble understanding that code and they often lose time trying to figure it out whenever they need to do something which involves that part of the codebase. While Sally may claim that she took more time because she did it 'better', the extra effort wasn't worth it because no matter how well her intentions with that code, it ended up costing other people time. And what if John's shortcuts didn't introduce any future effort?

There are countless variations on this scenario which makes it virtually impossible to come up with a way to measure productivity or quality based on hours spent or code metrics. The only way to objectively measure this is to define a new metric which holds into account the extra effort that will be introduced later on. I'd call this metric Eventual Efficiency. Quality or productivity by themselves don't really mean anything if one influences the other negatively. Efficiency however can be seen as a combination of the two. Did you write truly fantastic code which ended up not mattering at all? Not efficient. Did you write mediocre code that got the job done and didn't (or hardly) introduced future effort? Sounds pretty efficient to me. Did you write great code that reduced future effort? Very efficient! Did you write bad code quickly that ended up introducing a lot of effort? Not efficient at all.

Unfortunately, we'll probably never get to the point where we can actually measure the Eventual Efficiency of developers. Until we do, it's worth keeping in mind that whatever numbers we might be looking at don't really mean anything without the link to the related future effort.

1. Check whether the exception has an inner exception. If not, proceed to step 2. If it does, check recursively until you've got the original exception (the one that doesn't have an inner exception).
2. Read the exception message. Don't just glance at it, actually read it. If you got an 'aha!' moment upon reading it, you already know what to do. If you didn't, proceed to step 3.
3. Take a look at the stacktrace. If the technology you're using prints its stacktraces in reverse chronological order (as in: the most recent method call is the first one listed) then open the first class of your code base that is listed in the stacktrace and go to the method of that class that is listed first in the stacktrace. If the stacktrace is printed in chronological order (as in: the most recent method call is the last one listed) then open the last class of your code base that is listed in the stacktrace and go to the method of that class that is listed last in the stacktrace. If line-numbers are displayed in the stacktrace, go the line-number that is printed next to the first mention of the first class of your codebase (in the case of reverse chronological order) or the last mention of the last class of your code base (in the case of chronological order) that is listed in the stacktrace. This is the part where you need to begin your search. The actual bug might be somewhere else, but at least you've got a starting point for your search. Once again, if you got an 'aha!' moment after this step, you already know what to do. If not, proceed to step 4.
4. Here's where it gets tricky. Some people immediately enlist the assistence of a teammate at this point. Others spend hours searching until finally calling upon a teammate who might spot the problem after 10 seconds. If it's not immediately clear, spend 10 minutes tops looking for a solution before consulting with a teammate. If you haven't found a solution after 10 minutes, you haven't lost that much time and you can ask a teammate for help. If the teammate can help, neither of you lost a lot of time and at least you tried to fix it yourself before interrupting a teammate. If the teammate can't help, you're probably going to have to investigate this further on your own. Perhaps your teammate has enough time to help you, but don't count on it.

For a lot of the people reading this, there's absolutely nothing new in this list so i apologize for wasting your time. However, odds are high that you're going to run into a developer who can use this sooner or later so feel free to send him a link to this page

I didn't even know there was a NuGet package for Agatha, so this was a nice surprise. I have no idea who made the package, but thanks

Everybody is welcome to join, so please feel free to do so. The idea is very simple: you can suggest a get-together at a bar (or restaurant) of your choice. If people respond, agree on a date, go out, talk about software development, have a few drinks and just have fun. Ideally, these get-togethers will happen pretty frequently and in various locations throughout the country. That way, you can just pick which ones you want to go to. If you can't make one, or don't feel like going, just skip one. Or skip a few, doesn't matter. Just show up when you want to.

Finally, i'd like to repeat the 'rules' again so that we're all very clear on this:

• Leave your ego at home.
• You pay for your own drinks
• Open to all kinds of developers (.NET, Java, Ruby, Python, PHP, whatever...)

Hope to see some of you on these meetings in the future

I want to get something like that going in Belgium again. I want to talk to other developers who are serious about their job. I want to know what they're doing and how they're doing it. I want to know what people are studying or experimenting with on their own time. I want to know what works for people and what doesn't. And i want us to share that information and that experience. If you feel the same way, please respond to this post with a comment (and do fill out your email address) or email me directly. I don't care how many or how few people respond. If 5 passionate developers respond, it's already a win-win situation for each one of them.

But... there are a few rules that i would like to propose to avoid the same result that we saw with the Belgian ALT.NET movement:

• If you wanna come to the meetings, leave your ego at home. We are not interested in being a part of your career plan. We just want to share knowledge and experiences.
• Let's not restrict ourselves to a single technology. It'd be great if these meetings were attended by people who were doing .NET, Java, Ruby, Python, whatever. The goal is to learn from each other and to pick each others brains, and one of the best ways to do that is to look outside of your immediate (technological) environment.
• Let's keep things simple. Let's not seek out sponsorship. Let's not seek out opportunities to do presentations. Let's just hang out and talk about software development.
• Let's get together regularly. Twice a month or so. If you can't make a meeting, show up for the next one. Or the one after that. It doesn't matter, as long as we always have a small group of people who show up to talk with and learn from each other.

Who's with me?

The most obvious way in which you can create value is when you write code that results in noticeable improvement when it is being executed. It could be a new feature. It could be an improvement to an already existing feature. It could be a performance optimization somewhere. It could be a bugfix. All of these make the software better in an externally observable manner which, like it or not, is all that really matters to the people who are funding your development activities.

Obviously, we all know that good code and good design make software better as well. It just improves the quality of the software in a more internal manner. It's not directly externally observable. It is however quite reasonable to claim that good code and good design lead to sustained productivity while working on the software. It enables the continuous creation of value without making it increasingly expensive.

So focusing on the quality of your code and design is a good thing, right? Of course it is, as long as it doesn't prevent you from actually delivering your software to the people who are supposed to use it in a timely fashion. At some point, you are going to have to accept that you can't spend all that extra time and money to make it perfect. The software you're working on is most likely supposed to reduce costs for its users, or generate money for its owners. As long as it's not being used, it's nothing more than a cost. A big one even.

Focus on creating value. Make sure you keep your code and your design clean enough to achieve that. It's not about how great you think you are. It's not about your ego. It's not about how you can tell people that you've used approach X or pattern Y or library Z in a project that users might not be happy with. It's about delivering the value that you were requested to deliver. Plain and simple.

The announcement of the first release can be found here, and an example can be found here.  Here’s a little glimpse at the code of one the examples:

I think that piece of code is a nice illustration of how powerful and flexible this is

• We have to be able to easily retrieve what user X changed in the database on day Y or during a certain time frame.
• We need to know what record X looked like at point Y in time, and be able to show a historic list of changes for a specific record.
• We need to configure the duration for which auditing data must be kept in the database on a per-table (or per-schema) level

We've done this in the past, but never in a manner that is just perfect (or close enough to being perfect anyway) for both requirements. So we discussed two alternative approaches to tackling this problem.

The first approach is to have 3 tables. The first two tables would contain metadata about the database structure (tables and columns basically). The third table would have a reference to each column with a previous value, the new value, who changed it and a timestamp of when the change occurred. We would use database triggers that would store the appropriate auditing data in the third table for each action (insert/update/delete). The benefits of this approach would be that it would be pretty easy to set up and also easy to query which changes were made by a certain user. It would be a bit more complex to reconstruct the state of a record at a certain point in time, but it would still be doable. The biggest downside (in my opinion), is that for each insert/update you would have X amount of inserts into the auditing table, and you'd also have to either perform some queries to get the identifier values of the relevant tables/columns or hardcode those identifier values in the generated triggers to avoid the cost of the extra select statements. So if you have an entity with 12 columns, an insert into the entity's table would mean 12 inserts into the auditing table. Updating 4 columns of that entity would lead to 4 insert statements in the auditing table, etc...

The other alternative that we considered was to use a specific auditing table for each real table, and every time a user does an insert/update/delete, insert one record into the table's specific auditing table with the current state of the record along with a timestamp, the userid, and an indication of which action was performed (insert/update/delete). This insert would also be done with database triggers. The benefits of this approach would be that it would be very easy to show what the state of a certain entity was at a certain point in time, and that you'd only pay the cost of the single extra insert. There are however two big downsides to this approach. The first is that it'll lead to an explosion of tables. We'd probably store the auditing tables in a separate database but you still basically have twice the amount of tables (and scripts!) that you'd have to worry about compared to what you'd usually have. We can very realistically expect a couple hundred of real tables in a few years, so you'd have to multiply that by two if you'd go for this auditing approach. Another big downside is that it would be very expensive to perform a query which would tell you what user X changed at point Y in time (or during a time frame).

Neither solution appears to be ideal. Also, this database will definitely grow a lot (more tables and obviously data) as we add more functionality and it's pretty safe to consider this entire project as something that will be expanding in functionality for a couple of years to come.

So my question to you is: Which approach do you think is best, and why? Or better yet, is there a better approach that we simply haven't thought of yet? I would definitely appreciate some feedback on this (either on the validity of both approaches or alternative approaches) so please do feel free to leave your thoughts in the comments

• give you access to their privates without too many difficulties
• don't really care about your intentions, or if they do, aren't very clear on that
• occasionally seem like a good short-term fix
• can be used in a variety of ways, with different outcomes and none of them are guaranteed
• can not to be trusted
• really need to be tested
• will burn you sooner or later if you're not careful
• become even more of a mess during the aging process

Feel free to add to the list

This worked pretty well for the first 2 years or so of my career, but a lot of that changed when i started working on our own little ORM in VB6 together with a more experienced coworker. For some reason, writing code that made the job of developers easier somehow was more appealing to me than writing code that made the job of our users easier. From that point on, my focus gradually shifted from being a developer who tries to add value through functionality to being a developer who tries to add value by reducing complexity. With that i mean that i spent less time working on actual features that our users would benefit from, and more time on writing code that other developers would benefit from. And that, in turn, would (should?) offer more benefit to our users on a larger scale because my code was supposed to make it easier for other developers to add new functionality.

Just to be clear on this: i think we need both 'kinds' (yes, i know there are more 'kinds' of developers but bear with me on this) of developers. If a team of developers consists solely of people like me, you're never going to deliver anything of value to your users because we would spend all of our time trying to improve whatever it is that we're doing. Just like you need people who are willing to think a bit further about how you're doing things, you need people who manage to actually get things done in a manner that is good from both the technical as well as the end-user point of view.

Sadly, i'm no longer one of those people. I used to be, but i don't really think i'm capable of going back to that. To me, providing a good User Experience means coming up with a good API. So i spend most of my time working on architectural and framework stuff. One of my biggest fears is that i'll some day end up as the typical non-coding architect so i try to stay very involved with how people are actually writing code to deliver real functionality. I may not write that kind of code anymore, but i do keep looking at a lot of that code so i can keep coming up with possible improvements.

So what about you? What are the things you focus most on, as a developer, and why? What are the things that get you the most satisfaction (keep this technical, i don't wanna know about your personal life) and are you able to focus most of your energy on this?

Consider the following code:

            var point = new System.Windows.Point(5, 7);
            point.X = 6;
            point.Y = 8;
            Assert.AreEqual(6, point.X);
            Assert.AreEqual(8, point.Y);

This compiles and works. Now consider the following class:

    public class SomeClass
    {
        public System.Windows.Point SomePoint { get; set; }
    }

And then this small piece of code:

            var myObject = new SomeClass
            {
                SomePoint = new Point(2, 3)
            };
 
            myObject.SomePoint.X = 5;

You'd typically expect that this code would compile, right? Well it doesn't. It fails with the following compiler error:

error CS1612: Cannot modify the return value of 'SomeApp.SomeClass.SomePoint' because it is not a variable

Not exactly what you would expect, right? Well, the compiler error in this case is actually a good thing, though the message isn't as clear as it should be. See, System.Windows.Point is actually a value type instead of a reference type, and as you should know, value types behave very differently from reference types when passed around. You basically get a copy every time instead of the actual instance.

Let me just borrow the explanation of the "DO NOT define mutable value types" guideline, from Microsoft's Framework Design Guidelines:

Mutable value types have several problems. For example, when a property getter returns a value type, the caller receives a copy. Because the copy is created implicitly, developers might not be aware that they are mutating the copy, and not the original value.

Now the compiler error makes sense, right? Well, the message still sucks, but it makes sense that the compiler would protect you from making this mistake.

It won't protect you from the following mistake though:

            var myObject = new SomeClass
            {
                SomePoint = new Point(2, 3)
            };
 
            var point = myObject.SomePoint;
            point.X = 5;

This code will compile, though if you expect that myObject.SomePoint.X will return 5, you're in for a treat. Hopefully nobody writes code like this, but imagine having to debug something like this in some legacy code that was never properly tested.

But really, why are mutable value types even possible? In what situation does a mutable value type make sense? I'd really like to know, so please point out those situations in the comments if you know of one. The only reason i can think of is performance but the number of situations where a mutable value type is going to give you a significant performance boost is probably so small that it would've made more sense to enable mutability for value types with a language keyword or something like that. Unless there is another benefit that i'm not aware of yet?

The tests of the old part of the code aren't always easy to comprehend and they use the database all over the place. I figured i'd quickly run them on the database that we use when we run those tests on our local machines, and after that, run them on the database that the buildserver uses (which is rebuilt entirely with each build) to examine the differences between both test runs. They both passed in both cases. They were still failing on the buildserver though.

Upon first inspection of the code of those tests, it didn't seem like there was any blatantly obvious reason why those tests were failing on one machine, and not on the others. They were inserting some records with some manipulated DateTime values, and then calling some code which would execute a query which should have retrieved these values. The records inserted by the test were not retrieved for some reason, which caused the tests to fail.

DateTime values and tests can be tricky sometimes so i started looking in that direction. The queries that where executed in those tests would use the current date/time together with a margin of a couple of minutes to retrieve records where a certain date/time column's value would fall in the range of the current date/time with the given margin. The records that were inserted in the tests would use the current date/time, minus 2 minutes, or plus 2 minutes. Hmm... this could possibly be flaky depending on how the query determines the current date/time. If the query receives the current date/time from the calling code, then this wouldn't cause problems but if it uses the current date/time of the database, then this is not only a flaky test, but a real bug in the code.

I then checked the system clock of the buildserver, and as i suspected, it was about 4 minutes ahead of the system clock of the database server. Normally, all of our servers' system clocks are synchronized, but for some reason, the buildserver hadn't had its system clock synchronized since the day before. The code was inserting records in the database with modified date/time values, based on the system clock of the system the code was running on, and was then querying the database using the database's system clock. Since the time difference was big enough, the query would not return the expected rows and this made the tests fail on the buildserver.

Obviously, this never would've happened if the query would've used a parameter supplied by the caller which would've represented the current date. And that is the real bug that these flaky tests (which up until this particular incident never failed) highlighted. A situation like this could've occurred in production if the application server's clock and the database server's clock would've gotten out of synch. Can you imagine the pain you'd go through when investigating a bug report like this? :p

Date/Time values are often tricky, especially when there is more than one source which could determine the current Date/Time. So do yourself, and anyone who will maintain your code down the line, a favor by making sure that only ONE source is in charge of Date/Time values in your system. Using the database for all date/time values is definitely not always possible, so it's best to have your application server be in charge of all date/time values. If you need the current date/time in a query, simply supply it as a parameter to the query and you'll avoid problems like this.

Though this advice does leave me wondering what the best approach to deal with this is when you have multiple application servers which could assign date/time values.

Some people want to put an equivalent to NHibernate's ISession's Load method into the base repository class, but we just can't come up with a good name for it. In case you don't know, ISession.Load either returns the actual entity if it's already in the session cache, or it returns a proxy for the entity but it does not immediately hit the database. The functionality of the Load method is thus very different from the Get method. Now, i think this is a case of extremely bad naming within NHibernate, and i don't want to have the same naming issue in our Repository implementation.

So basically, the question is: how would you name the equivalent of the Load method? Remember: this method returns a proxy to an entity if it's not yet in the session cache, whereas the Get method actually retrieves the entity from the database immediately or returns null if the entity for the given ID does not exist.

Finally

and

They are almost exactly the same, which is obviously a problem. The root cause of this situation is that there is no common interface between IQuery and ICriteria, and there also isn't a common interface between IMultiQuery and IMultiCriteria. Introducing those interfaces would make a lot of things easier, but can't be done right now. Still, that shouldn't prevent us from striving to avoid duplicate code.

This is actually pretty easy to do... here's the new FutureBatch class:

And now the original 2 classes look like this:

and

They are still very similar, but at least it's a big improvement over the original situation.