Continuous Improvement

When I first started programming, I was under some illusion that one day, once you learned enough about the language, runtime, or design patterns, you could hammer out some brilliant lines of code, they would work almost magically, and you’d never need to touch it again!

Boy, was I wrong.

Turns out, there’s this word.  You all know it.


We have a similar word in Lean/Six Sigma.  It’s called ‘Kaizen’.  In short, it means continuous improvement, but it has far reaching implications.  The word has its roots in Japanese culture & business (books that were written in the 80’s reference it), representing a philosophy of using data to constantly improve processes.  The major focus here is that it represents incremental improvement, not “big bang” improvement.  In the image below, the blue sections are slow, gradual improvements, intermingled with large jumps representing major advancements (red).

A more traditional visual of Kaizen may look something like this –

The key takeaway is that improvement happens gradually, and constantly.

A key tenet of Agile development (as argued by Dave Thomas of Agile fame) is that Agile software development is merely the process of making a small change, pausing to take a look at whether the changes have had a positive impact, and then course correcting if necessary.  Looks like the chart above doesn’t it?

A major component of this is refactoring.  In my opinion, every time a development team touches a codebase, they should leave the code in a better state than when they found it.  The goal here should be to improve readability, performance, organization, and overall flexibility of the code.  A Six Sigma-minded company pursues these opportunities to reduce waste, and only the worst run companies believe that waste is only financial.

Waste takes many forms – wasted time, effort, and talent, and all 3 of these are extremely relevant in software.

Wasted time results in delayed project deadlines, compressed testing, inter-personal frustrations, and a more rushed workflow in general, and rushing does not work in IT.  Sales people and high powered business folks may work better under tremendous pressure, but trust me, developers don’t.  Coding is a calculated and involved mental activity.

Wasted effort turns a 1 hour task into a 4 hour one.  It means you spent 3 hours copy pasting data from a spreadsheet into a custom JSON structure used by your app, only to find that in the end, it needed to be CSV format, and you could have just done a straight export from Excel.  Additionally, developers love efficiency hacks.  If wasted effort becomes a routine occurrence, they will rapidly become frustrated with their job, and will have reduced output and problem solving ability.  This makes for reduced team morale, and potentially increased turnover – something that HR teams may raise their eyebrow at you for.

Wasted talent is a truly hidden waste, and can silently kill large companies who are not prepared to respond.  A good friend of mine works extensively in finding and retaining the best talent for his business teams, and we’ve discussed this at length.  Hopefully I don’t need to justify this point, but if you think that all developers are worth the exact same amount, you have much more to learn about high quality software development. Steve Jobs probably could probably explain this better than I could.

Refactoring took me many years to fully appreciate, and I must admit, I’ve really come to love it.  It can feel like it can be its own art form sometimes.  Now, if you don’t have unit tests as insurance for all of your changes, you should probably go back to basics and get those up and running.  “Deploy with confidence” and all that.

There’s a ton of great material out there on refactoring, and I have yet to pick up my copy of the Fowler book on it. But, I’m keeping it simple.  Know your code smells, and make a series of small improvements in an effort to reduce waste.  If the design problem presents itself, maybe integrate a design pattern and assess the solution in a code review.  Over time, trust in the process that your codebase will improve over time.  The next developer will love you for it!


The Evolutionary Architect

In the midst of tackling this guy:


I can’t even begin to express how encouraging and refreshing it is to have so many of my thoughts and concerns finally captured into written word and gaining momentum.  Things like domain boundaries, and the fact that data duplication is OK if done in the name of scalability and development team autonomy.

Not that I’m anywhere near Sam Newman’s experience and knowledge, mind you.  But my posts are fairly clear when it comes to my philosophy of design.  The database is not king, sharing a monolithic schema can and will kill your ability to scale in ALL of the following areas: product feature change, team delivery speed, reliability of the software, and uptake of new development talent.

“A good software design is easier to change than a bad software design.” – “Pragmatic” Dave Thomas.

(his blog)

One thing I truly admire about this book is Sam’s pragmatism.  He’s not trying to sell you microservices, he moreso does a thorough pro-con analysis.  The people that should appreciate this most are, indeed, software architects.

