Friday, April 26, 2013

My thoughts on technical debt take 2


I did a bad job last week conveying my thoughts on technical deb. A friend that knows me well enough to have an idea of my opinion on the subject let me know that the post didn't sound like me. So, I'll take a minute to try and review what i was saying.

Technical debt as it was originally defined, can be a useful metaphor. My very limited knowledge of how Ward Cunningham originally presented it was that it was not a deep dissertation on the subject but just a little statement that started with "Shipping first time code is like going into debt." The idea being, all the little shortcuts you take to get first time code shipped are like debt, and in order to support and maintain that code going forward you will eventually need to pay that debt back; the sooner the better. If you don't pay that back, the codebase will become unmanageable and the cost of change going forward will keep going up.

Ok, fair enough. A little metaphor to help us be conscious of the cost associated with shortcuts and decisions we make early on in order to ship code faster. And a very good metaphor at that. To be fair though, the opposite end of the spectrum is filled with cute little metaphors and acronyms too; premature optimization, YAGNI (you aren't gonna need it), analysis paralyses, etc.

These metaphors can help us make decisions around things we do and don't do during the process of building and shiping working software. But, to complicate matters, on any given project you will have varying levels of developer experience and skills, and the answer to these questions won't always be the same. I'd probably go out on the limb to say even if you take a room full of developers with basically the same rating of skills they would make varying decisions along these same metaphor points.

Interestingly enough, in my previous post, I really wasn't talking about any of that. I was talking about something I'm calling "Technical Debt brouhaha". Which is more about the manifestation of the technical debt metaphor into something toxic.

When a term like Technical Debt becomes more then a metaphor used to help make decisions, and instead is used by developers of a codebase on a daily basis it can become toxic. When it becomes toxic, developers start using technical debt to mean:
This code sucks.
This isn't how I would have done it.
This code is too procedural.
This code is too object oriented.
Why are you using this gem, plugin, etc; thats a liability.
Why did you write that yourself instead of using this gem, plugin, etc.

Do you see where I'm going? There is a huge difference between using a metaphor to help make decisions, and instead just complaining about stuff. Often, once this toxicity starts it spreads like cancer, and soon every developer in a shop hates being there on a daily basis.

Sure we all have to let off steam. And some codebases and some environments really do suck. But as a professional software developer, you owe it to yourself, your client or your employer to do your part to try and leave the a code little better then you found it. Regardless of the reasons the code is the way it is.
I've been known to get in some pretty heated debates with other senior developers on a project. But its always because I believe what I'm fighting for will make things better. I try to keep that behind closed doors. And when I loose those battles, I come out and do my best to make the given path as good as possible. Debate can be healthy and good for a project. Complaining is toxic.

How about this. Instead of complaining about all the technical debt your codebase has, try to think of one little thing you can do to help make it better. Just one little thing you can do with this current commit that can help make this codebase just one tiny bit better then it was before this commit. Then think about something you can do to grow upon that. What makes this code so painful to work on that you just hate it? How can you at least abstract that pain, and then share that with the other developers? Soon you will laugh about it and say "why didn't we do this sooner"? Be the snowball that starts the avalanche of good, and not the toxicity of complaint.

Tuesday, April 2, 2013

my thoughts on technical debt


I'm calling bullshit on the "technical debt" brouhaha. Everywhere I turn I hear developers blabbering over technical debt. Developers crying about "repaying all this debt or we will be crippled.' Blah, blah, blah. Bullshit. 

Don't let the fear of technical debt stop you from building software that has business value. Ever. Its software. Its not steel and concrete. Software, is meant to be changed, modified, patched, and often thrown away. Yes, the results of some decisions will be more difficult to change then others, but it can all be changed.

Technical debt really only matters if your app is a success. And by success I mean that the app adds business value and has a reason to survive, be maintained, and grow. And by this definition, it is already a success.

Conversely, technical debt is forgiven and means nothing if your app ends up not serving a business need and has no reason to be maintained and grow. 

Every app has some technical debt. Most apps I work on have a lot of technical debt. Shortcuts, bad decisions, tightly coupled code, huge classes, little or no test. Often these decisions make my job hard and cause fixes and enhancements to take longer. But at the same time, I know that all these warts and problems are part of something greater. Something called shipped product. Something providing enough business value to someone somewhere that the app owners can afford to pay me to enhance them and make them better. And thats pretty special. 

I have hard drives full of pet projects and weekend work that was created in the spirit of minimal technical debt. But most of those projects are dead on the vine. Not because of their technical merit. But because they never got completed and shipped or didn't provide the business value I thought they would. Shipped code that is providing value to someone somewhere is a special thing. 

As professional software developers we go to conferences, read and write books on our craft, and constantly try to better our game. And all that is good and important. But none of that matters if there isn't shipped software providing value to people, and that is what matters most. 

I have seen more successful software in the wild providing business value that was written by people that just weren't that good at writing software, but figured out a way to ship and fulfill a business need, then I have pristinely written code. Its just fact. Warts and all, shipped code providing business value trumps pristine code sitting on a hard drive. 

So, lets help our clients or employers by making code better and easier to maintain. Because that is what professional software developers do. But lets rein in all the technical debt preaching, ranting and bullshit. It was a cute term for a day or two.

Build it. Learn from your mistakes. Make it better. Create value.

Wednesday, November 9, 2011

slim from a haml user's perspective

I've been a fan of haml since first taking a look at it in 2007. I use it almost exclusively on all my projects. Lately, I've been hearing more about slim and decided to have a look. Both template frameworks share similar goals of reducing the amount of html syntax so you can focus on your content and semantics without all the brackets, and open and close tag syntax getting in your way. Slim also claims some pretty impressive performance benchmarks.

Slim's 'about' page claims you can make it look more like haml by using id and class shortcuts, but that they are optional in slim. This struck me as a bit misleading, because regardless that haml id and class shortcuts are popular with haml users, they aren't necessary in haml either. They are a completely optional choice in haml as well.

There is a fundamental difference in how markup versus content is treated between the two frameworks. And, after working with slim for a few hours, I'm not sold on its syntax. Maybe its my years of familiarity with haml that is causing some friction.

Haml takes the approach that html elements start with a delimeter and then your content is free to be nested or included inline. This makes sense to me. If I was writing normal html, my elements would be delimited by brackets wrappers, and my content would flow within.

Slim, on the other hand, assumes that html elements are not delimited, but content is. I'm not being completely fair here because inline content is not actually marked up separately from being on the same line as an element tag. But, content either needs to be inline with an element tag, or marked up with a pipe or backtick.

From the slim documentation:

Add content to a tag

Either start on the same line as the tag

body
  h1 id="headline" Welcome to my site.

Or nest it. Note: Must use a pipe or a backtick to escape processing

body
  h1 id="headline"
    | Welcome to my site.



A similar example in haml, might look like:

%body
  %h1(id="headline") Welcome to my site.


or

%body
  %h1(id="headline")
    Welcome to my site.


For me, the slim approach seems bass ackwards in this regard. Perhaps its just my familiarity with haml, but this fundamental difference kept nagging at me while I tried slim out for size.





Friday, September 23, 2011

installing ruby-debug19 with rbenv

Here is what worked for me. Obviously change path to work for you and your specific ruby version:

gem install ruby-debug19 -- --with-ruby-include="/Users/scott/.rbenv/versions/1.9.2-p290"

Monday, September 5, 2011

Rails 3.1 require_tree CSS

This is a post about a Rails 3.1 convention and choice used to assemble your application's CSS file. Its not a post about the general idea of the Rails 3.1 asset_pipeline, but assumes familiarity with that. I also offer a simple alternative that might be considered that isn't too far off from the default.

It's a trivial thing that I've griped about a few times, but the choice in Rails 3.1 to link to a application.css manifest file that includes a "require_tree ." directive off of the app/asset/stylesheet root is imho a stupid convention. For one thing, when building a CSS solution for an application, the order of the included CSS matters. And if all of these CSS files are assembled into a single application.css, the order of inclusions still matters. I realize that it is simply the default application.css, and it is very easy to delete the one line that says "require .". But if every real application will need to do this, then I think its a pretty stupid convention.

If your entire application's css file was only ever the assembly of some n controller_name.css files, then this would be a moot point, and the Rails default "require_tree ." would be fine. But I think its a fair statement to suggest that is fairly close to never the case.

I appreciate the idea of making things dead simple for people just getting started. And I get the fact that the default action of a controller generator is to create a controller_name.css.scss file. And I get the fact that this "require_tree ." by default provides a out of the box experience that stitches all these files together to create your application.css.

The problem is that seldom if ever in an application do you create a CSS solution that doesn't involve some hierarchy to its style rules. Often you will include some basic typography rules defined in one or more files, some basic layout rules in another, some basic color rules in yet another, etc. and then apply some hierarchy of granular changes on top of these as necessary. Even if you don't take a typography, layout, color approach to foundation, in any real application you will have some foundation rules, that are then refined in a cascading or granular fashion, where the order of these subsequent granular rules is important.

Additionally, in applications built today, you often have a different set of basic foundation rules applied for different reasons (different section of your application, different media, different browser, different resolution, etc.). In the Rails 3.1 asset approach, all of these styles will need to be defined at some point under app/assets/stylesheets. You would almost never want everything under your stylesheet root to always be included, and especially in a manner where order has no significance!

So, my basic gripe is that seldom (if ever!), will you have a situation that suggests assembling all css under your "root" css directory will make sense. And additionally, this will almost never be a best practice convention that anybody building a real application would be able to use. So, why does Rails 3.1 use this as its out of the box convention?

A fair alternative to the out of the box convention for Rails to follow might be to build all controller_name.css.scss files in a subdirectory off of app/assets/stylesheets, perhaps app/assets/stylesheets/resources (or controllers). And then the default convention in application.css might be to "require resources/." by default.

Then if Rails wanted to promote some additional best practices, they might include some top level foundation css (like typography, layout, color, etc.) or even just a base.css.sass that could be explicitly required in the application.css to give the new developer a convention that is at least built upon some real world best practices to creating CSS solutions.

A default asset pipeline application.css file that looks like this:


/*
 * This is a manifest file that'll automatically include all the stylesheets available in the resources directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * immediately after your foundation styles, but it's generally better to create a new file per style scope.
 * Application foundation styles
 *= require 'typography'
 *= require 'layout'
 *=require 'color'
 * Specific styles
 *= require_self
 *= require_tree resources/.
*/


or even just this:


/*
 * This is a manifest file that'll automatically include all the stylesheets available in the resources directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * the top of the compiled file, but it's generally better to create a new file per style scope.
 *= require_self
 *= require_tree resources/. 
*/

instead of the Rails default of this:

/*
 * This is a manifest file that'll automatically include all the stylesheets available in this directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * the top of the compiled file, but it's generally better to create a new file per style scope.
 *= require_self
 *= require_tree .
*/



Monday, May 23, 2011

customer satisfaction

I'm not a fan of customer surveys. I actually think it sucks when I spend my money for a product or service, and then you expect me to also give my time for a survey. My time is very valuable. I already paid for your product, and now you want my time? Its actually a ridiculous expectation. I especially hate surveys that go on and on asking the same question in slightly different ways each with a 1-10 scale option. Blah....

Want to know how you are doing? Am I repeat customer? If so, you are doing ok. Thats a good start.

If I get great service or find a  great product, I'll tell all my friends about it. And if I get shit service, I'll scream loud and clear. And the good news for you, dear marketing department, the world has changed. You can actually listen to me tell my friends about you via Twitter, Facebook, blogs, badges, etc. You don't have to ask, and ask, and ask, you just have to LISTEN!

I spent the first few years of my professional life working for a fairly large family business. When I started with them in the mid 80's they were still family owned and most of the top brass were either family or people that worked their tails off to be a part of the family business. I was talking with a friend a few days ago, who also happened to begin his career with a very well respected family business. They both had customer loyalty like you wouldn't believe.

Its true that the loyalty didn't come for free. And the loyalty definitely didn't come from survey questions on a scale of 1-10. During their hay day, they didn't spend money on customer satisfaction surveys. No, instead they spent money making customers happy, and building a reputation of quality. And they demanded nothing less from their employees.

I remember hearing the company president's son (he was in charge of marketing at the time) say something along the lines of "we strive to create a total quality experience around our company and product" He went on to describe how this idea was completely encompassing. When somebody notices one of our tractor trailers on the highway, its important that it speaks quality. The trucks had be clean, run well and be worthy to carry the quality product inside. And so they had their own mechanics, truck washers, and top of the line tractors that most truck drivers would dream of driving. The manufacturing plants had tours open to the public, and most school children in the area had a chance at one time or another to take a tour of the plant and see how state of the art equipment was used to bake 10's of thousands of loaves of bread a day, as well as cakes and the then famous chocolate chips cookies. All to showcase the company quality.

As I was talking with my friend, we realized that we shared similar war stories. Various things we were expected to do, all in the name of customer satisfaction and building a brand of "quality" around the business and service. It was not that uncommon to finish a 12 hour day, and get a call from the tiniest of tiny customers in need of additional product (a fish fry joint out of rolls, a corner store out of bread for the weekend, etc.) It really didn't matter if it was huge $5000 a week supermarket or small mom and pop grocer that did about $25 bucks a week in business. If a customer called with a real need, we did what we could to make them happy. Often it meant bringing some product with us on our way home from an already long 12 hour day, just to make a customer happy. Often the extra trip involved getting back in a delivery truck and heading out for another hour.

And often the overall "extra" work, if measured as a line item on spreadsheet would come at a loss. The gas, time and effort to drive a 25 mile round trip just to deliver a few dozen extra rolls to a fish fry joint probably looks insane on paper. But if that happened to be a Friday night during Lent when that fish fry joint did more business in one night then they might do agin in the next few weeks... well then the return is unmeasurable! From the owner, to everybody working there, to the customer's customers that see you making the delivery at 7:00 pm on a Friday, you deliver a message about your company. And during their hay days, that loyalty was rewarded with mind boggling market share over the competition.


 Over the years, and a few generations removed, often these business that did things the right way get bought and sold and the original message gets lost. Instead of spending money on quality and earning true customer loyalty, its about the bottom line of every action, as if every action is a stand alone decision. Little by little things happen. The tractor trailers get farmed out to a hauling company. Eventually people see them carrying your product around in dirty crappy smoky trucks. Plant tours are closed for insurance liability reasons.  And the fish fry joint that calls looking for a few dozen extra rolls at 7pm on a Friday gets a recording "sorry, we are done making deliveries for the night, but we will have somebody there first thing in the morning"

But, its all good, because we are hiring this new image building company, and they have suggested this new whiz bam customer survey that helps our customers feel empowered towards driving change back into the organization.

Forget the survey. Don't waste my time. Just make me a real happy customer. I'll tell all my friends about you, promise.

Friday, February 11, 2011

Cathedrals, Chapels, and Programming

I was reading some classic essays from The Cathedral and The Bazar by Eric S. Raymond tonight, and for one reason or another got reminiscing a bit about the environment and time associated with some of my first introductions to programming.

During the summer of 1982 I was heading into my senior year of high school and I took an introduction to computing fundamentals course at RPI.  I wanted to be an electrical engineer at the time and badly wanted in at RPI, and figured a summer course would help my chances. I can't remember if that summer course was actually part of the Computer Fundamentals for Engineers FORTRAN program that I later took over the next few years, or if it was just a precursor introductory type of thing. But, my 'welcome to programming days' were all based on IBM Mathematical Formula Translating System language while preparing to become an electrical engineer. 

At the time, I thought of programming as just glorified calculator/slide rule usage. A way to store your mathematical algorithms (punch cards, magnetic tape, etc.) for load and replay so you could later feed some input to it. I didn't look at the kids that intended on studying just the programming stuff as real engineers or science. I couldn't understand why anybody would choose a curriculum based on learning about different ways of typing in algorithms. Us real engineers were going to build these machines!

But, a funny thing happened. The seeds planted during those Computer Fundamentals for Engineering days took root. I never did become an electrical engineer, and I had to course correct a few times before realizing in the early 90's the passion I actually had for software development. 

Back at the beginning of this post I mentioned that I started this reminiscing while reading some essays. The essays are a combination of programing history, culture, and the author's experiences used to describe different development methodologies. The Cathedral and Bazar references are like a parable that helped convince most open software projects to adopt Bazar like (open, transparent, bottom up, lots of people contributing and testing) methodologies.

So, why did an essay about a cathedral reference, as well as a religious like parable remind me of my early introductory days to programming. I mean despite my passion, I'm no real hacker like the folks mentioned in these essays. The answer however is quite simple. The Chapel.

Back when I took those Computer Fundamentals for Engineering courses at RPI, the campus Computer Center, was also known as the Chapel. Well, actually it really was a chapel. The Vorhees Computing Center was actually a chapel built for the Sisters of St. Joseph in 1933, and converted to the campus computer center in 1979. Not only was it a chapel, but it had a friendly spirit known as Myron at the time. Myron was an IBM 3033.