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.

Refactoring.

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!

 

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.

2a0b4d4f5ea25f2d7f60722683af3962

 

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

Thoughts on ASP.Net Core & DI

Microsoft is making big changes to the way they are building and shipping software.

Personally, I think it’s a huge win for developers.  It’s only a matter of time until .Net Core targets ARM processors and all of my homemade applications talk to each other via distributed messaging and scheduling on a Raspberry Pi network.

But the paradigm shift in project structure and style leaves some polarized in their opinion.  The developers who understand the power of Open Source are generally immediately on board.  The developers who still think the best answer to any problem is a stored procedure simply can’t comprehend why you would do anything in .Net Core when the existing .Net Framework “works”.

“Well, it works!”

Ever heard that?

That statement eventually gives birth to the infamous “Well, it works on MY machine…”

Let me tell you something about my philosophy on development.  What really fuels why I do what I do.

The art of software development, in my opinion, is being able to design an evolving solution which adapts to an evolving problem.  I might even give that as a definition to “Agile Code”, but I’ll leave that for another discussion.  I don’t mean an evolving solution as in having to touch the code every second of every day in order to meet new requirements – I mean touching it a handful of times, and the answer to every new requirement is “sure, no problem” as opposed to “Crap – that code is a nightmare to modify for even the smallest tweaks”.

.Net Core facilitates this in so many ways – between amped up dependency management, DI as a requirement, and a middleware styled approach.  Developers have known for decades this is how to build software, and for years have tried to shoehorn this paradigm into the .Net Framework via OWIN and a myriad of IoC containers.  Greg Young, an architect whom I have the utmost respect for, has spoken out against DI containers(specifically the proposed benefit of hot swapping implementations at runtime), but after being confronted with some very challenging requirements, I honestly can’t make an app nowadays without it.  Even for simple apps I make myself – I decide to switch up implementations and benchmark things against each other, but I don’t want to delete code that I’ve written on my own time for fear of reusing it at a later time (No TFS at home..yet…).

The most important aspect of .Net Core, in my opinion, is it forces you to think in terms of abstractions.

It’s disheartening when I’m working with other developers who:

A) Claim to be C# developers and can’t define “coding against an abstraction”

B) Don’t understand that how to properly separate the concerns of code

C) Believe that offloading business logic to the database is a good decision in the name of performance

I have to catch myself here.  It’s easy to slip into a cynical view of others and begin to harshly criticize their talent as I put on my headphones for a three hour refactoring session.  That’s not me.  I believe anyone can code.  I believe anyone can be a good coder.  Good developers, and high performing people in general, are good thinkers.  They know what they don’t know.  They never settle for a single best solution, they pragmatically select the best tool for the job, critically assessing their problem and any potential solutions.

 

This is how I mentor the younger developers that drop their jaws when they see Startup.cs for the first time:

Ignore this entire file.  You need to know two things.  You configure services and you use middleware (thanks Daniel Roth!).

What is it that I need this package/code to do?

Pick the best tool for the problem, and drop it specifically where it belongs.  Concretely, this means thinking about your problem space.  There’s a 99.9% chance you are not the first person to encounter this problem.  What is the most elegant and reusable solution?

This gets the developer thinking about scoping and narrowing their development focus.  Too often they jump immediately to code that actually takes input A and outputs B – it’s our nature.  Usually, as I pester them with questions, they end up verbalizing the abstraction without even realizing it, and half the time the words they use best describe the interface!

Dev: “Well, I’m really only using this code to provide data to my view model.”

Me: “Right – you didn’t even say web service in that sentence.”

Dev: “So it’s a ‘Data Provider’, but it will to go to the web. So it’s a Web Data Provider. ”

Me: “For local debugging though, you need to be able to provide some hardcoded values, and it shouldn’t impact or modify any other code.”

(Blank stare, moderate pause)

Dev: “…Should that be a hard coded data provider?”

Boom.  My job here is done.

For anyone used to working with repositories, DI, and OWIN/MVC, this stuff is child’s play.  The junior developer (and indeed, the fully mediocre developer) need a hand grasping these concepts.  I find that guiding them through a discussion which allows them to discover the solution presents the most benefit.  Simply telling them what to do and how to do it trains a monkey, not a problem solver.  Anyone can write 500 lines of code in Page_Load.  They need to understand the ‘why’.  Personally, teaching on the job is one of my favorite things to do – there’s simply no substitute for the happiness that hits a developer when they realize the power that this new technique has awarded them.

More on this at a later point, but for now, understand the danger that you take on by using that new() keyword.  You may be stuck with that code block for a long, long time.

 

On to today’s music.  I found some more somber sounding folk-pop stuff.  The EP by Lewis Del Mar was a really great find!  (Minor language disclaimer).

 

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!)

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