<CharlieDigital /> Programming, Politics, and uhh…pineapples

4Apr/121

Reverse Technical Interviews

Posted by Charles Chen

One of the things I've had to do quite often in the last few years is conduct technical interviews.

It's always a challenge as of course, if you want to make sure that a resource is technically competent in specific tasks or role for which you are resourcing, that's pretty easy; just ask questions oriented around those tasks that they will be responsible for.  But what if you want to assess an individual's broader technical competency of and experience with a platform?

As a technically oriented guy myself, it's very easy to inject my bias and my core knowledge into the equation and I think that typically makes for a bad interview.  There are always many things that I know well and many things that I don't know well for any given platform.  So how can I go about measuring a candidate's competency without injecting my own knowledge and experience bias?

As an addendum, for technical interviews, it's sometimes difficult to come up with a good set of questions that are "fair".   I don't think it's fair to ask obscure questions for which few folks would know off the top of their head, but would have no problem solving with Google and StackExchange, for example.  I also don't like to ask brain-bender type questions as I don't find the outcome of those questions to be generally useful in evaluating technical expertise.

One approach is to ask open-ended design type questions.  "Given this platform, how would you design a solution to meet requirement X?" "What are the benefits of approach U versus approach V for modeling this data?"  These are okay, but I find that I often get clouded by situational bias.  What I mean by that is that I tend to think of problems I've solved in the recent past or problems that I'm working on now.  But I know that many of these design issues took me days if not weeks of research, prototyping, experimenting, and discussion to settle upon -- it simply doesn't seem fair to ask a candidate to produce a response on the spot.  It's worth something, I guess, if they are able to come up with the same solution (or a better one!), but if they can't, does one hold that against them?

So in thinking about these issues, I think one good approach is to go with a reverse technical interview.  What this means is that I ask the candidate to produce a list of technical and design questions for me for the interview.  My thought is that this allows me to turn the bias that I would otherwise have into a tool because they will have the same biases.  They will tend to ask questions around what they've worked on, what hard problems they've solved, and what experience they have.  This seems like a much more dynamic approach and would seem to provide more valuable insight...I think.  It's one thing to list a skill or a technology on your resume, but it's another thing to be able to ask deep, challenging, technical questions around it.

As a bonus, being able to come up with and ask good questions is itself a valuable skill.

29Nov/11Off

Home Office 2011 Edition

Posted by Charles Chen

Finally got around the cleaning up my office (after 4 years...) .  Love the way it turned out and much more work space with much less clutter.

Shot of the office from the foyer

Alternate view.

Ergotron Lx Dual Stacking arms to free up desk space.

For reference, this is what it looked like previously.

Filed under: Awesome, DevLife No Comments
25Oct/11Off

Isaacson on Jobs on Craftsmanship

Posted by Charles Chen

From an NPR interview with Walter Isaacson, Jobs' biographer:

On Jobs' father, who rebuilt cars, and held design and craftsmanship in high regard:

"He would show Steve the curve of the designs and the interiors and the shapes ... and even have pictures of the cars he liked the most in the garage. He put a little workbench in the garage, and he said, 'Steve, this is now your workbench.'

"One of the most important things he taught Steve was [that] it's important to be a great craftsman, even for the parts unseen. When they were building a fence, he said, 'You have to make the back of the fence that people won't see look just as beautiful as the front, just like a great carpenter would make the back of a chest of drawers ... Even though others won't see it, you will know it's there, and that will make you more proud of your design.'"

I can't begin to compare myself to Jobs, but I think this is a value that's important to me, personally, from a software development perspective.  There is an aesthetic and a beauty to well written code or framework not to mention the pride of the author in crafting a clear, concise, and elegant design -- even in the "parts unseen" by the end user.

