Wednesday, October 10, 2007

Why Developers Need Great Equipment

Introduction

I wrote this as a justification to the managers at my company as to why developers should have better computers. After a while, I figured that it would make a decent blog entry. I have edited this a bit mostly because I was lazy. I left out the list of workstations, specifications and price guides that I submitted. Go to Dell or HP and do your own research. I also left out my list of references. If you read my blog, you already know the authors I read. I probably would not be able to attribute any of these ideas to the correct individuals even if I tried. None of these arguments are new and they have previously all been laid out by authors with far superior linguistic skills than mine. Here it is anyway.

Cost of Development

The cost of development is both directly and indirectly affected by the quality of equipment that developers have. is through developer productivity. Typically, the direct influences are easily measurable while the indirect influences are much less so. That being said, it is probably the indirect influences that have an overall greater affect on the quality of work produced by your developers.

The average developer’s workday consists of a cycle of change-compile-test. This is a cycle that developers can go through many times a day. Every fraction of a second that can be taken off of the cycle anyplace the developer is waiting on the computer is a measurable gain. In most cases at the company I work for, we’re talking about very noticeable lengths of time. I sometimes give up waiting when changing from one document tab to another within the IDE because it just takes so long. This time is just plain lost. It costs money and the oportunity to work on more features. It is very easy to sit and measure just how much time is wasted if you want to get out a stopwatch and keep track.

A less measurable influence is that when people are forced to wait for the computer to finish longer running tasks, they tend to start doing something else: reading a book, surfing the web, answering email. Those activities do not stop immediately when the computer is done compiling or testing. They stop when it makes sense to stop: at the end of a paragraph or chapter, at the end of the web page, when the email is complete. This is extra time not spent on the task of developing your product. Even if the secondary task is work related, the interruption is a break in flow which can take on average fifteen minutes to achieve. A developer not in flow is both less productive and less happy.

Cost of Developers

A less than happy developer is more expensive. Again, this comes in measurable effects and not so measurable. Granted, simply having better equipment is not the only influence in a developer’s happiness, but it is one of the cheaper and more powerful influences that a company has control over.

On the measurable side, if a developer starts to be less happy it can prompt them to ask for more money, if you’re lucky, or leave your company outright. Either way, the cost is much higher than buying good equipment for each developer. A nice $3000 workstation with cost spread out over three years is less expensive than giving that developer even a modest $2000 dollar bump to keep them happy. That $2000 increase amounts to $6000 for those same three years plus a percentage raise each year plus any extra increase when the developer figures out that the money really did not keep them that much happier and they ask for more or quit anyway. And we all know that the cost of losing a developer you don't want to lose and trying to replace them is much more than $3000.

One not so measurable effect is that a developer’s work, through no fault of their own is just not as good. This can affect not only their code, but directly and indirectly the morale of the entire team.

Why should developers’ computers be so much more powerful than other machines?

A developer has many more applications running and documents open than workers in almost every other discipline. At my current place of employment a developer must have open at bare minimum: one IDE instance (code editor, debugger and more), source control, unit test utility, database, web server, and a web browser preferably with its own debugger. On top of that each developer will probably also have a few of each of the following running: local copies of the document processing engine, indexer, scheduler, database utilities, code compliance software, bug tracking software, requirement and design documents and document management software, multiple browsers to test JavaScript and CSS and additional instances of the IDE when necessary. Add to this all the day to day utilities of email, IM, Word, Excel, other windows utilities that all employees need and other tools that I forgot and you get a large list of programs that more often than not require many processing resources to keep running smoothly.

The resources needed to make all of these programs run fast include multiple fast processors to make the simultaneously running, computation intensive tasks faster: compiling, file indexing and generation and code testing. Memory is needed so that a computer does not need to move running software from fast RAM to noticeably not as fast virtual memory. Fast and preferably multiple hard drives are needed for any kind of data access: file generation, compilation, source control check-ins/outs, etc.

Monday, October 8, 2007

Experience and Abstraction

I had one of those light-bulb-over-the-head moments today. I was waiting for my computer to compile the changes I had made to our project so I could test them out so I picked up the book I am currently reading. Yes, it takes that long to compile... on the computer they gave me at work at least. I've opted for a more technical manuscript this time so the book is Pro WCF and the topic I was reading covered the three approaches to setting up and using the new Windows Communication Foundation: attributes, configuration and programability. At one point, the authors were compelled to point out that the list of types was also the order of precedence. Attributes are included in the code and are set first. Any configuration defined in the configuration files is then applied. And last, any changes to the set up made in code happened last. To which I replied, "Duh." And then the light bulb went on.