In chapter 2, The Evolutionary Architect, Sam goes through and does a deeper dive on what it means to be an architect, how we as a software development community have misunderstood the word over the years, and how a true definition is still up for grabs.  Honestly, I completely agree with him.  “Back in the day”, when I worked for Global Quality at a Fortune 500, I had the opportunity of a lifetime to study Six Sigma methodology with a true master of the craft.  This person not only knew the ins and outs of the methodology and the process, but they were responsible for managing a large global team.  It was under this person that I learned, by example, how an evolutionary leader can be both a master of a specific process, but also step back into a management role and empower their team to execute that process.  As team members (and myself as a junior member at the time), we can and will fail.  It is the architect’s (indeed – any manager) role to mitigate that failure, and manage the complexity involved.

It is an architect’s role to manage the complexity of a software product, not to increase it.

Unfortunately, since leaving that particular company, I have yet to meet another leader anywhere close to that magnitude of employee empowerment, mentorship, and expertise in both the “product” and the “people”.

So, back to Sam’s points (now that I’ve given you my background and why I agree), he states that the architect’s role is often that of a tech lead.  Based on my experience, alot of tech leads get less than 2 hours of coding per day, and are often caught up in meetings and company bureaucracy which prevents them from being directly or actively involved in the development. Sam states (and I agree) “More than any other role, architects can have a direct impact on quality of the systems built, on the working conditions of their colleagues, and on the organization’s ability to respond to change.”

This then, makes them such a strange hybrid of technical, but also leadership expertise.

Personally, I’ve seen both extremes – an architect who injects their opinion into code, without consulting the pragmatic ideas of the rest of the team (who in turn has to own the end result), and also the architect who is so hands off that their responsibility is configuring TFS and learning how to use Git so that they can tell the other team members to go Google it.

Neither of these scenarios capture the true essence of an architect – but Sam goes on to say we’ve actually borrowed terminology and not fully understood the impact – and that the role is very well defined in other industries, like engineering, where there is a specific, measurable goal.  By contrast, software engineering is less than a century old.

Trebuchet "is a" type of catapult - right?
Trebuchet “is a” type of catapult – right?

“Architects have a duty to ensure the system is habitable for developers, too”.  This is critical – tech turnover is still high.  Developers leave because they don’t like working with your codebase (yes, Mr. architect, you’re responsible for the overall quality of your codebase – go sit with your juniors now), or because benefits, culture, and environment is better at a different company.  In my experience, a company that invests wildly in the satisfaction of their employees retains better talent for longer.  Software is unique in the fact that you can invest in your developers with shiny tools and conferences, instead of being limited to “only” monetary compensation (like a sales team for example).

“If we are to ensure that the systems we create are habitable for our developers, then our architects need to understand the impact of their decisions.  At the very least, this means spending time with the team, and ideally it should mean that these developers actually spend time coding with the team too.”

This could be pair programming exercises, code reviews (you don’t get to complain about quality if you don’t put forth a concrete solution) or mentoring sessions.  If you’re an architect that only knows how to create stored procedures which end up creating multiple dependencies and breaking changes for more than one application, then you need to stop calling yourself an architect, and start doing your job – developers hate working in environments like this.  Stored procedures make for top-tier database performance, and the absolute lowest software agility (if misused) – since your dependencies cannot be managed from within your solution.  That “one guy” has to “remember” that “oh, when you change this sproc, these two applications will break”. Not fun.


Sam compares the architect to more of a town planner – they don’t get to decide which buildings go where, but they are actively involved in IT governance, and pragmatic decision making (read: data-driven) – i.e, they zone out areas where commercial and residential buildings will eventually go.

Anyone remember SimCity?

A town planner does not have the power to add and remove buildings or real estate developers from those zones.  Often times, it’s developers who are on the cutting edge of new tools that can achieve various outputs, and they should be empowered to deliver on the desired quality.  If you’re dictating who is consuming which stored procedures, you’re a town planner who is calling up Wal-Mart and asking them to move in.  If your development team has assessed the risks, and has pragmatically agreed on Costco or Meier, you need to let them do their job.
I’m also a big fan of governance through code, as this hearkens back to my Six Sigma days of mistake-proofing a process.  This can open up a whole new area of discussion, such as how Resharper, or architectural styles like DDD, REST, and CQRS can enforce best practices (as defined by you) at a code level.  Another discussion for another time!