I once got into a heated debate about code quality with a CEO who was, at the time, bent on fixing nail pops and seams on the walls of his recently built and painted house.  I asked why he didn't see the same need to put an effort into addressing analogous issues in our code that disturbed the overall quality and aesthetics of the codebase, which seemed to me even more important than a few nail pops.  "That's different" is the only response that I got, but to me, it's the same.  There's a personal pride in building a product with exemplary craftsmanship.  There's a team's pride to being able to walk into a code review with a customer and know that they will be wowed.  There's a developer's own pride in writing software that takes design and usability of the framework into account.

This gets lost in the age of outsourcing and rent-a-coders, but great software is still -- and likely will always be -- a craft that requires skilled craftsmans to build (of course, great software requires more than that like vision and an understanding of the problem domain as well).

Filed under: DevLife 1 Comment
17Feb/11Off

Responsibility in Consultancy

Posted by Charles Chen

As a consultant, I feel strongly about giving sound technical advice to my clients, even if such advice means saying "no" to a client or possibly turning back a larger project for a more pragmatic one. It's about doing the right thing and offering sound technical advice to the best of my knowledge -- not just money, projects, and utilization.

The one personal example that really sticks out for me is the case where Microsoft sold a deal to a hedge fund to build a bulk import system using BizTalk that would have cost them triple the price (once licensing and hardware was factored in) of doing it using SQL Server DTS, which was easier to program, maintain, and more robust in every way (not to mention this company already had SQL Server skillsets in-house).  Luckily, we were able to convince the client that DTS was purposefully designed for carrying out bulk import and transform of data before they committed the cash to BizTalk.

Recently, a friend of mine showed me a project that the Big Consulting Company he works for was delivering to their client, a public library. It looked really good for a public library website...until he dropped the bomb that it was built using Silverlight (and to top it off, he was really proud, too -- as if I was supposed to find it impressive).  I don't think I've ever done a bigger facepalm in my life.

As I've stated in the past, I have a strong disdain for the misuse of Silverlight.  There are certainly scenarios where it should be used for building web sites:

  1. Streaming media
  2. Scalable 2D vector graphics and animation
  3. 3D graphics and animation
  4. Interactive games

And that's it!  Beyond that, if a company wants to use it in their intranet site, it doesn't concern me as much because the environment is more homogeneous and controlled in terms of having the platform to run the Silverlight applications; it's their headache going forward.  Besides, if it's a private, multi-national company, then by all means; if they wish to waste their capital and resources, that's their choice.

