Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts

Saturday, March 13, 2010

Can You Name the Most Popular Programming Languages?

Fun Quiz to test your knowledge of the most popular programming language (well, fun if you are a languages geek).

Tuesday, November 24, 2009

Bitter Refactoring


Kimberley Bitter
Originally uploaded by kamoda
After reading Martin Fowler's book on Refactoring I've been a big fan of the practice. We all know that adding in tests to insure the refactoring doesn't change the results is essential.
But this last week the real world crept into our world of programming paradigms. We refactored a complicated section of code to make it simpler, more readable, and faster - a big win; except that after the code was fielding, one of our customers reported a problem.
Their use of our product actually depended on a bug in the old version. Refactoring the code fixed the bug and caused our customers grief.
I'm still a big fan of refactoring and continue to do it, but now I'm a little wiser that refactoring carries more risk than I'd thought before.

Wednesday, August 13, 2008

PeopleWare by DeMarco and Lister


Click to read reviews or buy Peopleware

I've just finished reading Peopleware by DeMarco and Lister and have put it on my Recommended Reading list. Buy one and read it.

This is a great book, it's 20 years old, but still relevant. I thought the highlights were these:


  1. Projects fail not for technical reasons, but for sociological reasons.
  2. Our successes stem from good human interactions, not from incremental technical improvements.
  3. Making errors should be encouraged - everyone should have a few mistakes during the project when we tried something and it didn't work. When the answer to "How many mistakes did you make?" is "none"; that's a bad sign people aren't trying enough new things.
  4. We need people who make the team "jell" - they are worth more than coders.
  5. We spend too much time trying to get things done, and not enough time asking if the thing is worth doing.
  6. People really like to make very high quality stuff, but the market wants high quantity.
  7. Parkinson's law, "work expands to fill the alloted time", doesn't apply well to software developers.
  8. Beware of claims to increase software productivity by 100% because most time is not spent programming.
  9. When testing productivity of programmers, some were 10 times more productive than others. This is not quite what it sounds like since not all a person's time is taken with programming.
  10. During "programming games", language did not affect the outcome (except assembly language) and experience didn't matter (if they had more than six months experience).
  11. Quiet places for work are extremely important to allow programmers to get in the "flow" of their work. (This agrees with Joel Spolsky, but not the Agile wing of development).
  12. Corporations have entropy. Differences, and creativity, in departments are slowly ground out of them to create a flat, bleak landscape of sameness.
  13. Big Methodologies don't work; better to use training, tools, and peer reviews.
  14. Fujitsu encourages all projects to do some aspect in a nonstandard way.
  15. Letting teams strive for less than perfect quality is the "death knell" for the team. Teams really want to do high quality work.
  16. "Sociology matters more than technology or even money."
  17. Overtime is destructive and counter-productive.
  18. People hate change. We are agents of change.
  19. Try to keep people on one project at a time, not spread over several at one time. They are less efficient and more frustrated.
  20. Don't waste your peoples time in meetings and overstaffing projects early.
  21. Create a fun, creative, productive team environment - somehow.


Their recommendation for having quiet offices struck me. As a result we got the loud cell phone in the office turned down and I bought one of my people, who is affected by the noise, some noise-canceling headphones to see if that would help with the noise. It didn't.

Tuesday, April 22, 2008

.Net Application Restarts Frequently on Windows Server 2003

While stress testing a .Net 2.0 application, we noticed the application was restarting about every minute. This restart did not occur under normal loading, but when we really pounded the app it did this weird restart every minute thing.

The application ShutdownReason was "Configuration change", a more detailed message:

_shutDownMessage=Overwhelming Change Notification in c:\inetpub\wwwroot
Overwhelming Change Notification in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Config
CONFIG change

This happened on Windows Server 2003, but not on XP.
The solution was to install the Microsoft .NET Framework 2.0 Service Pack 1. Now it is happy.