For any fans of mainstream house, you may be interested in Deadmau5’s new album – W:/2016ALBUM/ (not a typo!)

Same Old Situation.

One of the key features I like about Agile estimation is that the members on the deliverable side get the final say regarding the size of work.  Traditionally, I’ve been a part of Fibonacci numbers, though I’ve heard some excellent arguments for T-shirt sizing (no surprise – finance wants to correlate everything to man hours for tax deductions, but this an outside interest which shouldn’t interfere with the estimation process itself).

Has anyone been part of a project estimated by a singular entity that’s not writing code?  It can be extremely frustrating.  It’s funny – the younger developers think it’s a problem unique to them – but the older developers have “seen it all”.  I had a great conversation with an older, ex-C++ developer, and we brought up The Mythical Man Month.  If you’re not familiar with Brooke’s law, it states something to the effect of “adding manpower to a late software project makes it later”. I say that because the book is on my list of reads, but I technically haven’t read it yet.  I notice some companies believe that any problem can be solved by throwing more manpower at the problem, without any regard to the quality of the product or developer skill/mindset.

There’s something about the “McDonald’s Developer” that irks me.  The idea that I can snatch up any Joe off the street, and in a handful of hours, teach him how to flip a burger and write code.  What’s so difficult for me to reconcile about this issue, is that McDonald’s (and most fast food chains) are among the leanest businesses in the world.  They have to be – fast food is fiercely competitive.  My Lean/Six Sigma brain wants to agree – but my pragmatic developer brain can’t seem to understand how this results in a high quality, maintainable product.  Developers who tend to fit this profile think of their problems in terms of for loops and making sure they check for null.  They haven’t had enough time in the industry (or around better developers) to look at architectural concerns, proper structuring of code to follow SOLID principles, and constantly analyzing what they write to find cleaner, most readable and efficient patterns.  This primitive skillset is then propagated by higher ups who don’t see the benefit of empowering these new developers, or simply don’t know how to grow the potential of a junior member.  Outsourcing has had a detrimental effect on this situation, as that mentality feeds the idea that more asses in chairs will solve your problem, when the truth is a good development team will design a system such that some obstacles will never even arise.  Boy, that makes it difficult to claim a victory for solving a problem by preventing it.  Anyone who’s ever worked in quality or been around manufacturing would understand all too well.

I think part of the way that I reconcile this McDonald’s mentality is that the architecture and framework of your application(s) should make it difficult for poorly designed or written code to enter the system.  This hearkens back to the mistake-proofing idea in Lean.  The process itself should be set up to minimize risk for any negative factors.  There are more than enough design patterns which make it easy to reason about the structure of a system without having to dive into thousands of lines of code.  It’s not that McDonald’s employees are any less capable or intelligent – it’s that the process sets them up for success and makes it difficult for them to mess up.  I’m allowed to make commentary here, having worked part-time in retail food myself.

Coincidentally (or not), I’ve noticed that places where the outsourcing mentality are prevalent have little to no code review practices – does that say anything about their value for their internal customers?

Starbucks is another example of treatment of internal customers.  It’s pretty obvious their culture attracts certain types of people (if not stereotypical).  It’s a very similar corollary – the processes they have in place make any given drink virtually identical, no matter who makes it, or where.

Does this mean their employees, who are part-time, single digit hourly wages, are any less deserving of investment?

Not at all!  In fact, I have a few friends taking advantage of the Starbucks education benefits and wrapping up their undergraduate degrees.  They may or may not be with the company in 5 years, but then again – most tech professionals won’t be either!  Costco is a good example of a company that is well known throughout Wall Street  as investing so heavily in their employees that they  have the best employee retention and customer satisfaction rates.

As I explore this idea more in the future – I’ll be sure to write my new discoveries on it.  In addition to the the rush I get from refactoring badly written C#, mentoring newer developers is near the top of my list of favorite things to do.  And I have a feeling that if they feel invested in, and are growing their skills, it’ll reduce the dollar and time waste involved with maintaining the revolving door of new hires.

