When .NET arrived on the scene it promoted the use of events and delegates to decouple code. Chris Sells had one of the best early stories on how it all works (.NET Delegates:A C# Bedtime Story)*:
Once upon a time, in a strange land south of here, there was a worker named Peter. He was a diligent worker who would readily accept requests from his boss. However, his boss was a mean, untrusting man who insisted on steady progress reports. Since Peter did not want his boss standing in his office looking over his shoulder, Peter promised to notify his boss whenever his work progressed.
For a few years I think we were all infatuated with events. We used them everywhere from the web to the desktop, and even in between. Looking around, you have to wonder if we went down the wrong road.
Consider the people who …
I’m thinking one day soon we will compare writing explicit event code to manual memory management.** Both will be low level details we don’t see in our everyday code.
If so, this will be quite a change from just a few years ago.
--
(*) The start of the story should sound familiar to anyone who worked with COM’s IConnectionPoint, which almost qualifies the story for an award in the horror category.
(**) If this means I never see the INotifyPropertyChanged interface in anyone’s code ever again, then I’ll welcome the new event overlords with open arms.
My latest article for MSDN Magazine appeared online and in print a few weeks ago. This article is about search engine optimization with the latest and soon-to-be released tools.
It wasn’t so long ago that SEO experts would lambast the .NET platform as poor choice of technology for SEO work, but much has changed just in the last year. While working on the article I exchanged some emails with Carlos Aguilar Mares, who sold me on features in the SEO Toolkit and the URL Rewrite extensions for IIS. The SEO toolkit will crawl your site and warn you about things the search engines don’t like to see - like bad redirects, missing ALT attributes, broken hyperlinks, and multiple canonical formats. You can use the toolkit to manage robots and sitemap files, and even find malware on your site. The URL Rewrite module can give you optimized and friendly URLs without giving up the performance benefits of kernel mode caching.
Things get even better next year with some of the features the ASP.NET and Visual Studio teams have in store. Read the article for more details.
I wrote the following prose in preparation for my fireside keynote at Concept Camp 2009. Concept Camp arrived at a time when I was asking questions about the software I’ve created over the years. I was wondering if the software I’ve created is truly successful, and how you measure success in software development.
I’ve written commercial software for many companies over the years. Some of the best software I’ve created was for companies that are now out of business. Was the software a failure? Some of the worst software I’ve created, as a developer working alone and just out of school, is still running inside laboratory instruments around the world. Is that software a success?
Athletes declare victory and defeat using scoreboards and finish lines, but success – real success, isn’t easy to measure in software development, or in other lines of work. As an example, let me tell you the story of two men working as army generals, and you try to decide which one achieved victory.
Concept Camp 2009 took place just outside the town of Williamsport, Maryland, which is near my hometown of Hagerstown, MD. Since I grew up in this area I had no choice but to learn about the local history, and there is no shortage of history in the area. For instance, Williamsport, holding a prime location along the Potomac River, was one considered by George Washington as the site for our nation’s capital.
Not far from Williamsport is the town of Sharpsburg. Its 700 residents live next to the Antietam Battlefield – one of the most famous battlefields on American soil. 147 years before Concept Camp, this area was full of soldiers fighting the American Civil War. The general leading the Confederate army from the south was General Robert E. Lee. The General leading the Union army from the north was General George B. McClellan. Both generals were graduates of West Point, but the two applied vastly different strategies in battle.
General Lee assumed control of the Confederate army in the spring of 1862. This was during a time when many felt the war would be over quickly. The Union had already invaded the south and the army was sitting outside the capital city of Richmond, VA. Lee quickly won a series of battles, however, and pushed the Union army away. Those battles ended the hope for a quick end to the war.
The situation was beginning to worry President Abraham Lincoln. European powers like Britain and France were watching the rebel army effectively defend its territory, and they were thinking of supporting the south’s claim for sovereignty. Meanwhile, mid-term congressional elections were coming up in November, and if the northern voters perceived the war as going badly, their voting power could end Lincoln’s plan to reunite the country.
Against this backdrop, General Lee saw an opportunity for great military and political gains. In early September, he led his army north across the Potomac River. It was the Confederate army’s first steps on Union soil.
General McClellan chased Lee’s army until they met outside of Sharpsburg by the Antietam Creek. The ensuing battle on September 17, 1862 was horrific. It is still the bloodiest day in American history with 23,000 casualties. You can read about the terrible fighting around Miller’s cornfield, Bloody Lane, and Burnside’s bridge in books like “Antietam - A Soldier’s Battle” by John Priest (my history teacher in school).
McClellan’s army left 30% of Lee’s army dead or wounded. Because of the casualties, Lee had to withdraw his army and return south to Virginia. President Abraham Lincoln took this opportunity to issue the first Emancipation Proclamation on September 22nd. The Proclamation meant the war was no longer just a war between states, but a war to end slavery. The higher cause boosted the morale of the Union soldiers and bolstered support for the war from voters. Overseas, the Proclamation forced European powers to reconsider support for the rebel states, as they didn’t want the world to perceive their policies as supporting a slave nation.
Doesn’t this sound like a decisive victory for McClellan and the Union?
Of course, I didn’t give you all the information you needed to know about the battle. I didn’t mention that McClellan’s army outnumbered Lee’s army almost 2:1 (90,000 men to 50,000 men). I didn’t mention that McClellan kept half his men in reserve – they never fired a shot. I also didn’t mention that McClellan split up his attacks into three separate assaults, giving Lee time to shift and reorganize his defenses. And I didn’t mention how vulnerable Lee’s position was with his back to the Potomac River.
Finally, I didn’t mention that President Lincoln, unhappy with McClellan’s performance, removed the general of his command not long after the battle.
Most experts believe McClellan had the opportunity and resources to eliminate Lee’s army and put an end to the war. Instead, the civil war continued for three more years.
It’s difficult to draw analogies between war and software development. One is a bloody endeavor that kills while leaving physical and mental scars. Another is a profession that involves keyboards and cubicles under fluorescent lighting. Nevertheless, I think there is something we can learn about victory from the Battle at Antietam. Achieving victory doesn't mean we've achieved our full potential.
Also, we already know that victory is hard to define. Shipping a product isn’t a reason to declare victory, particularly if the product falls apart after 1 month. We can’t declare victory based on the number of lines of code we’ve written, or the number of features we’ve shipped. Having too much code or too many features can lead to defeat. We can’t declare victory based on the number of unit tests we have, or code coverage statistics. We can’t declare victory by pushing cards across a Kanban or moving a line down a burn down chart.
All of the things I’ve mentioned are indicators of success, but even if we look at them collectively we’d still be missing the judgment of the people who use our software. Does it have the right features? Is it fast enough? Is it friendly? Does it work without unnecessary surprises? Did it reach on time? Did it cost too much?
Customers, clients, consumers, and users all have a considerable say in our success and failure, and we can’t ask their opinion using only a single point in time, just like we can’t declare the winner of a 100 meter dash by observing runners at the 50 meter mark. Most applications need to evolve over the course of years, and we can only achieve victory if we continue to grow the application.
Returning to a military theme, there is the type of victory known as a pyrrhic victory. A pyrrhic victory is what happens when you are decidedly victorious in a single battle, but paid such a heavy price to win that you are in a position to lose the war. Not everyone realizes that software development is a marathon, and shortcuts often lead to pyrrhic victories. The application ships, but it’s an un-maintainable collection of shortsighted hacks that will fail to evolve with the user’s needs in the future.
Since users have a considerable vote in our quest for success, having them invested in our software project is a great idea. The good news is that software development is making concerted efforts to move the user closer to the center of our development activities.
We started by changing our methodologies. We realized that a waterfall process, where the user tells us in detail what they want, and then we hide in offices for 24 months while building it, results in defeat for everyone involved. We started to adopt agile methods that embrace change and require everyday participation from the users.
We also started moving users closer to our code. Doman driven design encourages the use of a ubiquitous language that the developer and the business expert share, and the language influences the names of our abstractions. We strive to write acceptance tests using natural languages a customer can understand. Everyone wants a domain specific language that a business expert can comprehend.
We’ve moved our users closer to what we do, but software development is still not centered around the user. Developers sit in the center of software development as the sun sits in the center of our solar system. We use our heavy mass of technology to distort light, space, and time to our needs. We tell the user what can and can’t be done. We’ve trained them to come to us and ask us what’s possible, instead of envisioning their own possibilities.
Like General McClellan in the Battle of Antietam, we aren’t reaching our full potential.
General McClellan didn’t fight to win the Battle of Antietam – he fought not to lose. He was cautious. He was pessimistic. He didn’t pursue Lee’s weary army as they hobbled back into Virginia, though he had fresh regiments of soldiers available. McClellan saw only risks, and not the opportunities.
Software developers are obsessed with mitigating risk. All the indicators of success we talked about earlier- deadlines, code coverage, unit tests, burn down charts – these are all in place to mitigate risk. We also mitigate risk with compilers, coding standards, source control systems, patterns, practices, daily stand up meetings, continuous integration builds, and more.
Avoiding disaster in software development requires an obsessive-compulsive approach to risk management. We focus on risk instead of potential.
Our focus means we don’t fight to win in software development. We fight not to lose.
Once a customer asked me how I could automatically populate one of the screens in her application with information held inside a database of manuscripts. I immediately saw the risk in matching data to the right fields based on the context of the screen. I’d need a way to search and index the correct pieces of information. I’d need some fuzzy logic to interpret the meaning of the data. There would be some advanced algorithms needed to transform and pick apart the appropriate information.
I wasn’t thinking of the software’s potential. I wasn’t thinking about how this feature could transform the lives of the people who used the software. I saw only the risks. I surrendered to fear.
Kent Beck listed courage as one of the primary values to embrace in his Extreme Programming book. We’ve made significant advances in embracing many of the other values listed in the book. We practice test-driven development while reciting the Single Responsibility Principle in homage to the value of simplicity. We hold daily stand up meetings and apply continuous integration to promote the value of feedback.
But courage?
It’s difficult to find a pattern or a process that helps us practice courage on a daily basis.
How many times have you seen a software team talk a customer out of a feature because it might require something different, or unknown?
Fear of the unknown drives too many decisions in software development.
The next time your user asks for something and your first impulse is to start assessing the risks involved – STOP.
Think about the possibilities first. Think about the value to the user. Could this request make the software great? If not, how could it be even better? What can you do in this area to empower the user? How can the software truly transform their job, or their business? What could you change about your technology to make this work? What could you change about your team to make this work? What could you change about your company to make this work? How many days would you really need to experiment with something new and different? Only after you understand the true potential of what is possible can you can put on your engineering hat and assess the risks.
We all work with limited resources and deadlines, but we often use these constraints as excuses instead of parameters in a formula for victory.
Only courage allows us to find the true potential of software. Only courage allows us to recognize our weaknesses and try something new. Only courage allows us to explore unfamiliar landscapes in the world of software development.Only courage will allow us to align our goals with the goals of the user, make our software great, and give us a shot at undisputed victory.
--
I want to say thanks to @SaraJChipps for having the courage to organize this novel event, and inviting me to speak. And thanks to everyone who had the courage to come and share their stories and laugh in the rain. Concept Camp 2009 was a success, and I can’t wait for the next one! I just hope the weather is a little better …
During the last week of August I was in Stockholm, Sweden to deliver two of the twelve workshops at Øredev's Progressive .NET Days. The workshops were split across 3 tracks and covered prevailing software development topics like NHibernate, DDD, DSLs, Git, and dynamic languages. Based on the feedback I’ve heard, the workshops were considered a success by everyone who participated. But, what left a lasting impression on me was the unbounded hospitality of the event organizers, attendees, and Stockholm itself.
On the first evening that I ever spent in Stockholm I was greeted by Michael Tiberg, the CEO of Oredev. We strolled across modern roads into the medieval, cobblestoned streets of Old Town Stockholm – Gamla stan. Michael was my personal tour guide and pointed out sites. I saw Stockholm City Hall - a stalwart building made of red brick and home to Nobel Prize ceremonies and banquets. I also saw the rounded backside of the Swedish Parliament building, and facades of the Stockholm Palace.
Michael didn’t know I was a fan of Jazz music when we entered Stampen that evening. In the 17th century, this building was a French Reform church, but since 1968 it’s been a jazz pub. The vocalist of the 5 piece band playing that evening would belt out jazz classics in English, then banter with the growing crowd in Swedish. The last song we heard before leaving was Billie Holiday’s God Bless The Child – a personal favorite.
Within a day I decided that Stockholm is a quiet city, but quiet isn’t the same as sleepy, or empty. People are everywhere in downtown Stockholm. Commuters wheel past in the dedicated bike lanes and swarm into metro openings. Taxis and tourist buses jockey politely for curb space. But something was audibly missing - the insecure blustering I’m so accustomed to hearing in the metro areas of the Northeast United States – no horns blowing, no people shouting, no music blaring. In Stockholm, even the sidewalk hawkers stand quietly on the corner wearing sandwich board signs to advertise lunch specials.
The quiet in the city gives you the chance to hear people laugh. They laugh as they talk on cell phones, and they laugh in crowds under the open awnings of cafes. The Swedes I met paint themselves as reserved, and present themselves as self-assured and happy.
I took home many fond memories from Stockholm, including a trip to an Ice Bar (thanks Magnus), and some great technical discussions with other speakers and attendees. The last evening I spent chatting and dining with guys from Nansen – a local and fast growing web development firm. We talked about software development, health care, politics (I met at least two members of the Swedish Pirate Party during the week), religion, the size of American cars, and XBOX games. I hope to return one day and experience more of Stockholm, and I’m already looking forward to the main Øredev conference this fall in Malmö.
The 36-Hour Day is a book to buy if someone you love is growing a little older, and perhaps growing a little confused, too. The book is about memory loss and dementias like Alzheimer’s disease. It will give you information and strategies you need to care for your loved one, but more importantly, it gives you a perspective and understanding of what your loved one experiences as their illness transforms their behavior and memory.
I have an easy time finding quality technical content on the Internet, but I struggled finding good resources on this topic. The articles on dementia live in a wasteland of superficial prose, smeared by pointless advertisements. The 36-Hour Day : A Family Guide to Caring for Persons With Alzheimer Disease, Related Dementing Illnesses, and Memory Loss in Later Life is packed with advice to deal with the emotional, legal, medical, nutritional, and behavioral aspects of a heartbreaking situation. Kudos to the authors Nancy Mace and Peter Rabins.
The book will help you care for the person you love.
The book will help you care for yourself.
I highly recommend it.
OdeToCode by K. Scott Allen
Subscribe
Twitter
Search
About
Learn C#