Before I describe the futuristic fuel that powers said light bulb, there's some more background you need. I recently read an article by Joel Spolsky. The article talks about the different abstraction layers of software these days. When one of those bottom layers blows up, developers are forced to code around it. It helps a lot if the developer doing the work spent a few years working with that lower layer before it was conveniently paved over. That way, they don't need to go looking for the cause, they just know what the problem is and how to fix it.

I always understood this from an intellectual level, but I never really thought I had that much depth in my coding experience. In truth I probably still don't. I've only been doing this programming thing for coming up on seven years now. But I got a taste of what it means to really have some experience. Oh, lets go ahead and put a capital E on that: Experience. I realized that not everyone working with .NET really understands what attributes are. Even those that do probably don't understand how they really work. If they don't know how attributes work, they probably won't know how they connect to configuration values or changes made pragmatically in code. The authors of the book went out of their way to explain this to everyone because they realized not everyone has enough experience to know this.

So what fuels that light bulb? A couple of things really. First, I learned that I have a bit more software development Experience then the average Joe out there. That's nice and comforting even if it is a bit conceited. But it does help to get the job done faster once in a while. Second, I learned another reason why I need to keep my audience in mind all the time when writing. Fine all you regular bloggers and technical writers that already knew that can rub it in my face... Go ahead... Are you done yet? That's too bad. I'm moving on. Maybe I already knew both of those things on some level or another, but just like it makes coding WCF easier when you already know how some of the basics of .NET fit together, I think I'll be able to communicate a bit more effectively after living through this little revelation of mine.

Tuesday, October 2, 2007

Best Practices: Does anyone here want to learn anymore?

I have been having this running argument with a couple of the other developers where I work. A couple of them believe that the best way to use source control is to keep the working code in the trunk. That's not the part that we argue about. Then the first time the code is pushed to a production environment, the code is branched. So far so good... well... sort of. The problem is that there is not enough isolation around the branch. It's OK to only have one production branch, but it should be isolated from the development branch by another level. This is called forward integration by some. Or the branch can exist on its own and bug fixes from the branch move to the trunk. When a new version is ready, a new branch is created and pushed. Either of these approaches would rid us of the following trials and tribulations.

What actually happens is that deployments go something like this. One person resolves all of the conflicts for the past four to six months in order to merge the trunk directly into the production branch. It takes this person somewhere between two and four hours when we're lucky to hopefully accurately resolve all those version conflicts. I certainly hope he remembers all the changes and their far reaching effects that I made six months ago, because I don't. On top of that, no one can check in any changes while this is going on. In my years of developing I have used five different source control systems and two of four different techniques that I am aware of for branching. Not a single one of the utility manuals or forums ever suggested that merging the trunk directly into into the production branch as standard operating procedure was a best practice for using source control.

I try to explain all the subtle reasons why one of the best practices will work better. Why it is better to merge bugs as soon as the fixes are made (smaller pieces of work, merged by the person that made the change while the code is fresh in their mind). How this allows for faster, less error prone code pushes. The reasons why isolating the branches makes sure that people are not getting in each other's way. There are many more reasons why one of the documented techniques will work better in the long run, and all of those reasons are in the source control user manuals. "Don't listen to me talk about source control if you don't trust me. Just read the books and you'll find for yourselves all the good reasons to follow the best practices," says I.

It just seems like no one wants to understand. Even on those rare occasions when a book is cracked or the web consulted. It seems like people just look at the examples without reading about why things work the way they do. Says one of these developers, "I saw this great piece of code on the web today that dynamically hunts through all the configuration files in a directory looking for a particular section. So I implemented it." Sigh... "Great," says I. "What you failed to read is that it probes through many directories looking for one particular file by name, not one section in all of the files. Now we can not have multiple configurations in the same directory because only the configuration section from the first file will ever get read."

Maybe the problem is not that people don't want to understand. Maybe they have actually lost the ability to reason things out:
"Here's all these great reasons, let's change how we do stuff."
"Show me how that works."
"That will take two weeks. Let's just talk about it so I can convince you."
"If you can show me a better way, I'll consider it."
"OK I'll get started on that tomorrow."
"Two weeks? Are you crazy? We don't have time to do that! We don't even know if it will work!"
"Then let's sit down and I'll show you how it would work. It's not that hard to understand. Really."
"You better show me how that works first."