I’ll have to end today’s post with a song of the same name.  Sublime, whose title album went five times Platinum largely due to the success of “What I Got,” has a very college reggae/party ska feel, which tends to be a very specific taste.  I always felt their music was fun, but not something I could commit to buying a physical copy of, or listen to repetitively and recommending to others.  What I didn’t know, is that their frontman, Bradley Nowell, died in 1996 – and the band dissolved soon after.

Turns out, they reformed with a new frontman in the late 2000’s – and it’s awesome.  The new singer/guitarist is Rome Ramirez, and they perform under the name Sublime With Rome.  This has to be some of the finest reggae to come out of the West Coast – Rome’s voice is amazing, the music has a very timeless feel.  I actually listen to it as rarely as I can, for fear of ruining the magic.  It’s like Sublime grew up, graduated college, and found its identity – the percussion is bang on, it’s well mixed, has a deep reggae vibe, and Rome’s voice keeps thing very fun, without being stereotypical reggae, as can be common in the states.

Check out Same Old Situation.

No REST for the wicked.

I tend to be an obsessive person.  I’ll get really excited about a technology, automation tool, open source library, or data related “thing”, and just be consumed for weeks, or months on end.  It happens with some games I play as well.  My wife, back when we were dating, even told me that she was fearful for a time that she was just another one of my obsessions that would fade.  (Don’t worry – we’re happily married!)

Lately I’ve been in between obsessions, and seem to be fishing around for some cool things to do.

Random aside – the words “I’m bored” you will NEVER hear me say.  Life is too short to stop learning, and the amount of things I do NOT know terrifies me.

Anyway, I completed a server build last Christmas, and I’ve been digging into some areas of network security that have been weak points for me.  Specifically a course on Pluralsight on Wireless Security.  Sure, taking care of the router at home is a trivial task for even the most average of IT people, but it was great learning about encryption IV’s stamped into the firmware of routers for the WPS feature.  I always disabled it because it “felt” insecure.  I’m a web developer, it’s not hard to imagine the myriad of techniques hackers use to compromise our precious data-driven websites.

My brother in law has been engrossed in Linux administration recently, and it’s got me thinking about my weak PowerShell and windows command prompt skills.  I’ve always been such a strongly typed .Net thinker that command line apps are giant “magic strings” for me – they almost feel dirty.  I won’t tag this post under code smell, but I’d love to go over magic strings in a later post, as I find them all the time and constantly have to refactor them.  I digress.

I feel like my brain has more control over me than I do over it.  (How’s that for meta-humor?)

But really.



So here’s my list of possible undertakings:

  • Buy a Raspberry Pi
  • Learn to Administer said Raspberry Pi via command line
  • Dig into system admin tasks for my Windows Server 2012 box so I can better understand the infrastructure side of IT
  • Hack my home WiFi with old, useless laptops, in the name of improving home security
  • Start shopping for new server components – do I want to build a new one the size of a shoebox?
  • VM a Linux box and just have fun learning that
  • Educate myself on Active Directory so I don’t appear like such a dolt to other IT admins
  • Continue my research into .Net based web scrapers, and see if I can spool up anything with .Net Core

The Pi’s have me really excited – I’m dying to set up a network of them so they can all talk to each other via RESTful HTTP calls.  Have I mentioned how much I love REST?  Using HTTP as it was originally intended – really helps to model out solution spaces for complex data services and Web API’s. I’ll go into that in another post, with concrete samples of how I’ve approached this in my own ASP.Net code.  I can imagine exploring the wonders of message queues and callback URI schedulers to coordinate automated tasks between the Pi’s – sending me texts throughout the day when one of them has finished scraping customer reviews for a product I’m researching.  I’d love to host a MongoDB node on one if it’s feasible!

I’m sure I’m missing a few from that list.  And I’ll watch a few movies and TV shows until something grabs a hold of my brain again.  Let’s just hope it’s not internet spaceships this time.

