Archive for the ‘Software’ Category

On Teams: Religious Debates Erode Respect

July 15th, 2010

“religious debates … consist largely of people expressing strongly held personal beliefs about things that can’t be proven. … they rarely result in anyone involved changing his or her personal view. … besides wasting time, these arguments create tension and erode respect among team members, and can often prevent the team from making critical decisions.” – Steve Krug, Don’t Make Me Think

There we have it, religious debates erode respect.

Author: Adam Kahtava Categories: Software, Team Work Tags:

Please, Call Me Señor Developer Not Senior

April 20th, 2010

This March marked my fifth year of working in the software realm and five years since graduating University, and this year (according to industry standards) I’m now considered a Senior Developer.

Funny enough. Today, I don’t consider myself a Senior Developer, but a couple years ago I would have told you to “Call me Senior”. Back in those days I may have been a Senior Developer within the monocultured context of the domain, language, and environment I was working with, but certainly not within the larger context of the software realm. I had surrounded myself with homogeneous tools, like minded colleagues, and had fallen into the trap of thinking I was an expert when I wasn’t – we all thought we were Senior Developers.

“When you are not very skilled in some area, you are more likely to think you’re actually pretty expert at it … The converse seems to be true as well; once you truly become an expert, you become painfully aware of just how little you know.” – Pragmatic Thinking and Learning: Refactor Your Wetware

Over the years I’ve observed that Experts and true Senior Developers are collectively regarded as such by their peers, not by corporate credentials, not by job titles, or duration of employment. Experts and Senior Developers are more preoccupied with getting things done, improving themselves, improving their environments, and helping others – not worrying about job titles and status.

“The people who are best at programming are the people who realize how small their brains are. They are humble. The people who are the worst at programming are the people who refuse to accept the fact that their brains aren’t equal to the task. Their egos keep them from being great programmers. The more you learn to compensate for your small brain, the better a programmer you’ll be. The more humble you are, the faster you’ll improve.” – Code Complete: A Practical Handbook of Software Construction

Please, don’t call me a Senior Developer, I’m Mr. Developer or Señor Developer.

Author: Adam Kahtava Categories: Musings, Personal, Software Tags:

Stop Refactoring

June 19th, 2009

Eric Evans provides this interesting commentary while he discusses refactoring targets:

When you encounter a large system that is poorly factored, where do you start? In the XP community, the answer tends to be either one of the these:

  1. Just start anywhere, because it all has to be refactored.
  2. Start wherever it is hurting. I’ll refactor what I need to in order to get my specific task done.

I don’t hold with either of these. The first is impracticable except in a few projects staffed entirely with top programmers. The second tends to pick around the edges, treating symptoms and ignoring the root causes, shying away from the worst tangles. – Domain Driven Design, Eric Evans

I can think of many times where developers (myself included) have really just been gold plating under the guise of refactoring, or other times when refactoring activities contributed superficial cosmetic changes while the real mess lies beneath – getting to the root of the problem requires significantly more time and work than we’re often allocated and the cosmetic changes give us a sense of motion without moving. Then there are the occasions where seemingly superficial refactorings lead to an insightful break through.

Of course Evans isn’t suggesting that we stop refactoring altogether, instead he suggests that we think about what we’re refactoring, and that we focus on the parts of our software that provide the most value – in the context of Domain Driven Design this would be our Core Domain.

Author: Adam Kahtava Categories: DDD, Software Tags:

Project Failure is not Personal Failure: Emotional Buy-in to Projects, Languages, and Frameworks is Bad

October 23rd, 2008

I was at the point where I could visualize the project’s code, the team had gelled, and we only had a couple remaining issues. This was after almost a year of over time and personal sacrifices. From our perspective (the developers) everything was great. Then for reasons beyond our control, the project was canceled. I was DEVASTATED! Somewhere over the course of this project I had lost my personal life and began equating my personal success to the project’s success. When the project came to a screeching halt, so did I.

Listening to Yegge, Spolsky, and Atwood really brought up this uncomfortable memory of projects past.