However, it is a damn crime to recommend Silverlight to any client building basic web applications that are Internet facing, especially a public library financed by taxpayers.  I mean, people should be fired and embarrassed for offering such terrible advice.  To begin with, few non-Windows devices natively support Silverlight (and even folks on older Windows OSes can't natively run Silverlight apps).  iPad?  iPhones?  Android phones?  Linux based netbooks?  As sales of traditional laptops and desktops decline, it's important to factor in the presence of these newer platforms when designing a publicly facing Internet site.  I would think that this would be even more important for a public library.

Now, if the site were media focused -- like a YouTube -- perhaps it could be forgiven; after all, HTML5 is still a moving target and supported only by newer browser versions.  But this is a public library website that was listing books...It's as bad as websites that still use Java (yes, Java without the "Script") for image galleries or raindrop effects.  It's as bad as websites using Flash for menus and menu rollover animations.

I would be embarrassed to be a part of the company or the team that sold and implemented this deal.  A fucking crime to the taxpayers of the township with me as the perpetrator; no better than stealing money from your neighbors.  I couldn't live with myself for being so evil.

Now, he told me that the client insisted on Silverlight and that it was they who wanted it done in Silverlight.  To me, that makes no difference.  As a consultant, it's my duty to provide sound technical guidance to the best of my knowledge and ability.  If there is a more compatible, cheaper, easier to maintain solution built on a platform with greater longevity that solves the same problem, I will recommend taking that route, even if it takes me out of the running.  It's our job as consultants to consult and to offer sound technical advice.

For you see, the client may not know or care for the difference between Silverlight and HTML5 or jQuery based UIs.  The client may be under the impression that a given UI or bit of functionality is only possible because of Silverlight if that's what they've been sold and demo'd.  The client may not understand the alternative solutions as certainly, for a non-expert, the difference between two types of wood -- for example -- aren't perceivable.  The client may be enamored with one buzzword or technology, but it is our duty and responsibility as consultants (and decent human beings) to tell the truth because I'd like to believe that when I ask a contractor to come to my house for a quote or get a diagnosis from an auto mechanic, he'd do the same for me and give me the low-down to the best of his or her ability and knowledge.

In the end, I was so peeved by what my friend had shown me, I took 30 minutes and rebuilt the same exact functionality that they had implemented in Silverlight using nothing but jQuery and CSS with only 20 lines of JavaScript and 5 lines of CSS after being challenged to do so.

I'm still peeved by this as it's a critical misunderstanding of the Internet ecosystem and managing device compatibility as well as a critical misunderstanding of technology and their suitability for a purpose.  Not to mention that it's a terrible choice for audience accessibility, long term costs, and maintenance.  I really don't want to be upset by the fact that my friend or his team could have purposefully offered bad advice for greater financial returns as that would be a true embarrassment and I only hope that all sides in this come to their senses and ditch Silverlight.

In the end, for me, consultancy is about people and treating customers with respect by offering the best technical advice to one's knowledge.  Even if it costs me my job, I've always believed that I am accountable to my clients and I'm responsible for giving sound technical advice.

Filed under: DevLife, Rants 2 Comments
5Dec/10Off

Why The Office Is The Worst Place To Work

Posted by Charles Chen

Caught this editorial on CNN this weekend:

Companies spend billions on rent, offices, and office equipment so their employees will have a great place to work.  However, when you ask people where they go when they really need to get something done, you'll rarely hear them say it's the office.

If you ask, you'll usually get one of three kinds of responses: A place, a moving object, or a time.

They'll say their house, their back porch, an extra bedroom they've converted into a home office, a library, the coffee shop down the street, the basement. Or they'll say their car, or a train, or a plane -- basically, during their commute. Or they'll say really early in the morning, really late at night, or on the weekend. In other words, when no one else is around to bother them.

Indeed, I think it's important to realize that different individuals have different productivity models.  By that I mean that certain people are "morning people" and their brains are most active and creative in the morning.  Others are "night people" where there brains are most wired and effective in the evenings.  Some people feel more comfortable with natural lighting during the day time.  Some prefer a bright working space while others prefer a dim one.

It seems counterproductive to force everyone into one model of the work environment when the preferences that maximize the efficiency of each individual can be vastly different.

And then there's the bigger issue of interruptions:

I don't blame people for not wanting to be at the office. I blame the office. The modern office has become an interruption factory. You can't get work done at work anymore.

People -- especially creative people -- need long stretches of uninterrupted time to get things done. Fifteen minutes isn't enough. Thirty minutes isn't enough. Even an hour isn't enough.

I believe sleep and work have a lot in common. I don't mean that you can sleep at work or you can work in your sleep. I mean sleep and work are phase-based activities. You don't just go to sleep or go to work -- you go towards sleep and towards work.

You aren't sleeping when your head hits the pillow. You start the sleep process. You have to go through phases to get to the really beneficial sleep. And if you're interrupted before you get there, you have to start over.

The same is true for work. You don't just sit down at your desk and begin working effectively. You have to get into a groove. You go towards good work. It takes some time to settle in, clear your head, and focus on what you need to do.

A very good analogy and I wholeheartedly agree.  At the same time, to ensure that this model works, teams need the right tools (Webex or equivalent, chat clients, VOIP, etc.) and the right people to make it work.  To some extent, it takes a good amount of trust that each member of the team understands their tasks and roles to get their jobs done without having to have a manager or supervisor constantly buggering for a status or having meetings to figure out the status of the tasks.

At least for myself, I find it incredibly difficult to work any any problem of moderate complexity without sitting down and having a solid bloc of a few hours to work on the problem.  There's nothing worse than having to do a mental context switch when one is working on a difficult problem.  Well, it's only worse when that context switch is for a meeting that's inconsequential to the tasks at hand

Filed under: DevLife 1 Comment
18Oct/10Off

jQuery Conference 2010

Posted by Charles Chen

I didn't go, but John Peterson did.

Check out his feedback from the conference.

<3 jQuery

Filed under: DevLife No Comments
16Sep/10Off

Presenting at the Tri-State Code Camp 2010.2!

Posted by Charles Chen

The session is titled "Object Oriented Development and Practices in SharePoint":

Building maintainable solutions on the SharePoint platform can be a challenge (and that might be putting it mildly). Code interspersed with CAML strings, rampant code duplication, hundred (thousand?) line methods, inconsistent code quality, and so on.  How can a dev/technical lead address these problems that arise when a team of individuals with diverse experience and skill levels embarks on designing and building a solution on the SharePoint platform?

This session introduces a series of practices, tools, libraries, and techniques to support an object-oriented approach to building sustainable and maintainable solutions on the SharePoint platform.  It offers an innovative approach to solving complex solution and development problems through embracing simplicity and leveraging the capabilities of the .NET Framework to build a framework for highly object-oriented, patterns based solutions.

Technologies: SharePoint 2007, Visual Studio 2010, C#, .NET, XSLT (Saxon)

Audience: SharePoint developers, SharePoint technical architects, SharePoint technical leads, .NET developers

Level: Intermediate/Advanced.  Audiences with experience in design patterns, reflection, delegates, anonymous functions, and XSLT will be able to follow along and extract the most value from this session.

To expand on that, the plan is to cover some of the lessons I've learned from being deep in the code on a handful of large SharePoint projects.  These lessons I've encapsulated in a framework of sorts which was designed to help:

  1. Accelerate development of solutions for SharePoint
  2. Increase developer productivity while still maintaining high levels of code consistency
  3. Increase adherence to the DRY (Don't Repeat Yourself) principle by leveraging patterns and object-oriented code
  4. Decrease the entry barrier for ASP.NET developers transitioning to SharePoint

It won't be for everyone; however, for any team that's deep into the SharePoint APIs and building custom solutions (web parts, event receivers, web pages, layout pages, and so on), I promise this will be a great session to attend.  My hope is that attendees will be able to walk away with some ideas on how to make their teams more productive and to help teams write better code.

The event will take place on Saturday, October 9th at the DeVry campus in Fort Washington, PA (great campus, good presenters, free lunch!).  Details here: http://codecamp.phillydotnet.org/2010-2/default.aspx

I'd be lying if I said I wasn't a bit anxious over the whole thing.

I plan on putting together a monster post before the event with the outline, details, and materials of the stuff I plan to cover.  See you there (and wish me luck)!

15Sep/10Off

A New Euphemism for Bad Code

Posted by Charles Chen

Ant Death Spiral (via Cynical-C).

This is one of my favorite things about ants -- the ant death spiral. Actually, it's a circular mill, first described in army ants by Schneirla (1944). A circle of army ants, each one following the ant in front, becomes locked into a circular mill. They will continue to circle each other until they all die. How crazy is that?

This is the perfect description for bad code and bad programmers (and poorly run companies!).  Each development cycle that builds on bad code just compounds the problem until you're locked into a code death spiral of "we don't have time to clean it up" or "it'll take too much effort to refactor it" or "this is just how we do it here".  Instead, each member of the team begrudgingly (or even worse, dutifully and mindlessly marching like ants) continues to use the bad code, copy and paste the bad code, and build on top of the bad code thereby creating more bad code and more dependencies on the bad code that become inexorably difficult to refactor and extract.

WHARRGARRBL!!!11!

In programming and software development, Paul Graham captures this concept perfectly in his essay on the failure of Yahoo! and why they fell to Microsoft and Google:

In technology, once you have bad programmers, you're doomed. I can't think of an instance where a company has sunk into technical mediocrity and recovered. Good programmers want to work with other good programmers. So once the quality of programmers at your company starts to drop, you enter a death spiral from which there is no recovery.

But not all hope is lost,

Sometimes they escape, though. Beebe (1921) described a circular mill he witnessed in Guyana. It measured 1200 feet in circumference and had a 2.5 hour circuit time per ant. The mill persisted for two days, "with ever increasing numbers of dead bodies littering the route as exhaustion took its toll, but eventually a few workers straggled from the trail thus breaking the cycle, and the raid marched off into the forest."

Avoid the ant death spiral!  As Fred Brooks suggests in The Mythical Man Month,

Programming managers have long recognized wide productivity variations between good programmers and poor ones.  But the actual measured magnitudes have astounded all of us.  In one set of their studies, Sackman, Erickson, and Grant were measuring performances of a group of experienced programmers.  Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space requirements!  In short the $20,000/year programmer may well be 10 times as productive as the $10,000/year one.  The converse may be true, too.  The data showed no correlation whatsoever between experience and performance. (I doubt if that is universally true.)

Take the effort to find, work with, hire, or -- better yet -- count yourself among those programmers that can help teams avoid walking into the ant death spiral in the first place.  Address lingering issues and inefficiencies as soon as possible; fixing bad code early can yield huge gains in agility and flexibility down the line.  Never be afraid to break the cycle and call out bad code and poor practices.

Filed under: DevLife 2 Comments
13Aug/10Off

Failing (Gracefully)

Posted by Charles Chen

(Alternate title: Failing Productively)

I posted some snippets from a recent interview with Fred Brooks in the August issue of Wired (by the way, I'm working through his latest compilation of essays, The Design of Design).

I'll repost the relevant bits here:

KK: You say that the Job Control Language you developed for the IBM 360 OS was "the worst computer programming language ever devised by anybody, anywhere." Have you always been so frank with yourself?

FB: You can learn more from failure than success.  In failure you're forced to find out what part did not work.  But in success you can believe everything you did was great, when in fact some parts may not have worked at all. Failure forces you to face reality.

I think this is an important lesson.  I've written about this topic before in a post about, of all things, The World of Warcraft.

From the Wired article:

Where traditional learning is based on the execution of carefully graded challenges, accidental learning relies on failure. Virtual environments are safe platforms for trial and error. The chance of failure is high, but the cost is low and the lessons learned are immediate.

To expand on this, in software, I think it's important to have lots of little failures.  This is the only way to discover and find solutions that work and solutions that don't work (hopefully on the path to a solution that does work!).  In my book, failure is good; it's a necessary part of the learning process (if I'm not failing, I'm probably not doing anything interesting or challenging).  I expect to fail and I expect other developers that I work with to fail.  My estimations even account for failure.  The important thing, however, is to actually examine your failures and to understand why you've failed.  More than that, it's important to understand how to fail.  The key is to fail early and fail in small, isolated scenarios and be able to extract from that some concept of what will work and what will not; we call this iterating or prototyping or iterating with prototypes.  Then, on a macro scale, examine one's work once a project is done and identify what one did wrong, what was painful, what could have been done better and actually make the effort to improve.

Brooks also expands on this in The Design of Design.  In chapter 8, "Rationalism versus Empiricism in Design", he writes:

Can I, by sufficient thought alone, design a complex object correctly?  This question, particularized to design, represents a crux between two long-established philosophical systems.  Rationalism and empiricism.  Rationalists believe I can; empiricists believe I cannot.

The empiricist believes that man is inherently flawed, and subject repeatedly to temptation and error.  Anything he makes will be flawed.  The design methodology task, therefore, is to learn how to determine the flaws by experiment, so that one can iterate on the design.

Brooks boldly states: "I am a dyed-in-the-wool empiricist."  I'm in Brooks' camp; I'd definitely consider myself an empiricist.  It's evident in my sandbox directory where hundreds of little experiments live that I use to rapidly iterate an idea (and isolate the failures).  If you're an empiricist, then -- as Brooks implies -- iterative models of design and development come naturally.  I find it more productive to go through a series of quick, small prototype and experiments to identify the failures than to end up discovering one big failure (or lots of little small failures) late in a project!  As much as we'd like software engineering to be a purely mechanical process (say an assembly line in an automotive plant), I don't think that this can ever be the case.

So then it follows, if designers and developers work best with an empiricist view of the world, then why do we continue to design, plan, budget, and schedule projects using a waterfall approach?  Why do we continue to use a model that does not allow for failure in design or implementation, yet cannot actually prevent failure?  "Sin."  Brooks writes in chapter 4 "Requirements, Sin, and Contracts":

The one-word answer is sin: pride, greed, and sloth... Because humans are fallen, we cannot trust each other's motivations.  Because humans are fallen, we cannot communicate perfectly.

For these reasons, "Get it in writing."  We need written agreements for clarity and communication; we need enforceable contracts for protection from misdeeds by others and temptations for ourselves.  We need detailed enforceable contracts even more when the players are multi-person organizations, not just individuals.  Organizations often behave worse than any member would.

So it seems that the necessity for contracts best explains the persistence of the Waterfall Model for designing and building complex systems.

I find that quite disappointing and pessimistic and yet, full of truth.

On a recent project, we failed to launch the project entirely even after months of designing, design reviews, sign-offs, and discussions.  I had already started writing some framework level code, fully anticipating the project starting within a matter of weeks after the design had been scrutinized ad nauseum and "finalized".  The client insisted on a rigid waterfall approach and wanted to see the full solution in design documents upfront.  As absurd as this sounds, the client had already spent more for design artifacts (documents and UML diagrams), by this point, than they had budgeted for delivery (development, testing, validation, and deployment).  It was an impossible objective to start with, but we obliged as an organization despite my own protests internally.  Tedious, micro-level designs were constructed and submitted, but to what end?  The project was scheduled to go live this April.  It is now August and after a change of vendors, it isn't even close to getting off the ground.  Instead of many micro-failures along the path to success, this client's fear of failures (embodied by their goal of designing out all of the risk) has lead them down to the path of one big failure.

So the question then is: how can we overcome this?  How do you negotiate and write a contract to build a solution iteratively?  How can you effectively build that relationship of trust to break down the sins and the communication barriers?  Brooks touches upon various models and why they work, but doesn't necessarily offer much insight and guidance in how to overcome the "sins" while still working within an enforceable contract.  This, I think, is an important lesson to learn not just for individuals, but for organizations.  A certain level of failure must be acceptable and in fact, encouraged; this is essentially what iterative design and development means: iterate quickly and find what does and doesn't work.  Make many small mistakes early instead of finding big mistakes in your design or assumptions later.

Footnote: I'm still working through the book and, so far, it has been a great read.

12Aug/10Off

Laptop Buying – For Developers

Posted by Charles Chen

About a year ago, I caught on to Dell's refurbished laptops over at Dell Outlet and since then I've purchased a total of three four laptops from there and each one has worked out great.

My first purchase was a Dell Latitude E6400 which I used as a primary development machine as I was traveling heavily.  At the time, as configured, the laptop that I acquired was over $500 cheaper than a brand new laptop from their business channel with the addition of a 15% off coupon (which they throw out there all the time; you can check their Twitter stream for updates).  That's a huge savings.  I used it to run Visual Studio 2008 and VMWare 6.5.  It was plenty good, but with the rollout of Visual Studio 2010 and SharePoint 2010, I definitely noticed a HUGE decrease in performance.  It was excruciating.

I was torn between upgrading the E6400, which I had for less than a year, by adding another 4GB of RAM and an SSD or getting a new laptop, but it just so happened that my mom needed a laptop for some contract work that she picked up.  So I turned to Dell Outlet again and picked up a Core-i7 packing Latitude E6410, purchased an extra 4GB of RAM (total of 8GB), a Muskin Calisto Deluxe from Newegg (a Sandforce based SSD), and a second drive tray from NewModeUS for somewhere around $1600 (note that this includes almost $80 from shipping and taxes from Newegg and NewModeUS) after using a 15% off coupon for the laptop.  It's a great value considering configuring the same laptop from the business channel would have cost around $400-500 more.

The E6410, with the 8GB and the Calisto SSD, is able to lay down some serious computing power.  It handles my SharePoint 2010 Enterprise VM without a sweat.  Visual Studio 2010 is far more usable now as well.  As I almost never use my DVD drive, I swapped it out for a Western Digital Scropio Black (at $80 for 7200RPM, 320GB, it can't be beat in terms of price/performance) and store all of my large files and VM images on the second drive.

I've also purchased an E4310 for my wife this year.  My experience with the E-class Latitudes from Dell Outlet has been so overwhelmingly positive, that it was a no-brainer.  It's a great little machine for the road warrior developer and now that I've felt the heft and the size, I'd seriously consider it myself (although it doesn't have an option for a Core i7 CPU -- i3 and i5 only) as NewModeUS also has a drive tray for the E4310.  She tends to use laptops for far longer than I do :-D Her last one lasted her about 5 years now so I hope that this one can last at least as long.

Refurbished? I'm not really sure what this means.  It's pretty broad I guess, but considering that I got my E6410 in July and the laptop itself was released only in April or May, I figured that it had to be in pretty good shape.  How much wear could a laptop accumulate in two months?  My guess is that the refurbished laptops fall into one of a few scenarios (just my guess):

  1. Ordered too many -- perhaps a hiring freeze or some employees were let go before IT was notified.
  2. Not needed anymore -- perhaps a company went bankrupt or went out of business?
  3. Some malfunctioning component -- maybe the power supply didn't work or the video card was wonky and the whole chassis was returned.
  4. Misconfigured -- IT department receives shipment and finds that a batch of the laptops were misconfigured with the wrong CPU or missing other features.

I don't know the answer and I don't know why my laptop is "refurbished", but for all intents and purposes, when I pulled it out of the box, it was brand spanking new; no wear to speak of.

Dell E64xx.  I'd like to take a moment to reflect on these laptops.  I spent quite a bit of time looking into the offerings from HP as well.  In particular, the HP EliteBook 8440w and 8540w which I was also considering.  Ultimately, having had my experiences with the E6400 the first time and seeing the build quality of the E-class Latitudes, it was hard to justify shelling out the additional premium for the HP units (the pretty consistent 15% off coupons for the Latitudes at Dell Outlet are a big incentive).  Given that the performance difference between the two would be largely marginal, I stuck with the E-class laptop once I found out about NewModeUS (Dell doesn't let you configure a laptop with two 2.5" hard drives the way I wanted it configured and it was one of my key criteria as I keep several multi-GB VM images on my laptop).

Overall, these laptops have been a joy to work with.  Far better than that Lenovo T series laptops (which my sister purchased herself despite my suggestions and which I use for some clients).  The screen is bright, the connectivity is great (though no USB3, it does have eSATA and a DisplayPort connector), the keyboard is excellent (especially with the backlighting), the web cam and microphone are excellent, it has a pointer "nipple", and the build quality is top notch.  I regularly pick up the laptop one handed and there's little discernible flex; the chassis is very rigid.  I also like that the system is so easy to customize for the do-it-yourselfer.  This allows you to buy a cheap chassis (focus on the CPU) and simply just replace the RAM and the HDD.  The entire underside (a thin, magnesium alloy plate) is held in by one screw (to my surprise).

Even with the Core-i7 onboard, it isn't any noisier nor does it run appreciably hotter than my Core 2 Duo packing E6400.

I've also come to really like the overall design of the E-class Latitudes.  They're relatively thin, simple, and classy looking.  Much better looking than the Lenovos.

Dual Core or Quad Core? I struggled with this for a while as I was heavily considering one of the quad core Core-i7 processors.  However, I'm glad I chose the dual core.  I've found the performance to be excellent and the price, heat, and battery life trade-offs to be the big win.  Generally speaking, in development, it would seem that your limiting factors are the disk speed and RAM rather than the number of physical cores.  Given that the dual core CPUs have faster physical cores than the quad core CPUs, my feeling is that one is probably better off with the dual core Core i7 CPUs for a development laptop.

There was some good discussion on a thread over at NotebookReview.com with great insight on the topic.  Highly recommended read for developers in the same quandary as I was on dual core vs. quad core.

At the time, I was also thinking that having a quad core would help in terms of the VM (I was getting terrible performance on my SharePoint 2010 VM) by being able to assign two cores to the VM, but the VMWare documentation seems to advise against this (can't find it now, but there was a whitepaper on this very topic) in most scenarios.  In practice, with the 8GB of RAM and the SSD, the dual core Core-i7 has proven to be more than enough.

Suggestions for Developers. For any developers looking to get your own laptops or for small development shops, I'd definitely recommend looking at Dell Outlet and the E6410 and E4310 laptops.  Wait for the 15% off coupons and you'll get yourself a steal.  For the time being, unless you plan on getting the top of the line quad core Core i7 and you aren't concerned about heat or battery life, I'd stick with the dual core Core i5 or Core i7 CPUs.

Here's what I would do (once I've got a 15% off coupon code):

  1. Buy the chassis with the best CPU and ancillary features that are important to you (web cam, battery size, BlueTooth, Windows 7, x64, etc.) that you can find in their database.  For the most part, disregard the HDD, even if it comes equipped with an SSD.  You can kind of disregard the RAM, but look for something that has 4GB in one slot.
  2. Buy a Sandforce based SSD (the Calisto is a great SSD -- I've already purchased two of these).  You can check LogicBuy.com as amazing deals do occasionally surface.  Target at least 120GB.
  3. Buy an extra 4GB of RAM from Newegg.
  4. Buy a drive tray from NewModeUS for your chassis (do note that the drive tray is an actual SATA interface -- WIN!).
  5. Buy a Western Digital Scorpio Black HDD and plug that into your new drive tray (Amazon has good prices if you have Prime).  Use this drive to store you large files and your VMs (store your source files on the SSD for speed).
  6. Buy an external enclosure for whatever drive you take out of the chassis.  I've used the ACOMDATA Tango enclosures (see my review at the link) which supports eSATA.  Use this as an external drive or for backups.
  7. Do a clean install with the SSD as the primary.
  8. Once you have you system reinstalled, be sure to change the write caching policy to improve performance on the disk in the tray.  Follow these steps:
    1. Right click on Computer
    2. Select Manage
    3. Click Disk Management
    4. Right click on the disk and select Properties
    5. In the Hardware tab, select the disk and click Properties
    6. In the new dialog, select the Policies tab
    7. Here, you should enable write caching and you can also turn off the Windows write cache buffer flushing if you want.  Since it's essentially an internal drive now (unless you plan on hot swapping it) with battery backup, it should be pretty safe (but do so at your own risk!)

Write caching configuration

I'm not sure how the Seagate Momentus XT hybrid drive does in terms of large files that you'd be working with in terms of VMs, but I've had pretty good success with the Scorpio Black.

Suggestions for Dell. Get some better web developers.  Seriously.  The Dell Outlet site is barely usable.  It was terrible before they fixed it up, but they've somehow made it prettier, but much harder to use -- I wouldn't have thought that possible given the state the site was in when I first used it.

With a bit of patience (waiting for the coupon), luck (finding the right configuration for your needs), and elbow grease (upgrading a few components yourself), you'll have yourself a killer development machine at a great, budget friendly price.  My E6410 is now my primary and only development machine.

Filed under: DevLife No Comments