Today’s song is titled with this post.  It was wildly popular on the radio for awhile – I would still consider it more or less radio rock.  Generally people are pretty polarized on Cage the Elephant.

Ain’t no REST for the Wicked

Does this make your blood boil?

A group of professionals converse at a table, discussing a recent project delivery.  Amidst the banter, the following statement garners the attention of the room:

“You know, without us database guys, you developers wouldn’t have anything to develop!”

Chuckles all around, and a particularly opinionated business systems analyst comes back with:

“Without analysts to make any sense of your crappy data, nobody would care about your databases!”

The developers said nothing because, well, they’re developers.


Ever heard this kind of discussion?  I’ve witnessed a more serious version of it on more than one occasion.  In case you don’t know the appropriate response, let me go ahead and lay it out for you.

The quarterback on a football team huddles with the offensive side after making a play, and says to them:

“You know, if you guys didn’t have me throwing such great passes, this team would be nothing!”

How do you think they would respond?  How would you respond?

Being a team, then, by definition, none of them can fully execute a meaningful play without all roles and players allotted and focused on the goal.  Imagine the best quarterback in the world, throwing passes to middle school kids who are good at math, not football.  What’s the score of that game?

Naturally, the same analogy holds true for most sports – anything where specialized skill sets have to converge according to a common goal.

Of course, one of the lurking factors here is that each of these technical roles are compensated differently, but salaries are a matter of subjective compensation for a given skillset, negotiated according to geographic medians and other factors determined by payroll consultants and hiring managers.


“The database is king”?

“Nothing is more valuable than a company’s data”?

I honestly view these statements as a form of intellectual hubris.  

That may seem a bit harsh, so allow me to explain.  I’ve worked for companies where certain departments definitely had special treatment, but it’s one thing to receive that treatment and it’s quite another to believe in your soul that you are entitled to that treatment.

“Nothing is more valuable”?  Really? What about leadership inspiring purpose and pride in the hearts of thousands of employees?  What about a business product improving the lives and experiences of millions of humans across the globe?  How do you put a value on those things as compared to some bits on a hard drive?  (Any counter-argument here saying that those statements all require a database completely missed my point and should start re-reading this post from the beginning).

Now there are a couple things to which I will concede.  A company’s data, if managed well and correctly, can, and should stand the test of time.  A poorly designed database, will cripple the ability to wield it effectively, and in some cases, slowly and painfully degrade application innovation over the course of many years, and in some scenarios, many decades (I’m looking at you, AS/400). Speaking as an object-oriented thinker, nobody knows the pain of objected impedance mismatch more than myself.

I’m able to say with confidence that a company’s data is not its most valuable asset.  I’d stake my life on it – and it raises the question – what, then, is a company’s most important asset?


I’ll say it again – let it go down nice and smooth.

People are a company’s most valuable asset.

Not your product, not your data, not your dollars.

Your employees are the product innovators, the customer advocates, the value creators.  Data is one of many tools in the toolbox.  And, trust me, you don’t need to sell me on it’s importance.

While the discussion in my opener happened to be lighthearted – there are those who would fiercely debate points and counterpoints to it.  The essence of the discussion is a non value added proposition.  If you catch anyone engaging in this discussion, do yourself a favor.  Shut it down with logic and pragmatism.  Get the group talking about something more useful and exciting, like why you should shift gears like a samurai.

Alright, that’s enough of that.  Today’s artist/song is a callback to the title.  For awhile now, I’ve been itching for a good Rock sound similar to the Black Keys – and I’ve definitely found it in the Icelandic rock group Kaleo.  ‘Hot Blood’ is one of my favorite songs recently, and aptly describes what happens to me whenever I’m drawn into another pointless, futile question of, “Which is more important, the application or the database?”

First things first.

So for my first substantive post, I want to talk about something which is near and dear to my heart.  Something which sets the tone and foundation for this entire blog.  Something that was instilled into my brain years and years ago by a man whom I would consider a valuable mentor – and someone who is truly dedicated to the measure of quality, down to their innermost core.

Let’s kick this off with a question.  One of the most contentious questions in business.

What is quality?

How you approach the answer to this question determines the starting point for how you answer this next one:

What is software quality?

