Archive | Development RSS for this section

Adventures in Refactoring: The High Cost of a Complacency Culture

by Jon Cwiak (Twitter) => Senior Software Engineer | TechOnTap Brewmaster | Microsoft Certified Professional at building things

The High Cost

Head over to any online news source and you are almost certain to see another story about a hack, data breach, data leakage etc. While many of these “hacks” are attributed to complex phishing attempts and/or stolen credentials you often never get an inside view on the technical “how” such attacks were pulled off. The technical details are withheld for lots of reasons but mostly because parts of that vulnerability may not have been fully mitigated; those same vulnerabilities are probably in your organization.

This article is not about inside stories or root causes of hacks; instead, I want to focus on one attack vector where these attacks originate….a danger that creeps, well camouflaged, in all organizations: the complacency culture; Most businesses today buy, lease, or build their own custom software; this is to be expected and absolutely necessary to run a business. When time/scope/cost/feature set make sense, software is purchased and used, purchased and adapted, and often purchased and forgotten; when features of packaged software don’t meet the needs of the business in question, software is created… and often forgotten. In large organizations, it’s not uncommon to have teams of development staff not know about one or more production applications that they own; it was written long ago and lost to the ages….and there is where the danger lurks.

Software can be dangerous when it’s forgotten or ignored. Not only is there are high price in maintaining old code from a support perspective but there is real danger of letting a solution stagnate for too long. In and of itself, old code is not bad code; however, when the operating environment is kept at a lowest common denominator to cater to solutions that have not been touched in years, this screams danger.

Technical debt is a real. We trade time to market, business features, and cost of purchase for a long term technical mortgage that many organizations don’t feel the need to repay….until they spend hundreds of millions of dollars dealing with a data breach or a hack.


As technical leaders we are challenged with a complacency culture; as employees or contractors we have expectations of performance; as craftsman we have a responsibility to our craft before our responsibilities to our managers; so where does this leave us? How to we answer to our craft instead of our demands?

When as system is rotting, it’s up to us to raise this concern and bring our toolbox to bear on what we can; what can we do to ensure that future stewards of our systems don’t pay the high cost that we do today?


Change is hard; Complacency culture is best battled by removing the conditions in which it thrives: laziness and acceptance of good enough. Here are some specific ways to encourage moving forward:


Get involved in the technical community; Join or start a user group; attend a conference; learn and share an idea…even if it’s not really new;


Engage with interviewing; Value integrity and grit over particular technical talents; Remember that we can all attend a training course; not everyone is a good team player.

Learn To Learn

Learn how you and your team learn best; Be selfish and grow yourself…you silently inspire;

Automate Everything

Stop doing things manually that can be done with automation; Learn & encourage others to rethink routine.

Stop Wasting Your Keystrokes

Write blogs not emails; the future you will appreciate you more.

Wrapping It Up

Paying back technical debt starts with removing the complacency culture. Take iterative, incremental steps build a great team; a great team helps slow and/or stop the erosion of your culture; be a technologist and “professional up” by remaining a life learner. Automate all you can; last but not least, remember that the success and/or failure of our products may not always be in our control but the decision to remain committed to our craft is.

Guest Blog: Say Hello to Nancy

This week’s blog is from Adam Driscoll (Blog | Twitter), software engineering manager at Dell, PowerShell MVP, and Tech on Tap – Nothing But .NET speaker. He’s going to introduce us to the Nancy framework.

Nancy is a lightweight framework for building web applications in .NET. It’s easy to get up and running and can be extended to develop complex web apps with minimal overhead. In this post we’ll look at how to get a simple Nancy instance running and serving web pages.

First, create a new console application in Visual Studio. Next, open the Package Manager Console and type ‘Install-Package Nancy’ and then ‘Install-Package Nancy.Hosting.Self’.


We now have Nancy installed with the self-hosting module referenced. This will allow us to stand up our own Nancy instance outside of any other web server like IIS. Next, we need to create a NancyModule. Nancy modules define how the Nancy server will respond to requests.

Nancy modules are automatically discovered. In this module, we handle requests coming into the server at the /beer endpoint. We will return a Beer view that dynamically populates a list of beers.


The Beer.sshtml file is included with the project as Content and copied to the output directory.


Using some simple syntax, we can auto-generate the HTML markup for creating a list item for each one of the beers created in the module.


Finally, we need to create the Nancy self-host when the console application runs. We also need to tell Windows to open the ports and reserve the URL that we are specifying. If this is not done, the server will receive an Access Denied error and we will not be able to navigate to the page.


Now it’s time to test the Nancy module. When run the first time, the Nancy host will prompt for elevation as it executes a couple netsh commands to open the routes to the server. Subsequent runs may not require this elevation. Once the host is up and running we can navigate to the endpoint with any HTML browser or client.


Nancy has much more to it than what was covered in this post. I suggest you run over to the Nancy Wiki for more information about this neat little web framework.

You can talk to Adam and learn more at Tech on Tap – Nothing But .NET on Saturday, February 28, 2015 – sign up today!

Tech on Tap 3.1 – Nothing but .NET


The Tech on Tap Brewmasters are putting together another event.  This time we’re taking on Microsoft .NET and hope you will come out to learn with us on Saturday February 28th 2015 from 11 am – 5pm at the Stone Cellar Brew Pub.


On February 28th we will be featuring the following sessions

11:00-12:00 LINQ – .NET’s Nifty Little Query Syntax – Adam Driscoll

1:00-2:00 Learning to Weave: AOP and Other Threads – Jon Cwiak

2:15-3:15 How do you know if the Cloud is right for you? – Larry Palmbach

In addition to the sessions, the Stone Cellar will be providing a Brewery Tour after lunch.

Click the link below to register for Nothing but .NET and join us for a day of learning and beers.


Register today!

Bringing PHP to Tech on Tap

The Tech on Tap brewmasters are at it again. For our next event we are switching things up a bit. On September 28th we focus on web developers:





We’ll have more details about the speakers, sponsor companies, registration information, and of course the beers here soon. Watch this space in the next few weeks.