I kid you not. Why are people just not willing to sit down to talk and truly grok a concept? I don't think anyone has lost that much brain power. It cannot be that reading is too difficult. Maybe they just got ground down. I know justifications with as much common sense as the preceding conversation come down from on high all the time. And to be fair, it does seem to be the more senior members of the team that need to interact with the powers that be more often that are afflicted by this apathy. I bet they are getting trained to not care because they are in a bad environment. Then again, it could be that age is setting in. The younger guys on the team right now really seem to be hungry for information. And the young ones that are left go out of their way to know all all those new concepts. Biblically almost. If I wasn't such the optimist I'd think I was being deliberately stonewalled. Wait a moment!?!?

I love learning about technology. Both through conversation and reading. Speaking has the advantage that, if the other person's message isn't clear the first time through, they can rephrase their point. Books just aren't good about rearranging the characters on the page when a new approach is needed. But I love learning new things from all sources. It's especially gratifying to have that "Aha!" moment when true understanding slides into place and I see just how much more productive me and my team could be. Unfortunately, as of late that feeling turns rapidly to frustration when those I need to convince won't listen to reason or read the books.

I suppose there's always that chance that we just don't have time to make those changes I'd like to make right now. But if that's the case. Just say so. I can learn that much easily. I realize that this is a cry for help. Maybe in more ways than one. But I really want to understand what I need to do in order to engage those brains once again. Help me learn how to help them learn.

Monday, October 1, 2007

Hello October, Will You Design My App?

In a painfully ironic... ironically painful? Let's just go with "In one of those twists of fate called life that is both ironic and painful," I find myself coding a feature in our application for the second time. The reason being that the user interface does not match the new user interface which is shortly going to be replaced by the newer user interface. That's not the painful part yet, nor is it the ironic part. The painful part is that while I am working on moving all sorts of HTML around to support the new CSS organization (which actually is an improvement), one of the designers lets slip that the entire feature is going to redesigned in the future, yet again, after the new version that is not even being worked on yet is completed. Ah well, I can only try and tell them to do at least some design up front so many times. The ironic part about all of this is that I just started reading User Interface Design for Programmers.

The reason I bother I suppose is that some day, I imagine myself working at a company where we gather requirements. Where management is smart enough to understand that prototyping an application in HTML or Illustrator or even just using paper allows one to do usability testing a whole lot cheaper than writing all the application code first and putting the product out in front of people. No one ever gets the UI right the first time. Boy does it just not happen that getting it right on the first try thing. Do you really want to pay an expensive developer to write two sets of code, or would it be better to pay an expensive designer to come up with a few refinements to some drawings?

And I've just been talking about usability problems so far. I won't even get into all the logical issues that we've run into due to designers not thinking about what happens when each and every button on the UI is clicked. Sure, there will always be holes in the spec. But, I prefer a spec with a few small holes to a bunch of vapor with just a few main ideas holding it all together.

Will this new project work in the end? Absolutely. We've got a bunch of great developers working on it and a bunch of really smart people supporting it. Will it work as well as it could? Definitely not. That might be a bit harsh. I mean, nothing is perfect after all. Almost nothing is really ever as good as it could be. But I look at all the wasted time. The time wasted rewriting the application time and again because no one did any usability testing with cheap prototypes. All the time wasted fixing logical errors and wrong decisions made because no one though about how the permissions model should behave in a business environment where community features such as tagging and commenting would be so prevalent. My favorite excuse was "not being able to see that far out." All that time that could have been spent completing more and more usable features that would have blown the users away. And I get frustrated that those of us that believe we as a company can do better don't seem to be able to push through new ideas, and it's not for lack of trying.

Another lesson that I recently learned however, is that there is always a way to accomplish your goals. Don't let my little rant get you down too much. If at first you don't fall off your horse, learn how how to pick up that bridge. Or something.

Monday, September 24, 2007

Blogger Credibility: No Easy Solution

A while back I read a post by Joel Spolsky entitled Bribing Bloggers. The focus of the post seems to be deciding whether or not giving away free products to people to do reviews on them is ethical or not. Joel was approached by a large software vendor with an offer of a free laptop loaded with one of their latest products in the hopes that he would blog about it. The terms of this gift were that it was up to the recipient as to whether or not they even wrote about the machine/software product and what to do with the machine afterwards with suggestions being: keep it, return it or give it away. Joel is of the opinion that "... this is ethically indistinguishable from bribery. Even if no quid-pro-quo is formally required, the gift creates a social obligation of reciprocity."