I know what you’re thinking – too broad for a blog post.  You’re right.  Heck, so many books have been written on this topic I probably couldn’t keep all of them on my bookshelf.

Let’s look at some key questions that we, as software developers, should seriously be considering as we produce and improve our digital product.  Again, most of these questions arose from the fundamentals of manufacturing quality, Six Sigma, and Lean philosophy, but need to be rehashed to apply to today’s fast-paced world of application design and digital product development.

How do we know that the application we’ve built is of high quality?

Who determines this?

Can it be measured?

What if a different development team takes over the product, and they say we are wrong?  Who is right?  What is the criteria for deciding?

Can I look at a codebase and “feel” the quality of the code, or does experience and instinct have no place in a world packed with data analytics, metrics, KPI’s, and issue trackers?

By the way, does any of this matter if I get slapped with a requirements document and am told to make this feature fast and cheap because management wants to get this thing out the door?

Over the next few weeks, I’m going to give my thoughts on the topic, and I’ll try to refrain from being over academic.  But for now, I want to dig into some pretty fundamental concepts.

Any Six Sigma expert worth their salt is going to throw Deming at you, and he would say “The customer’s definition of quality is the only one that matters.”

True, but who is the customer?

During my transition from Six Sigma to Agile/Scrum, I realized any time Six Sigma says ‘Customer’, it can be translated to ‘End User’.

Which means our users‘ definition of quality is the only one that matters?

Not quite.

You see, a fundamental part of Six Sigma methodology is identifying customers in different “domains”, if you will.  The first line drawn is between internal and external customers.  An external customer can be a wholesaler, retailer, or end consumer (this is probably closer to the end user translation).

A critical part of doing business and maintaining high quality standards is measuring, and investing in, your internal customers.  This can be a supplier who makes your goods, the purchase order department, and even customer service representatives.  For some of you, this might be a slight philosophy change.  Yes, after your product goes live, your responsibility goes beyond profits and five star reviews.  Once its out there, it needs to be supported, have its reputation (and by extension, your brand) maintained, and continue to “delight your customers” (following the Deming phraseology).  In the tech world, this is more common knowledge, but you would be surprised at the number of traditional consumer goods companies which cease caring about their product once it leaves the warehouse freight bay.

I’m going to cut myself off here for this week.  I think we touched on a few areas which deserve more attention and I’d like to dedicate individual posts for some deeper thought.

This one’s for you, J.W!



(Credit for the image goes to Tesseract – a British Progressive Metal group, if you’re a metalhead.  I rather enjoy the melodic tones, and their drummer keeps things mixed up and fresh!)

Blog is up!

Today marks the day that the blog is live!  This has definitely been on my mind for many months.  Big thanks to John Sonmez and his YouTube channel for inspiring action and driving me to finally do this.

Just a few words about me.  My name is Andrew, and I started coding in C# around 2010 (professionally since 2013).  Learning the language in the context of game development helped me to overcome a lot of the initial fears that come along with learning programming.  I like to think most of us need clear and distinct goals when picking up a technical skill, otherwise we lose interest, or get discouraged (the latter happened to me – I gave up for a year and almost vowed to never code again).

Nowadays, I’m engrossed in all things .Net, and have found a particular love for Web API’s.  Some people imagine the internet as a giant information superhighway – but there’s something magical about imagining a massive network of multiple superhighways, all linked together and transmitting data to each other in a huge spiderweb of HTTP requests and responses – synchronizing stock quotes, placing product orders, registering customers, and stealing people’s passwords from unsecured WiFi’s in coffee shops.

While my development skills reside in backend C# development, I will also be writing my thoughts of two of my most passionate pursuits – S.O.L.I.D. design principles and music!

Yes, music!

The sheer amount of music I consume on a daily basis is staggering.

I hope you’ll enjoy my musings on new artists I discover, horrible code smells I dig up, and my thoughts on Agile – especially since I spent a few years working for Global Quality under a Fortune 500 company (I’m a certified Six Sigma Green Belt – I like to think I know  thing or two about quality software).

Hope to see you soon!




Copyright Hi, I'm Andrew. 2017
Tech Nerd theme designed by Siteturner