[Yegge] some people … they can’t handle [a failed project]. They’re out on the ledge, you have to talk them down real slow, it’s usually more junior people. 

[Spolsky] I don’t know about junior, but … that they identified with the project, and that is kind of important. … People are going to be … devoted to a project that they identify with.

[Yegge] … identifying with anything so strongly that it starts to give you emotional reaction is really bad. You never know when your language is going to be obsolete or your project is going to get canceled or your favorite framework is going to be replaced. – Steve Yegge, Joel Spolsky, stackoverflow podcast #25

I can certainly relate.

Author: Adam Kahtava Categories: Musings, Personal, Software Tags:

How To Display Your Amazon Reviews and Wish List (on your site) Using Amazon’s Web Services

October 6th, 2008

If you’ve ever landed on Amazon then you’re probably familiar with their reviews and wish lists. Amazon provides access to these items (and many-many more) through their extensive web services – the Amazon web services can be complex and overwhelming when all you want is a review list and a single user specific wish list. For this site I wanted to pull in my reviews and wish list – displaying them alongside my blog. It’s fair to note, that user reviews are available via an RSS feed (but this feed doesn’t include all the details I wanted) and the wish list page still doesn’t provide an RSS feed. So a custom Amazon web service request was in order.

Let me try to make this story short.

If you want to request your reviews and your wish list you need the following:

Once you have a wish list or review, you then need to:

Once you’ve collected all those bits, you need to:

  • Checkout and download the source code for the project and build the assembly or download the pre-compiled assembly.
  • Add the assembly reference to your project (remember, I’m assuming you’re using .NET).
  • Make a call to the application which will generate XML files containing your respective reviews and wish list.

Setting up the call would look something like this:

IAmazonRequest amazonRequest = new AmazonRequest() {
 AssociateTag = "adamkahtavaap-20",
  AWSAccessKeyId = "1MRF________MR2",
  CustomerId = "A2JM0EQJELFL69",
  ListId = "3JU6ASKNUS7B8"

IFileParameters fileParameters = new FileParameters() {
  ProductFileNameAndPath = @"Products.xml",
  ReviewFileNameAndPath = @"Reviews.xml",
  ErrorFileNameAndPath = @"Errors.xml"

IAmazonApplication amazonApplication = new AmazonApplication(amazonRequest, fileParameters);


And Viola!

If you’d like to provide some design guidance, fix a bug, or request a feature, then visit (or join) the project on Google Code.

Alternatively, you might also be interested in the LINQ To Amazon source featured in the book LINQ in Action.

Author: Adam Kahtava Categories: .NET, ASP.NET, Amazon, Open Source, Software, XML Tags:

The Three-step Sequence: Incorrect Assumptions and Experience

September 30th, 2008

the obvious … is never seen until someone expresses it simply. – Kahlil Gibran

The preface of Object Oriented Software Construction literally introduced me to the three-step sequence:

the well-known three-step sequence of reactions that meets the introduction of a new methodological principle:

(1) “it’s trivial”;
(2) “it cannot work”;
(3) “that’s how I did it all along anyway”.

(The order may vary.) – Bertrand Meyer

Author: Adam Kahtava Categories: Book, Musings, Personal, Software, Testing Tags:

Everyone Is Special, I Wish I Was Special

September 13th, 2008

I had x-ray vision as a child – that’s right, I could see through walls and birthday gifts. I was convinced I had super eyesight and my friends thought they had similar enhanced sensory powers – we thought we were super heroes.  In high school I was a wizard (one of a handful of computer enthusiasts).  University, College, and my first job were similar experiences – I felt special because most of my colleagues were fresh graduates void of the lifelong passion for computers.

Through all these experiences I was convinced that I was unique. Then I started becoming part of the bigger conversation. While engaging online I began learning that there were thousands of people like me: weened on computers, interested in good software design, and passionate about what they do.

Imar Spaanjaars’ signature always reminded me of this lesson:

Everyone is unique, except for me.

Yegge’s recent post brought up this thought again:

people like to think they’re unique and special, and that their tastes aren’t necessarily widely shared by others. This is what drives fashion: the need to differentiate yourself from “the crowd”, by identifying with some smaller, cooler crowd. … The reality is that for any given dimension of your personality, there are oodles of people just like you.Business Requirements are Bull**** 

David Heinemeier Hansson reiterates this:

it’s somewhat counter intuitive … for a lot of developers …  it’s counter intuitive for humans in general to think they’re not that special, but when they do think they’re special … they kind of get these assumptions that they need very unique and special tools that will only work for them … We as programmers aren’t really unique or that special. David Heinemeier Hansson, 37signals: “Friday Keynote”

Remember you’re not really special. :)

Author: Adam Kahtava Categories: Musings, Personal, Software Tags:

Noisy Work Environments are Counterproductive, But Compensating With Music Negatively Effects Creativity

September 6th, 2008

Working in a noisy work environment and listening to music is counterproductive for intellectual demanding work. For example: we don’t write exams in busy cafeterias, or write resumes through loud movies, and Libraries are quiet for a reason. Noise; whether it be music or background noise does negatively affect your ability to get things done.

DeMarco and Lister (in Peopleware) present the results of an interesting experiment:

During the 1960s, researchers at Cornell University conducted a series of tests on the effects of working with music. … They put half of each group together in a silent room, and the other half of each group in a different room equipped with earphones and a musical selection.  Participants in both rooms were … given a programming problem …

They discovered that the majority of the people working in the silent room could pick out a pattern in the programming problem and could come to a quick clever creative solution. Whereas the people working with music playing were able to solve the problem, but didn’t make the creative leap.

They go on to explain:

Many of the everyday tasks performed by professional workers are done in the serial processing center of the left brain. Music will not interfere particularly with this work, since it’s in the brain’s holistic right side that digests music. But not all of the work is centered in the left brain. There is that occasional breakthrough that makes you say “Ahah!” and steers you toward an ingenious bypass that may save months or years of work. This creative leap involves right-brain function. If the right brain is busy listening [to music], the opportunity for a creative leap is lost.

In their book they also make the point that open space work environments and cubical farms are not conducive to knowledge work, and that all employees (or at least groups of employees) should have the ability to close their door. Great companies do follow these guidelines, but many of the smaller companies or transitional companies (at least the ones I’ve worked in) tend to air on the dilbertesque side (the noisy cubical farms / open concept).

To compensate for the noise in the work place I’ve resorted to wearing noise canceling earphones without music. These earphones double as a metaphoric door – it indicates to those around me that I’m hard at work and not to be disturbed. Noise canceling earphones let me create my own personal audio walls, but eventually I become the weird guy with the earphones that aren’t plugged into anything guy.

As a lowly developers it’s hard to make the case to management for a quieter work environment (let alone an office with a door), but we can keep our eyes out for companies that share these values, start our own company, or take opportunities that let us work from home. In the meantime thank goodness for ear plugs (err.. I mean earphones).

Author: Adam Kahtava Categories: Creativity, Musings, Personal, Software Tags:

More on Naming Conventions: My Naming Heuristics

August 30th, 2008

Following a hard rule for naming conventions in software development is difficult; it’s always a compromise between how things were named in the past and where things are going in the future. Other dependencies like the size of the project, the number of developers, and the environment you’re developing in play important factors. In short, there’s never a great naming rule, but here’s my general (heuristic) approach to naming.

My heuristic approach to naming conventions:

New Development / Greenfield Work:

  • Follow the conventions of the language, or the standards used within the larger community, and pay attention to the API. For example: If you’re programming in .NET follow the naming conventions outlined in MSDN, in JavaScript look at the DOM API, in CSS look at the definitions.
  • If a formal naming convention exists for the organization and these conventions makes sense (they aren’t too far off the language APIs) then follow them. If it feels like the naming conventions were created in the dark ages by a very-very senior COBOL Developer then start asking questions.

Maintenance / Brownfield Work:

  • Follow the conventions of the existing code if you’re modifying an existing module.
  • If you’re creating new modules then consider following the conventions of the language and API.

This post was inspired by a podcast by Donald Belcham and Kyle Baley on Brownfield Applications.

Author: Adam Kahtava Categories: Programming Languages, Software Tags:

Cross Language Naming Conventions: Avoiding Verbosity In The Presentation Layer

August 29th, 2008

Most languages and technologies used in web applications come with their own unique naming conventions – which is unfortunate, but necessary, because diversity is important. Languages like JavaScript and PHP use camelCase, CSS uses-hyphenated-delimiters, and ASP.NET / Java / and the like adhere to the conventions used in their respective libraries and frameworks. Managing the different naming conventions in a web application can be difficult, but with discipline, embracing each language’s conventions can provide some great benefits.

A common mistake I’ve made in the past, was trying to make all languages adhere to a single convention. As a budding PHP / ASP developer I took the-single-convention-for-all-languages approach. In retrospect, I used this approach because I didn’t completely understand the language I was using, and in order to compensate for this lack of knowledge, I’d try to meld the languages into the mental model I understood best. This was a mistake.

Today, I find that working with the conventions of the language facilitates re-use (experts in the language understand what I’m doing), promotes portability (modules can be used across projects regardless of server-side technologies), encourages global collaboration (open source modules and plug-ins can be easily consumed and contributed to), and helps to a nurture a more maintainable application (developers from other language domains can easily maintain the application with a relatively small learning curve). Like a carpenter working with fine material, I embrace working with the grain of each language. It’s also fair to mention that breaking free from the monocultured (one-size-fits-all) approach to naming conventions provides a broader perspective, and also makes your development skills more universal – it might even open the door to different development domains in the future.

Then there’s the discussion on name length, verbosity, and using meaningful names. Steve McConnell suggests that the optimum name size for a variable or function is between 8 and 20 characters (Chapter 11, Code Complete), but with tools like ReSharper (for renaming / refactoring etc…) I find myself using names well over 30 characters. So names like GetApproveeTotalFromNamedBasket are a common occurrence in my code. However, like most things, verbosity does need balance (everything in moderation right?). In the business layer, descriptive names are a godsend – they jog my memory as I rediscover what the module I wrote last month was supposed to do. But… in the presentation layer languages (like JavaScript, CSS,  ASP.NET, or XHTML) you may want to reconsider using long descriptive names. Since verbose, long running descriptive names in the presentation layer are passed over the network and can degrade performance. Often times these verbose names are combined together – throw in ASP.NET name mangeling, start hooking in verbose CSS definitions, and then start inserting JavaScript events. All this compounds quickly and result in large page payloads filled with elements like the following:

<div id="ctl00_ContentPlaceHolderForAllTheBestImprotantContent
<a onclick="LinkButtonClick_ThankYouForTakingTheTimeToReadThis();" 
 class="LinkFormatingCssClass SelectedLinkFormatingCssClass" 
 ,'')">Mark As Favorite </a> 

Note: That mess of code above would fire a JavaScript event then an ASP.NET event. It’s the result of placing an ASP.NET LinkButton, inside a Repeater, inside a Panel, inside a Masterpage, and adding a JavaScript event along with some CSS. We can see that using long names in the presentation layers results in a mess of text. It’s also fair to mention that the ASP.NET MVC Framework lets developers write cleaner presentation code.
Sure, everyone cites premature optimization as the root of all evil, and we do live in a world of gzip file compression and JavaScript minifiers. But… keeping names short in CSS, ASP.NET, and XHTML isn’t hard as long as you’re mindful of the final goal. Smaller names in the presentation layer will reduce the amount of data transferred over the network which increase the performance of the application.

Joseph Smarr of once said:

Web applications are only slow if you let them get slow – Douglas Crockford, Alex Russell and Joseph Smarr: On the Past, Present and Future of JavaScript [30:00]

My preference (project requirements warranting) is to keep things short and concise in the presentation languages while using longer descriptive names outside the presentation languages. What’s your preference?