I'd have to disagree, especially if there is no quid-pro-quo required. I don't know of too many companies that go around handing out money to government officials without expecting something in return. Sure, they say they don't. "It's just a campaign contribution." But you don't see companies contributing to officials that don't have a history of voting in the interests of that company. There definitely is some scratching of backs expected there.

In situations like this, I don't think there is anything wrong with giving away products. I don't base the credibility of any blogger whose work I read on how they acquired the item to be reviewed. Did they write the software themselves? Did Evil Co. give it to them? Or did they go out and spend $2,999.95 of their own money on Benevolent Ltd.'s latest whatsamajigger. There's always an angle. The trick as a reader is knowing what the angle is and how it affects the viewpoint of the blogger. If you can't live with what you learn, find someone else to read.

So what have we learned? The credibility of a blogger might start with how they behave in various situations. But it ends with each reader deciding for themselves how far to trust each blogger on different topics in different situations. Let me say that again. It is ever so much more importanter that each reader decide how credible each blogger is. There could be hundreds of reasons why they write the way they do. If a blogger thinks that means they can not accept free products from companies with vested interests in those products, so be it, but that is no more important than knowing that ease of use is more important than versatility to the blogger you're reading.

Example 1) Joel seems to like Benevolent Ltd.'s products because they are incredibly usable. Not bad criteria when looking for items to purchase. Personally though I always find myself thinking "Benevolent Ltd. hasn't made a(n) [insert product here] that has accomplished all the tasks I would ask of that [insert product here] since the mid-eighties. But I can buy another company's [insert... blah blah blah] that is more-or-less equivalent. Maybe it is not quite as easy to use or it's not as pretty. So what. The color might not be the exact shade of white that I like and it may take an extra step to accomplish the task I want, but it does do everything I want and I can even change the batteries. All for a better price point. Who the heck would like Benevolent stuff? Must be zealotry." I do realize this puts me in a severe minority most of the time and my opinions differ with this particular blogger. But I already know how far to trust each blogger on various topics because I've read so much of what they have to say and figured out how far to trust them.

Example 2) This is a more hypothetical situation. A blogger may only post positive reviews of products. Does that necessarily mean that blogger is a corporate shill? Or did that blogger choose to write only about products they want to endorse and skip the bad ones. Maybe they were trying to create a "What's Hot" sort of feeling and save their readers from the "What's Not" negativosity. Again, knowing how the blogger's values compare to your own and knowing the blogger's track record is what's important.

I suppose I am writing a response to this because Joel's piece came off a bit snooty and condescending to me. It is always possible that I don't have the same view as Joel because no one reads my blog and I have never been offered a free product to gab about, nor have I been accused of selling out because I blogged about a piece of hardware that I just really liked. Fair enough. A quote from Joel, "Effectively [the company has] bought publicity and goodwill. And even though the blogger has fully disclosed what happened, their message is corrupting the medium." Corrupting the medium? The medium of blogging is already as far gone as the Internet in general. Can it really be corrupted anymore? Some broad sweeping marketing campaign by Evil-Benevolent, Co., Ltd. is not going to change my opinion of any blogger, good or bad. Only that blogger's reaction to said promotion will change my opinion of the blogger. Didn't we have this credibility problem before vendors started giving away freebies to bloggers? Can a blogger not be trusted to write an honest review just because the topic item was a gift? Are bloggers just not able to tell the truth and not suck up if they accept a gift? And most importantly, can readers not be trusted to pick out the intelligent, socially responsible bloggers from the corrupt?

And in the end, the company sort of got what they wanted anyway. They may not have gotten a favorable review, but Joel did mention their name and products. And even though I disagree on this topic, Joel still seems like a pretty smart individual, I know another topic on which our opinions differ and I continue reading his blog.

Tuesday, September 18, 2007

Organic Software Growth: Watch Out For Cancers

One of the concepts that the company I currently work for touts from time to time is that their code grew organically. I'm not exactly sure what the president of the company understands the meaning of the word "organic" to be when used in this context. There are times I think that the word is simply thrown around as a buzzword because a bunch of really smart developers see the potential in it to help solve some of the large design and architectural problems that developers face on a daily basis.

And it does seem that organic software growth can be a great thing. If by organic growth you mean that when you respond to the demands of your customers you are able to increase the functionality of your software by growing new features into the the existing structure of the application in a way that is consistent and usable. I imagine this like those pesky spider plants all over the office. When they grow, you know what to expect. You get more fresh air and they are more pleasing to the eye simply because they got a little bigger and another leaf sprouted or whatever it is that individual leaves do. And with a little bit of daily tending, they really aren't all that pesky.

