Do you watch too much TV? Do you?

I know that I have wasted too much of my life zonked out in front of the tube. What could I have accomplished with the time wasted in front of the tube? The answer is a whole lot.

Last summer my wife and I turned off the TV for the whole summer. Yes, that's right, the whole summer. We just looked at each other one night and said "this TV sucks." We agreed that the mediocre entertainment is just a vehicle to shovel more advertising into our brains so we decided to take charge and switch the TV off for the summer. Our new summer entertainment came from reading. I know what your thinking "how quaint" but the experience was great. My wife loves court room dramas and I am a sucker for Sci-Fi. Yes I am a geek and I like being a geek. This summer is going to be different. We are still going to turn off the TV but I am going to use the time to better myself by following a SMART plan and a Polyglot Lineup.

If you have not read the Pragmatic Programmers Pragmatic Thinking and Learning, you must get yourself a copy, soon. Don't wait, it will change the way you approach learning technical and non technical topics. I originally did not think this book was going to be very good. I judged this book by the tag line "Refactor your Wetware." It sounded like a line from a late night infomercial, but boy was I wrong. The book has a great technique for learning about new topics and it's called SMART.

ahptl ... SMART stands for Specific, Measurable, Achievable,
Relevant, and Time-boxed. For any goal you have in mind (losing
weight, deposing your boss, conquering the world, and so on), you
need to have a plan: a series of objectives that will help get to your
goal. Each objective should have the SMART characteristics.

Pragmatic Thinking and Learning

Polyglot Lineup Schedule

  • Monday: Python ( IronPython in Action)
  • Tuesday: F# ( Real World Functional Programming )
  • Wednesday: Ruby ( Pickaxe )
  • Thursday: Python ( Python in a Nutshell )
  • Friday: F# ( Real World Functional Programming )

Armed with my SMART objectives, time and a polyglot lineup schedule, I am ready to take a deep speculative dive into these programming languages to broaden my knowledge of programming in general. Nobody, not even myself, can master 3 programming languages in a single summer but at the end of this summer I will have programmed in Python, F# and Ruby for nearly 200 hours. Would you trade 200 hours of programming for any TV show?

So, if the summer lineup has you wishing for more, then turn off the TV and make a SMART plan to learn something new.


The knowledge gained from reading and possessing technical books without real world implementation or experience is a mirage of knowledge. Just like in the movies, a mirage of a desert oasis looks real and inviting until you try to drink the sand, so too is the experience of depending on book knowledge until you try to use it for a real world implementation. To truly know something a person has to experience it first hand and be in the moment to truly grasp knowledge.

Reading is a very important and required part of being a Technical Craftsman but it is not the destination; it is the gateway to the journey of knowledge. Thomas Edison famous quote "Genius is one percent inspiration, ninety-nine percent perspiration" applies to reading and the mirage of knowledge. Reading accounts for 1 percent of knowledge and the rest comes from the perspiration of real world implementations.

If real world implementations are 99 percent of knowledge, how do we get those implementations? It's all in the hustle, or perspiration. If you want to truly know something, you are going to have to get your hands dirty and start to implement the things you have read about. These implementations can come from following book examples, open source projects, work projects, or from yourself. Make something useful with the things you learn.

Books I have read in the last 45 days:

ahptl cfcar2 mnee prj ruby3 tsgit

These are only the books pertaining to development and do not contain the other books that I have read for business and personal interest. I have a large amount of perspiration ahead of me if I want 100 percent of the knowledge contained in these books. You and I do not have to have 100 percent knowledge on every topic we read about, but we need to be aware of the quality of our knowledge when we are faced with technical challenges.


Q. What does not belong together?

A. Peas and Carrots

B. Peanut Butter and Jelly

C. Milk and Cookies

D. Scrum and Waterfall

For some people in the software world, this is not an easy question to answer. For the rest of us, the answer is D. With agile methodologies like XP and project management techniques like Scrum gaining popularity, a new kind of fusion development methodology has emerged--Scrummerfall.  

Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.

Brad Willsion - The .Net Guy

Why is Scrummerfall becoming more popular? Scrummerfall is popular because some people think that adding Scrum to the Waterfall software development process only requires the development team to change. All of the other processes and fiefdoms like Group Management, Requirements, Budgeting and QA all stay intact and unchanged. This type of change wrapped in a cocoon of business as usual spells disaster, and an expensive one to boot.

If everybody is waterfall as usual, how can a team following Scrum hit a predetermined ship date while allowing additional feature stories in the product backlog? The short answer is, they cant. The long answer is, they eventually won't. This type of problem reminds me of the Iron Triangle stuff from my days working on fixed price projects in New York City in the late 90's. Those were good times, when getting to work was an adventure.

The most important part of Scrum for me, are the product backlog and the burn down rate. These two metrics are the key to knowing when you will be finished or finished enough with the product. If you can't show me your project's burn down rate and a feature backlog, you are not doing Scrum. Having the morning standup is not Scrum, it's a waste of time.  

Scrum needs to involve more than just the development team. It needs to have the chickens and the pigs involved from all of the fiefdoms and especially the money people. They hate it when they get little or nothing in return for their hundreds of thousands of dollars. If the business you work for does Waterfall, then do Waterfall. If you can get the whole team to do Scrum, then do Scrum.

 


