pthread_cond_timedwait is a nice little function that can be used to "atomically" release a mutex, wait for a condition with a timeout and then acquire the mutex. The first pitfall of this method is that the "timeout" is an absolute time, not a relative time as with most timeouts. Other than that it works fine for most platforms I've encountered. Until I used it on a BSD based system. Suddenly the code did not work in some cases. I managed to track it down to the situation where the time had already passed in which case I got odd behavior.
Turns out most platforms implement this method in a way so that if the time have passed, the mutex is released and reacquired immediately (an assumption used in the code I was working on), but on BSD this is not the case. For most platforms the MAN-page clearly states that this is the case (i.e. release and reacquire the mutex) but for BSD it says nothing about it. I can only assume there is an optimization in the code skipping the release-reacquire action if the time have already passed. I think that is an odd behavior since it blocks any other threads waiting for that mutex (unless you work around it with an extra release-acquire scheme).
So know your APIs and be careful if you're writing code for several platforms. And I can ensure that a number of unit tests exploring the behavior of an API can save time trouble shooting differences like this.
Yesterday was the fifth MSFTCorpDojo. MineSweeper as usual and we tried switching person at keyboard on each arrow in the TDD cycle (and not really pairing). As last time we tried BDD style tests. Didn't end up quite as neat as last time but we still learned something. I also noticed that everybody was very engaged this time. Don't know if it was the attendees or the fact that you could end up at the keyboard very soon all the time. Anyway I think we'll decide who goes next by random next time. Just to keep everybody on their toes... Will be interesting to see how that works. We'll also try to apply the object calisthenics rules next time.
This time it was also very clear how one person's decision on how to write a test or how to implement one thing may drive the complete solution in one direction unless you decide to do major refactorings. We also had to remind our selfs a few times not to do the smallest or dumbest change to make a test path but actually the simplest thing. I think it was nice how we sometimes tried to much, recognized that fast, backed out and did a simpler thing.
I think the daily stand-up is one of the most important parts that makes a team work well together and avoid surprises. But just because you have these daily meetings it does not guarantee that they're useful. A few anti-patterns I've seen in meetings are when people say things like "I'm working on some stuff" or "I'm still working on item 42". Statements like that are not really useful. Another anti-pattern is when problems or blocking issues don't boil up to the surface even though they exist just because people have over confidence in them selfs (or are afraid of admitting they have a problem).
There are a number of things you can do (one example). I think the most important thing is that the team find the meeting useful. And I hope the things I find useful are things most people find useful so these are my suggestions on how to keep the daily meeting valuable.
Those are the important things. If you stand up or not is a matter of taste (but standing up tends to be faster). Starting on time however is important. But I don't really believe in fines. Hopefully the shame/peer pressure of being late is enough to get people into the meeting on time.
I just finished a nice book on lean software development. I actually started to read it because one acquaintance of mine is quoted in the book. But it turned out to be a really good book covering economic aspects as well as the regular lean topics. A pleasant surprise was that the last chapter covers the topic of balancing centralised and decentralised control and as an example the author uses the USMC. So it looks like I'm not the only person that's collecting things we (as software developers) can learn from the military.
Anyway, I think this book you should read if you have a leading role (CEO, CTO, product owner, coach etc) in your company. It might not be valueble to everybody in the organization (for example junior developers) but it definitly have some good pointsfor everybody.
I recently read this comprehensive list with ten common mistakes done when writing SQL. And I'd like to add number eleven to that list: using dynamic queries in stored procedures. Especially in projects with a lot of stored procedures for parts (or all) of the business logic there is often a few stored procedures with which builds an SQL query in a string and then executes it. These tend to be very difficult to understand and frankly are often only there just in order to return exactly what is needed. Personally I prefer a more naive way to solve queries that just have to be dynamic. There are three things you can do depending on exactly what makes the query complex. Either you can create a single query that returns everything you possibly need and then filter the data afterward. Or you can get what you need in a number of smaller queries. The last alternative I tend to avoid is to move the creation of the SQL out of the stored procedure and keep it as parameterized as possible.
All in all, in my experience the use of dynamic queries is usually not needed at all. Only with a bad database design may they really be needed,in which case you need to work around it as I described above. But the best way to avoid it is to make sure the design of the database supports the kinds of queries you need to do instead of relying on dynamic queries.
Over the last months (since I first tried the object calisthenics rules) I've been starting to create smaller and smaller methods. And this is a thing that have gotten me into discussions before. I've been met with arguments that having all these small methods makes the code harder to understand because you need to jump around in the code to get the whole picture. And I didn't really understand why I didn't feel the same way until today when I had a similar discussion with someone I hadn't discussed this before. It turns out that it is a trust issue. In order to make small methods actually being easy to understand you have to believe that each method called actually does what it says it's doing. And I'm not talking bout the comment for the method. I'm talking about the actual name of the method. If the method name is DoShowMessageBox you have to trust that is the only thing it is doing so the fact that the body is just MessageBox.Show or something else should not matter in the method where DoShowMessageBox is being called.
But just because you do not trust that each method does what it says it should do I still think small methods are beneficial. Establishing trust (i.e. understand) for a small method is in my opinion easier and faster than a large one so in the long run you'll build the trust you need. So in the long run you'll benefit from writing shorter methods and trusting each method to do what it says it does. If you want some more reasons you might want to listen to uncle bob.
Had a discussion about the final version in Uncle Bob's post that I linked to the other day. The discussion was about how hard the class as a whole is to understand with all small methods. Using a class that is really implemented as one method of about ten rows as an example may be a little bit wrong because those ten lines are probably easier to understand as they are rather than UB's final version. But UB's main point is still valid. Keep your methods and classes small and make sure they all do one thing.
And having lots of small methods or not is not only about trust and/or old habits. Fewer methods are probably easier to understand when you must understand all details but the benefit of smaller methods are in my opinion greater because with smaller methods each of them are easier to understand by them selfs (when we trust that whatever they call is doing what it says it's doing) and typically you don't need to understand a complete class to reuse a method. Second a small method rarely need any documentation so there is no documentation that gets out of date and wrong. And smaller methods also makes code easier to test in my experience.
Back to UB's final version of the code in the post referenced. There is one place where I think a method is "just another level of indirection". Since the class is a SymbolReplacer I think that everything that happens in replaceAllSymbols could have been done directly in the replace method. And for clarity (if there is no interface that needs to be preserved) I would change the name to replaceAll.
So exactly how far you want to take your method extraction should not be a matter of taste. It should be a bet on how the code is going to be (re)used and read. But a good rule of thumb is that when you think you've extracted enough - extract a little more.
I would like to add another thing to my previous list. And that is the mistake of not properly understanding how to use correctly create the WHERE clause. I came to think about this when I read this which also includes a few good tips on how to rewrite your query to work more efficient.