What you don't get is an ear of corn on your spider plant all of a sudden. This might not be a bad thing at first. You will certainly get your five minutes of fame for discovering or creating this new organism. People will be able to have a couple pieces of fresh corn at the office every once in a while. However, people will eventually realize that the two or three ears of corn they get from your new spider-corn plant really isn't worth all the trouble of having to re-balance the hanging pot every week so the water doesn't run out. Oh, they also have to make sure the pot is in a place where the corn ears get a lot of light but the spider part doesn't get so much light that it shrivels up. After the week or so it takes to find these problems, your customers will go get their spider plants from WalMart and buy however much corn they want from la fruiteria down the street whenever they want.

If you don't think about the features you add to your applications they won't fit in. If there's some off shoot piece of functionality that doesn't make sense with the rest of the application, not only will no one use it, but it gets in the way of the features they do like. At the very least, that new menu item for the new feature is going to mess up the muscle memory the users have built up to pick the good feature out of the menu. Maybe you introduced some new bugs in the good features while implementing the bad ones. Maybe the usage of the popular feature completely changed because of extra steps needed to distinguish it or its process from the useless feature. I'd be willing to bet that your application is also a lot more difficult to maintain than if the new feature just used all of the conventions and frameworks you already had in place.

And that's what I see happening around here as deadlines draw near. We are not taking the time to design usable, powerful and simple features that give customers real solutions to their problems and integrate wonderfully with the rest of the application. We seem to be taking their ideas and implementing them exactly as the are asked for instead of maintaining the consistency and integrity of the application. Hell, how many times does a customer ask for a change that really solves their problem anyway? This is not organic growth; this is Franken-cancer. It is not going to take long before one customer's request or sales-person's demand interferes directly with another. This causes the application to have many more preferences and settings that need to be set just to use the darned thing. We're going to spend more and more time cleaning the cruft and bugs out. And, no one will use any of those half designed features anyway because even though they asked to be able to pick corn off their spider plants, what they really needed were catered lunches.

Monday, September 10, 2007

The Mythical Man-Month: Why I Like Specs

So I've been reading a lot about project management and better ways to architect applications lately; design, process, code organization and interaction, and the like. One of the classic books out there that every one should read is "The Mythical Man-Month".

I'm sure we're all familiar with the little gem "nine women cannot have a baby in one month." But TM3 goes on to explain why creating a software application is more like creating a baby and less like building a bridge, at least as far as the additional woman-power goes. People are not interchangeable; visions are inconsistent, misunderstood, or incompatible; ramp up time must be accounted for; etc.


The book explains some ways that software design and implementation can be scaled up to teams of a thousand if need be without conflict of vision getting in the way. There are many processes and responsibilities that each person on a team has that allows them to work together without that conflict becoming a problem. Of particular immediate interest to me is the need for written specifications. "Why would you write about the importance of written specs? Everyone knows you need them, don't they?" Right.


"The manual is the external specification of the product. It describes and prescribes every detail of what the user sees... The manual must not only describe everything the user does see, including all interfaces; it must also refrain from describing what the user does not see."

All I can say from personal experience is that not following this wisdom causes problems. It is hard enough for one individual to have a vision of what your product should be. If that vision is not documented, it can not be implemented truly. If the visionary attempts to implement all of the vision on paper, as mock-ups or in code, there will never be enough time to complete the implementation. Divide the responsibilities and communicate.

Addendum 9/13/2007:

After reading a bit more of the book I have found that there are some chapters that are truly outdated. I would still recommend reading the book however. It is fairly easy to identify the sections that are aging; they usually contain a reference to OS 360 or some other decades old system. Still, it is a useful exercise to contemplate those sections to see how they apply to the present day.

Most of the concepts presented are still relevant. The examples are not necessarily as meaningful as they once were and the solutions presented are usually either outdated or never came into wide acceptance in the first place, so it is interesting to draw parallels to the solutions that exist today or to dream up a solution if one was never found.

There are a couple of chapters that just don't seem relevant to the general programming population of today though. The chapter on size limitation seems particularly quaint. While there may be some situations where developers of embedded devices still need to constrain the overall size of their software, I doubt any OS, web or intranet developer has been seriously constrained by byte limitations anytime recently. Not that we don't try to write code as concisely as possible, but legibility and maintainability are usually the primary goals.

Still a great book to read.