Magic strings are string literals or quoted text in your C# code.  When these magic strings are used in your application, they make it harder to code and maintain your application. You know as a good developer that magic strings should be avoided, right! Most of the time these strings should be replaced by resource file entries, enumerations or constants.

The smallest improvement that you can make with your magic string issue is to be more aware of them in your code. Once you are more aware of them, you can correct them. Luckily for us we use Visual Studio which has the ability to change the foreground and background colors of our magic strings. 

To do this you will need to open up the "Tools" menu and then select "Options" to open up the options window. Once there, select "Fonts and Colors" under the "Environment" setting. Then in the "Display Items" box select "String" and then choose an obnoxious background color, foreground color and check the bold checkbox to make it really stand out. I choose yellow for my background and black for my foreground. Then repeat this for the "String (C# @ Verbatim)" display item under string.

Ok, I know what your thinking, we made some changes to the colors of string and verbatim strings, big deal. Remember a kaizen is a small improvement not the whole solution. This kaizen is to improve your awareness of when you might not be using better practices as it pertains to string literals in code. So here is what it looks like in my IDE. Yours might be all white and glaring but my IDE is pimped to the dark-side.

Conclusion

To successfully complete this kaizen, you will need to keep this setting on for 3 weeks or more. If you're anything like me, then you will start moving the literals into constants or enumerations and start moving your error messages into resource files just so you don't have to look at that aweful color. This kaizen is a small step in improving yourself as a developer.

If you want some help with this kaizen, then get yourself a copy of Developer Express Code Rush and Refactor Pro products.  They make the process of moving strings into resource files so easy it should be criminal. No, I do not get paid by Developer Express; even though, I would work for company products and diet Coke!

Links

Happy Improvements.  


What is a Kaizen?

Kaizen is a Japanese word that literally means “Improvement.” Today, the word kaizen is used to define a methodology where small incremental improvements are made to any process or procedure to produce positive change. When these small improvements are combined together, they form big improvements and amazing change.   

How Does Kaizen Work?

The power and secret of kaizen is in the size of the improvement. Most people, when they want to improve something, change everything at the same time. This type of change is hard for us to sustain because it is not the normal process that our brain is used to so we usually revert back to the old ways of doing things. Good intentions are not improvements; they are a waste of time. With kaizen, you make the smallest improvement possible and internalize that change for about 3 weeks until your brain thinks it’s normal and comfortable.  After 3 weeks you lather, rinse and repeat.

Kaizen Example: Write One Unit Test Per Class.

I know what you are thinking. That’s easy and useless!  To tell you the truth, if you are able to keep up this kaizen for three weeks, you are on your way to writing more unit tests and that is the ultimate big improvement. How hard would it be to write 2 unit tests per class after 3 weeks? Do you write unit tests? If you don’t today, this technique will help you get started. Come on; try it, you’ll like it. What do you have to lose, nothing!

The real power of small improvements is in their combination. Many small improvements will become a very large change in just a couple of months. With each kaizen being so small everyone should be able to fit them in, even if you have a very busy schedule.

This blog series will be focused on code kaizen and other improvements we can make as Craftsmen on our way from Journeymen to Master. The kaizens will be broken up into the following 4 major areas: 

  • Code Kaizen - Improvements to code and coding techniques
  • Tool Kaizen - Improvements to the tools you use or should use
  • Wetware Kaizen - Improvements to your wetware
  • Process Kaizen - Improvements to how you do things

Conclusion

My goal as a developer and craftsman is to improve myself and my craft, hopefully at the same time. If you want to improve yourself, then try the "Craftsman Kaizen" way. I will be updating this series frequently with new kaizen's that will hopefully find their way into your craft.

Links


That's right, Windows Workflow Foundation deserves your respect and I am going to prove it to you. Skeptical are you? I understand why, some of the best technologies in the Microsoft stack are treated like the red headed step child and don't get the coverage they deserve . Technologies like WF and MSMQ are some of the most flexible and interesting bits Microsoft has to offer but if you mention the use of them people scoff at your approach. No respect!

To prove my point, let's design a new system that will allow clients to request a HTTP callback at a specific time using a supplied URI. This will allow clients to schedule when an HTTP process will be reactivated and continue processing.

Requirements

  • System needs to handle over 35,000 requests a day.
  • Calling URI has to be called within 2:00 minutes of the scheduled time.
  • System needs to be redundant and installable in a web farm with a minimum of 3 nodes.
  • Workloads need to be distributed evenly on each node.
  • Nodes have to gracefully shutdown on command without losing information.
  • Full tracking and logging of each request.
  • The solution needs to have a 99.9 completion ratio.
  • System must not consume large amounts processor time or system memory on each farm node.

STOP: Don't Cheat. How Would You Solve This Problem?

My solution was to create a Windows service to host the workflow runtime and use Windows Workflow's built in persistence, tracking and scheduler services. I was able to satisfy all of the system requirements with one sequential workflow, custom logging service and 397 lines of C# code. That's right, under 400 lines and I have a distributed, highly available system that performs above specification.

Scoff no more at Windows Workflow, Windows Workflow's services (persistence, tracking, scheduling) are well worth your time and money. Oh wait, they're free, so it's just your time. How long would it have taken you to design and code a system that satisfied all of the requirements? Make the time and invest in Windows Workflow. Windows Workflow will be going through a rewrite in the next installment of the .Net Framework so hopefully it will get more R.E.S.P.E.C.T and love than it does today.