Archive

Archive for the ‘Software’ Category

Do Great Developers Cluster Away From Microsoft?

November 22nd, 2008

According to popular developer consciousness:

good programmers tend to cluster in some organizations, and bad programmers tend to cluster in other organizations … (Demarco and Lister 1999). – Steve McConnell

Can we draw the corollary that:

Good programmers tend to cluster away from traditionally closed development ecosystems like Microsoft, and bad programmers tend to cluster toward Microsoft like ecosystems?

Following Robert Glass’s train of thought:

The most important factor in software work is not the tools and techniques used by the programmers, but rather the quality of the programmers themselves. – Robert Glass, Facts and Fallacies of Software Engineering

Could we conclude that:

Good programmers tend to realize that an investment in their personal development is more important than learning the latest tools? Are product / tool based ecosystems like Microsoft’s at direct odds with the core values of a good programmer?

My hunch is that exceptional developers are versatilists. These developers cluster around organizations that embrace knowledge over tools, open technologies, open communities, and these great organizations also embrace vernacular culture. What do you think?

Author: Adam Kahtava Categories: Musings, 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.

My experience was a lesson learned, which resulted in a couple personal changes:

  • No overtime at the expense of personal life or prior commitments.
  • A quest for a more outward facing perspective on projects and the industry in general.
  • A need for remaining emotionally detached from the project – as well as the frameworks, technologies, and the languages that I use.
  • An aversion towards organizations that encourage the type of situation I had gotten into.
  • Skepticism towards company loyalty, brand loyalty, etc…
Author: Adam Kahtava Categories: Musings, Personal, Software Tags:

On Teams: Dysfunction

October 19th, 2008

One of the risks to a project’s success is a dysfunctional team. It’s common for team morale to fluctuate as a project moves through its life cycle – project politics, bureaucracy, challenging overtime demands, etc, can all take their toll on a team. A team under stress can take a couple of diverging roads – from what I’ve experienced a team can rise to the challenge (like a family) and grow stronger, or digress into a winner-takes-all environment (like Survivor).

Teams work best in a trusting environment, and things begin to fall apart when backstabbing occurs – which from my experience results in alliances being formed between members, while a sense of self preservation and distrust creeps around the otherwise neutral team members. Soon the team digresses into a group of individuals operating in silos. I don’t think it’s possible to put a finger on the catalyst for the entire process, but it could boil down to a combination of: an overly cynical team member, a preexisting alliance between team members, lack of leadership on the project, a team member with an unexplainable appetite for control, a dysfunctional working environment, or human nature?…

No individual is a success who hurts the team, and no individual is a failure who helps it. – Software Project Survival Guide 

How can we cope? Bottom line: RESPECT. Treat your team as family, recognize that everyone has different strengths and weaknesses. Don’t participate in backstabbing, be transparent and honest, if you have an issue with a team member then make it a point to discuss your concerns with that member. Anyone participating in backstabbing is hurting the team.

Nobody on the team should feel unappreciated or ignored. This ensures high level of motivation and encourages loyalty toward the team, and the goal of the project.  – Respect, Extreme Programming Values

A project’s success hinges tightly on the team. Being a team player and having great interpersonal skills can be more important than technical skills – most people can rapidly learn new technical skills, but being able to function within a team might be an ingrained personality characteristic.

Author: Adam Kahtava Categories: Musings, Software, Team Work 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);

amazonApplication.Save();

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

Naturally people consider themselves smart, which sometimes translates into knowing everything, and these three reactions are probably a manifestation of thinking you’re overly enlightened. If we put ego aside – along with our natural predisposition for being lazy (trying to avoiding learning new things) – we often change our views altogether.

Looking back at my technological naivety: I was once wrongly convinced that client-side languages would never work and server-side languages / frameworks would dominate (until I really learned JavaScript), I had also mistakenly assumed that I was already doing TDD (until being introduced to the concept of Mocking), and I even thought that HTML table based design was the future (until I really learned CSS). With a little bit of knowledge and some experience I changed my views altogether.

Reflecting on these incorrect assumptions and decisions promotes growth – with every experience we grow. Which of my latest assumptions / reactions will change over time?

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

Transparency: Considerations For Choosing a JavaScript / AJAX Framework

September 20th, 2008

A growing number of development teams are given the opportunity to choose their JavaScript / AJAX Frameworks. This choice is often thrown to the development team because the Architects are more concerned with the bigger picture, and the technical details are over the manager’s head. Letting the development team decide on the JavaScript / AJAX framework produces some great benefits: it gels the team, fosters project buy-in, and creates project excitement.

Now, developers can be pretty skeptical, and getting them to agree has been likened to herding cats, but a couple core considerations / values seem to surface when the decision is being made.

Considerations for choosing a JavaScript / AJAX Framework:

  • Transparency - Who are the framework’s development team and why should we trust them? Do these developers blog? Attend conferences? Are they featured on podcasts / videos? Is there a high or low turnover within the team? What are their passions? Is this just a job, do they like what they’re doing, are they a cog on a wheel? Are they experts in their field?
  • Competency - Based on the information gathered in the consideration above (transparency), how competent do we feel the development team is?
  • Community Support – How well is the framework supported on forums and blogs? If something were to go wrong can we gain access to the framework’s development team? Are there widespread experts using this framework readily available?
  • Reputation – How popular is the framework in the industry? Who uses it? Are there any white papers, success stories, case studies available?

One of the easiest ways for a developer to choose a framework is by looking at the developers that built it (and talking with those that are using it). As developers our day job will be stepping into someone else’s code for the duration of the project, working with a framework created by competent developers makes our jobs easy. Frameworks without transparency don’t allow us to gauge the competency of the developers or the framework.

Transparency is essential for JavaScript / AJAX Framework teams, JavaScript itself is open and transparent (not compiled yet), it follows that JavaScript / AJAX Framework along with their teams should also be transparent. When the decision for choosing a JavaScript / AJAX Framework is placed in the hands of developers the frameworks that don’t meet the above criteria sink to the bottom of the list.

The only way to succeed now is to be completely transparent, everything is exposed, everything you do – Gary Vaynerchuk 

Author: Adam Kahtava Categories: AJAX, ASP.NET AJAX, JavaScript, Software 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
 _PanelForTheBestReviews"
<a onclick="LinkButtonClick_ThankYouForTakingTheTimeToReadThis();" 
 id="ctl00_ContentPlaceHolderForAllTheBestImprotantContent_
 RepeaterForAllMyFavoriteBookReiews_ctl00_
 LinkButtonMarkReviewAsFavorite"
 class="LinkFormatingCssClass SelectedLinkFormatingCssClass" 
 href="javascript:__doPostBack( 
 ctl00$ContentPlaceHolderForAllTheBestImprotantContent$ 
 RepeaterForAllMyFavoriteBookReiews$ctl00$LinkButtonMarkReviewAsFavorite'
 ,'')">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 Plaxo.com 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?