The Software Purist |

TAG | Software



Characteristics of Software Company Size

I find that it’s something interesting in software companies, that often, depending on the company size, things work very differently. Of course, this can be true for any profession, but for software, it seems to be at a larger scale than other areas of development. In this post, I will go over some general categories and then my experiences and perception for each.  I will also put a general figure for each, as far as size,  which is the size of the company, not specifically the development team. This will go over what I feel is generally more of a typical company of that nature. E.g.: For a 100 employee software company, generally at least 10-20+ developers. If it falls way outside the range, it’s an atypical case, that I won’t be covering here.

Very Small/Tiny (5-15 employees)

Very small companies are generally run as your typical start-up style. That means that process is commonly limited or non-existent. Software tools are kept to only what is absolutely required and what is free. Teams are kept small, as is the company. Communication is widespread, e-mails will often go to the entire company, because there’s little point in excluding the one person who it doesn’t apply to. The group is often close-knit and may even have lunch together every day. Management is thin or non-existent. With these strategies, most overheads are eliminated, and because the team is so small, it can be justified and gotten away with. Software developers are often working on a large piece or the entire product by themselves. Getting code done fast and to market is often more important than designing it well, which may come at the cost of having to rewrite it in a few years, if the company grows, but it’s considered worth the risk

Small (16-80 employees)

Small companies borrow a lot of characteristics from their very small predecessor. Most small companies started out with years under their belt as a very small. This has given the company both good experience and some responsibility to rethink what worked in the past. Some of what worked in the past worked because they were so small and the scale of their product was smaller, so they got away with doing it quickly and without following best practices. In a small company, they will review some of what’s been done and potentially rewrite some pieces with future goals in mind. In small companies, e-mails start to become refined so they won’t go to everyone; the volume would be too high, as to where e-mails would just start getting ignored anyway. Software process goes from none to minimal. A process is generally put in place where management is there, but their job is mostly revolved around staying on top of development, and in some companies, interfacing with the customer. Usage of process is done, but usually not “by the book”, so to speak. Development generally takes a bit longer than very smalls, but the software is generally written a bit more robustly, as company goals become more defined.

Medium (81-300)

Medium-sized companies generally stem from small companies who have grown. Depending on what phase the company is, because there’s a wide-gap in there, it can exibit characters closer to a small company or closer to a large company. Process generally becomes defined better, and they start to try to follow software processes. Managament gains the additional responsibility of enforcing process. Rearchitecture general does not put the company at financial risk. E-mails are sent purely to those who “need to know”. Interaction starts to occur through layers; a software developer generally wouldn’t interact directly with a CEO.

Large (301+)

Large companies are characterized by, a generally, lengthy existence. They have tried many methods and have an idea what has worked for them and what has not. Process is well-defined, and there are a lot of layers of overhead, but these are often required to ensure successful management. Operating processes are generally less efficient, but in the end, they generally put out better tested products (not always). E-mails to the entire company are frowned upon, unless you’re a human resources, or have a title such as VP. Development cycles are generally longer and the company has a long-term roadmap, going out 5 years or more. Many employees will never meet the CEO or president. Developers will generally be specialists. Some developers will specialize in  a GUI technology, another will specialize in a specific-back end technology. They might work with this one technology for years.


So, that’s my overview. There are a few points I want to note for technical accuracy. There are well-defined sizes for companies defined by legal terms, that I specifically avoided adhearing to: This discussion is from my perception. Additionally, as we all should be aware, every company is different. Which means, that some of what I’ve said may not apply to your company. If so, don’t take offense: I don’t work at your company… unless I do, in which case, you should tell me who you are. 😉 Finally, some of these also vary by industry. A large gaming company is likely to be very different than a large defense contractor. I hope you enjoyed the post, and of course, I look forward to your feedback.

· · · · · · · ·



Scrum: Agility and Practicality?

In this installment, I wanted to discuss the Scrum software process. I have worked on some Scrum projects and I intend to go through some of my experiences in the following post. Scrum is often referred to, as simply, Agile. However, calling Agile a software process is a bit of a misnomer. Agile is a classification of software processes that share a few common traits: Iterative styles of development and a more fluid ability to react to a change in requirements, strategy or customer needs. defines the word agile as being the following: “1. Characterized by quickness, lightness, and ease of movement; nimble. 2. Mentally quick or alert: an agile mind.” So, this flows with the general spirit of Agile. With this in mind, I can share some of my experiences, particularly with the most recent large project I worked on that was using the Scrum methodology.

The first thing to note when discussing this project is that I have worked on other Agile projects before. Generally speaking, however, prior to this one, saying we were doing Agile was more of a catch phrase and Agile wasn’t really being done. Having been trained in Agile and having done my research, in these cases, I was well aware that we weren’t doing Agile, but I believe I was in the minority. Anyway, coming back from that tangent, in this most recent project, the group did make an effort to follow Agile, as it was being dictated by a particular customer. More specifically, we were using Scrum, although most of the way through the process, most of the group was unaware that Agile and Scrum aren’t simply synonyms. An interesting blog article discussing this common problem can be found here.

Anyway, my experience with it wasn’t really a positive one, although I don’t necessarily think I can fault the Scrum process itself. The idea of a daily morning scrum with a small group of people seems like a logical idea. In our case, it wasn’t so effective, because our group was as high as 16 people, including project managers, technical managers, developers and QA, in two different offices. For the overseas office, the meetings were in the afternoon for them. Because of the high quantity of personnel, the meetings took 30 minutes – 1 hour instead of the recommended 10 minutes or thereabouts. In addition, the meetings degraded quickly, with developers discussing specific issues instead of keeping things at a high level, following the general rule of three: 1) What I worked on yesterday, 2) What I will work on today, 3) Blocking issues. Attempts to redirect it back to these three 1-3 sentence overviews weren’t always appreciated.

Again, this isn’t condemnation of Scrum specifically, as I think it had a lot to do with the structure of the meeting. That being said, I think daily scrums can degrade pretty rapidly, and it’s especially at risk, the larger the group. In addition, we typically started in the 9-9:30 AM range, however, the meeting was often at 10 or 10:30 AM. I find I have very good concentration in the morning and breaking this routine had an impact on my morning workflow. The increased communication is important, but I question whether it would’ve been better to end the day with this meeting. I ran into this same problem at my previous company, when we worked with Scrum: The meetings would last too long. In that case, the group was much smaller, but again, developers are developers, and sometimes the moment they think of an issue or interesting concern, they want to discuss it right there, even if it’s not the appropriate forum.

The second critical piece of the Scrum methodology is sprint length. Scrum recommends one month sprints. In the most recent project, sprints were generally two or three weeks at various points during the process, which I felt was too short. The problem with the reduced scope of this sprint length is I find that there’s too quick a push to show results. Sometimes when designing a complicated and major feature that integrates with multiple different system components, this can be too short. Sprints this short require too often a time to leave the system in a stable state to display to the customer and to management. In general, I recommend if you decide to do Scrum that you stick to the suggested one month sprint length.

Some other important artifacts of the Scrum process are the product backlog, user stories and burn down chart. The product backlog makes a lot of sense; unfortunately in our process, the product backlog was not used by upper management. I believe this is due to it being the first time the company had really tried to use Scrum. I think things would’ve flowed a lot better had the product backlog been used effectively. User stories are a tool which seems to be the Scrum replacement for Waterfall-style requirements. The idea of user stories makes sense, but I found that they were very time consuming to write. From here, the user stories derived into the sprint backlog tasks, which were intended to be short tasks between 4 and 16 hours. The final piece is the burn down, which basically gives a simple representation to figure out if you’re going to hit your target for the sprint. It will give you an idea if you’re nearing the danger zone.

One problem I frequently encountered during this sprint backlog tasks is for the tasks, the development teams often over-committed. It’s very easy to look at a small feature and say it will take only four hours, but the four hour estimate was often a best case estimate, without taking any consideration for integration, testing and bug fixing. So, it would generally follow that the team was working 60-70 hour weeks to meet the goals, due to the mis-estimates. Once hitting the mis-estimates became commonplace by upper management, they pushed for the same amount of committing with all sprints, so the development team had dug themselves into a hole, due to the poor estimating.

A critical piece of the scrum process is the sprint planning meeting. During the sprint planning meeting, the goal is to plan the tasks that will be done for the sprint and decide on who will do them. However, part of this process is that the sprint meeting will take no more than 8 hours and that the team will sign up for tasks they will do. However, this frequently was not the process. Mostly, it was a few senior developers and management deciding on who would work on the tasks. As you might have guessed, I was among the deciding group, although I objected to not including everyone. Furthermore, because not everyone was included in the meeting, the meetings often ran way over; I recall one that started in the morning and basically ended about 15 hours later. I generally recommend that there needs to be prepared prior to this meeting and the tasks should flow from the product backlog. Everyone should come into the meeting prepared and with some goals in mind. If people come unprepared, the meeting will drag. If not all the right people are involved, again, the meeting will drag. Unfortunately, no matter what the outcome is, you’re almost guaranteed to lose a full day of development every sprint, just deciding what tasks will be worked on.

The final piece I’d like to mention is that during a sprint, Scrum dictates that tasks shouldn’t be changed. Management cannot dictate priorities for the current sprint. They can change requirements for future sprints, but not the current sprint. In our case, this advice was not heeded. Both management and the customer would frequently change direction during the sprint. This resulted in a lot of rework and a lot of late nights adjusting to the new requirements. I have a feeling that this is commonplace during Scrum, which is part of my distaste for the process itself.

Ultimately, I think that Scrum makes a lot of sense on paper. Having gone through multiple projects which have made some use of Scrum, including one that made heavy use of Scrum, I have not seen any of them work effectively. In a way, Scrum promotes poor development practices, because the focus on rapid change somewhat discourages the practice of thinking a design and architecture through, which can lead to premature gratification that ultimately makes a more difficult to maintain design later. I’m definitely no fan of a strict Waterfall process, but I am confident that Scrum, in the process of fixing some of the flaws of Waterfall, has created some new ones in its place. I do think that education in the usage of any software process, whether it’s Scrum, XP, RUP, CMMI, etc… is essential to things working smoothly. The fact is that when faced with deadlines and pressure, people will revert to their most familiar behavior, some of which does not play with a process like Scrum. On a side note, a few developers I’ve worked with in the past have been very fond of the XP process. I have some doubts about XP, as well, but I can say that when I have used it, I have seen some benefits.

· · · · · · · · · · · · · · · ·



Software Outsourcing, Part II

If you have not read part I of this series, please check it out first:  My Experiences With Software Outsourcing. My first entry in the series discusses some of my experiences with outsourcing. In this second installment, I discuss these issues a bit deeper and provide my overall thoughts on outsourcing.  I’ve already gotten some great comments on the first article, which I appreciate.  One thing I should clarify is I’m not against outsourcing, just against certain approaches and motivations by companies who decide to use outsourcing.  In this article, I present scenarios where I think it may work.


As I mentioned in the previous edition, time difference can be a huge factor.  Teams that are intertwined often need to work closely and need more immediate feedback.  The only way to reduce this coupling is… well, to reduce the coupling.  Therefore, I am of the personal opinion, that in outsourcing, much like software, there should be a large desire for low coupling, high cohesion.  You have to trust your outsourced developers to do the work with the right instruction.  If you don’t have this sort of faith, then outsourcing is not for you, because the overhead can be high enough to defeat all discounts, and potentially, even be more costly.  Having dealt directly with this, I know from experience.  Ultimately, the goal is to desire economies of scale and avoid diseconomies of scale.

Low Coupling

High coupling occurs when any one person is free to contact any other person in the company.  Not only are they free to, but it is encouraged.  This can happen in one office.  The problem is if a single person takes direction from multiple sources, it’s more time cumulatively time consuming.  This can be deceiving, because to the person who made the request, they often got feedback quicker than if they had to go through channels.  However, for the person who served his 30th request of the day, it is well known that this is not efficient.  If this person who has been communicated to, by so many people, is a developer, all of this intercommunication prevents entry into “The Zone”.  This is one area where all of these channels of intercommunication can be the most costly.

The reason why this behavior is so prevalent is very simple.  It works extremely well when a company is small.  In a 10 person company, every person knows every other person and likely communicates daily.  But there’s a reason why this is so efficient: The company is small enough that there is likely no more than two managers, and everyone is strictly focused on work and completing their own tasks.  Then, each person merely talks to the person who he or she most needs to communicate with to complete his or her task.  The problem is that, as you likely realize, it does not scale well at all.  Putting project managers in place is a step to reduce that, since the project managers can act as the point of contact.  However, it doesn’t go far enough, unless the offshore project manager is given more authority, and the onsite project manager is more used for communication and just communicating ideas back and forth.  When it goes further that this, I believe it’s demotivating for the foreign employee to be working through multiple layers of management and messages being relayed.  And of course, it’s costly, resulting in a lot of rework, due to miscommunication.

My ultimate recommendation here is that each office should work on disjoint projects, with potentially different sets of standards and rules.  I think it’s tempting at first, to couple things tighter, because from a company perspective, it makes sense to not duplicate work.  As a purist, I feel that duplicate work is generally not cost-effective.  However, in this case, I think it’s sometimes acceptable, mostly because the alternative may be worse.  So, I generally feel that in order for the scheme to work, it has to be treated as almost two different companies.  The US location should act and be treated like a customer.  The foreign location should act and be treated like the supplier of the software.  In this scheme, I think it can be valuable, because you forego most of the overhead of the interoffice communication, except from the perspective of a client, who is concerned with functionality and not dictacting architecture.


The last thing I wanted to talk about in this installment is the motivations behind outsourcing.  The obvious motivation is saving money.  There’s no doubt about this, and it’s justified.  However, I see outsourcing as an opportunity.  You are getting developers for a fraction of what they would cost in the US.  Some companies take this a step further and even look for a deal in those countries.  I have to say, I think this is going overboard.  If you’re already getting developers at a fraction of the cost, why would you then proceed to also get inexperienced developers to save a few extra thousand per person per year?  If I was me, I’d pay highly there to get the most talented. It’s often cost prohibitive to get the most talented developers in the US, but abroad, it isn’t. I also feel that by getting the most talented developers, you get people you can trust to do the job, which also flows well with the concept of keeping overhead minimal.


Studies have shown that the cost benefits for outsourcing are often minimal, especially for companies who are seeking a deal. In pure cost analysis, because of the inherent overheads, it can provide little cost benefit, or in some cases, even be more costly.  I discuss scenarios where outsourcing might work, but it needs to be done with care.  If you’re a discount shopper, you may be fooling yourself.  If you use outsourcing to simply increase the pool of talented individuals who you may employ, the strategy has potential to be effective.

· · ·



Software Testing

I wanted to migrate this post from my old blog. I have added it here:

I was thinking a good topic would be to talk about a few different types of tests a software developer can do and what each provide.

Unit Tests

The purpose of unit tests is to test the functionality of a generally lower-level software module. External dependencies are stubbed out and mocked, so that you can test components in isolation. Checks are very granular and the test will generally give a pass/fail result, which makes it easily automatable. In my experience, there is often some confusion as to what a unit test can and cannot do well. For example, you might write a unit test that tests a class called String. It might find that you have two issues with this class that you fix. However, this won’t necessarily have a noticeable effect on your product. Unit tests are to make the developer’s life easier, because they take really difficult-to-fix bugs that wouldn’t be found until later stages and make them into generally easy-to-fix bugs at earlier stages. This flows in with a process known as risk mitigation.

However, they don’t necessarily make the development cycle take less time. When unit testing is done elaborately, including using a process like Test-Driven Development and automating these tests when making a build, they can be extremely beneficial. But, where time may be saved is often the deployment and QA teams, not necessarily the developers. Companies have to be willing to pay the extra cost for these tests in the name of higher quality, a smoother process, and to ease refactoring. Finally, unit tests are typically terrible at testing any non-deterministic process, especially when threads are involved. It is also generally difficult to test GUI functionality.

Integration Tests

I find these generally less useful, because this is the middle ground, as has enough overlap with unit tests and broader tests that they sometimes can be excluded. Still, in some scenarios they are quite useful. Just like in unit tests, integration tests tend to be automated, but this is not always the case. Where integration tests differ is that you generally don’t stub out interfaces, unless it’s an interface that is totally superfluous to the test or would prevent the test from running in an automated way. An example of a integration test is it might run the core engine of your application along with another component of the application, such as a logic module. The integration test would start by running a database query to reset the database to a known state, send login requests for 100 users, and verify that the 100 users logged in. It would then check the database and make sure the 100 records were properly set into the database. Then it would clean up the database.

Load Testing

I find that these are the tests I write towards the end of the cycle. You generally can get away without these if you’re making a standalone application, but it is essential for a server application that expects a high user load. The load testing script, often written in a language simpler than your application, such as Python, will simply simulate a bunch of users repeatedly trying to simulate a variety of scenarios during the test. They often all try to simulate the same scenario, but sometimes they try to stimulate different areas of the system at the same time. Verification at this stage is generally minimal, because in most situations, the users can interfere with each other, creating false failures. What you are trying to verify here is longevity test to prove that the server can withstand a constant barrage for n hours with m users. Failure on this test will often be discovered manually when you come in to check it the next morning, and will be something of the nature of a crash, deadlock, excessive memory growth, performance degredation, etc… Smaller issues, such as 1 out of 1000 users not having their record stored in the database are unlikely to be discovered.


While this isn’t all of the types of tests a developer will use, I find these to be the most frequent in my travels. One thing to keep in mind is setting expectations at the appropriate level. Developer-level tests are extremely valuable in making the developer’s life easier and making life easier for your coworkers. The thing I want to keep emphasizing is that they don’t necessarily save time and money, though. I give this caution, even though I’m a huge fan of software-level testing. You write tests for quality, period. Some hidden benefits are that they also provide additional “documentation”, example usage and generally make refactoring easier, because if you have to fit your code into a test, it’s more difficult to take shortcuts.

Overall, I have worked at both companies where quality was held highly and others where it wasn’t the most important factor in the success of a product. You have to decide for yourself what’s most appropriate for what you’re doing. One thing that’s important is setting expectations correctly. Sometimes management will think that if you write a test, the software will be bug-free. There isn’t a single piece of non-trivial software that is bug-free, anywhere in the world.

Also, I came across this, which is a great description of various different types of software testing:

· · · ·



“The Zone”

One of the mysteries of software development, as well as many other professions is the concept of “The Zone”.  This is also known as “The Flow”. Wikipedia defines it as this, “Flow is the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity.” You can witness this in a sport such as basketball. I recall quotes from Michael Jordan, in the 90s, about a game he had in the NBA finals, and how he was in the zone, as he singlehandedly led his team to victory.

The fact is that when you’re in the zone, you’re performing way above your normal state, things come naturally, thought is mostly unconscious, and you have extreme focus, which ultimately lets you process things far more quickly and effectively. Ultimately, developers get in the zone too. I know when I’m in the zone, I’ve done multiple days work in what would otherwise take a few hours. This usually happens for a combination of reasons: being well rested, interest in what I’m doing, determination, and a concept of a goal that I want or need to achieve.

I know other developers I’ve worked with often talk about a similar process. A mentor of mine from years back once said that he often starts a project slowly. Then, when he’s working, suddenly things just “click” and he quickly makes up for lost time, and that’s why his performance was good. I think this happens to a lot of us. I believe that the moment when things “click” and suddenly in the course of a few days you get a massive amount of work done is “The Zone”. In software development, the zone doesn’t happen all the time, and it needs to be realized that it’s important when it does.

Breaking the Zone

One of the challenges is the zone is working in an office workplace, where there are potentially a lot of distractions to remove you from the zone.  Mostly, I find these to be other employees.  Ironically, the lower you are in the chain, the more zone opportunities you will have, because generally you have less points of contact.  Each time, as a developer, I’m interrupted, it can be as short as 10 minutes and as long as an hour before I re-enter “The Zone”.  This kind of productivity loss should be considered unacceptable for most companies.  If you’re a company saving a few dollars by keeping the employees crunched together, shame on you.  It provides more stress for your developers, who are often, not a social bunch to start with.

Keeping the Zone

Obviously, as Joel Spolsky suggests, giving each person their own office is a big help, because it reduces the temptation to distract others.  This is a huge benefit, but it’s probably not possible for every company.  In general, I think high wall cubicles are also fine.  Noise levels should be kept in check by management and policy: Keep outloud music to a minimum, personal conversations should be taken elsewhere, and impromptu meetings should be a rarity and should occur in conference rooms.  This policy should be enforced and if someone is violating it, they should be asked to be more considerate.  Having inconsiderate neighbors is never a good experience.

Another thing that helps is investing a good set of headphones.  For some people, it’s best to get a studio-style headset or gamer headset, which will block out almost all noise.  If you want to be aware so you can hear nearby voices, but ignore most sounds, you can use a cheaper headset.  Again, though, note that this can be an unnecessary distraction for you, but can definitely be a tool for the paranoid.


“The Zone” is an psychological state every developer loves getting into.  The work flows faster, better, and with higher quality and focus.  It is sometimes difficult to stay in the zone when working due to outside distractions, but with some careful techniques, companies and individuals can make it easier to stay in “The Zone”.

· · · · ·



Interviewing Software Developer Candidates

One of the more challenging things in your professional career as a developer is evaluating potential candidates for hire. I wanted to discuss this topic a bit and provide some of my experiences and opinions on the matter. I think this is an area that a lot of developers have a challenging time with, being that we are often not social beings by nature and, therefore, are at risk of evaluating purely based on superficial characteristics or not asking the pertinent questions.

Who should interview

The first thing is knowing and noting the roles of all the players in the interview process.  In most cases, the manager cannot provide the technical deeper level of a tech out.  Likewise, the developer can’t be expected to focus on the high level business goals during the interview process, because the developer’s foremost concern is and should be: “can this guy code?”  If you’re a manager reading this, you need to understand that a suave developer can BS his way past any answers.  You need that expert developer to counter-balance from the technical side.  Any interview process for a software developer that is done without a developer present is a risky proposition, because managers are a risk for hiring the best speaker, instead of the most talented.  Ultimately, at least one manager and at least one developer should be involved through the process.  Ideally, you may want as many as 3-5 developers involved in the process, because it removes the responsibility from a single developer in finding the shortcomings.  The developer MUST be an expert in the subject matter he is interviewing for.  If not, he is at the same risks as the manager was.

What to Look For

There are two levels of things to look for during an interview.  The first is personality.  You need to be confident of positive answers to the following questions.  In most cases, the manager is more keen to these than the developer:

  • Does he or she tell the truth?  When pressed with a question he doesn’t know, will he admit it or will he not acknowledge his mistake?  A developer who has a habit of lying can cause real problems for teams he works with in the future.
  • Does he or she point the finger and/or place blame at others during the interview process?  This is a big warning sign.  It’s normal to have a bit of disdain for your previous company, but the interview is not the place to do it.  If the developer does this during the interview, you can expect more of the same once they’re onboard.
  • Is his work experience relevant?  Can he explain pieces of his work experience in detail?  Does he sound like he has pride in his accomplishments?  Does everything sound like a team effort or did he accomplish a lot outside of the team goals?  A developer who only says “we” is giving off subtle warning signs.
  • How quickly does he answer questions?  Slow answers sometimes mean either: A) the developer was confused by the question, or B) the developer is in the process of making up an answer.  If it looks like B, end it quickly.
  • Basic knowledge of company and position applying for.  Most candidates will spend a little time investigating your company.  You always want to know if he wants to work there, so this is important.  It should be a very small piece, but it’s a warning sign if the developer didn’t spend the time.
  • How does he react to pressure?  Give him a problem he couldn’t possibly know.  If the developer sweats, swears, freezes, etc… it may be time to move on.  If the developer will try to work through the problem, it’s a good sign.
  • Find out what his interests are.  What does he read?  Developers who don’t read quickly become obsolete.

The second group, and equally important is the technical portion.  This is where some managers fail.  A developer can appear to pass with flying colors on the first part and then simply not be a good candidate because of technical reasons.  Or vice versa.  Every candidate is different.  Here are some of the things you need to know from the technical point of view:

  • Ask beginner questions, intermediate questions and a few advanced questions.  In a first interview, these can be kept to generic situations.  In later interviews, you may want to get into more specific scenarios, such as a simple application and how they would approach it.  In any case, you look for consistency.  It’s okay to get a question wrong.  Depending on your questions, the level for what passes and what fails can vary.  A rule of thumb is to find a developer you trust and ask yourself what he would get if you quizzed him.  Then subtract as much as 10-20% from the score and you have your bare minimum.
  • Ask questions about coding style.  Find out what his favorite style is, then casually ask if he’d be comfortable using the opposite style.  His reaction will tell you all you need to know.  In my experience, there are a number of developers who are very particular about style.  This is one of the least important things when developing code, yet one of the highest contention points.  Anyone who demonstrates contention during the interview is not a team player.
  • Delve into job history a bit and ask him about interesting coding problems he came across.  If the code he wrote was a while back, it’s a very good sign if he discusses what he did at the time and then how he would improve on it now.
  • Problems like, “here’s a code sample.  Do you see any issues with it?  What could you do to improve it?”  These sorts of exercises are very useful to see how he thinks and if he can read the code of others.
  • Give a specific problem and ask him to draw UML diagrams.  See if the high level architecture matches the concepts.  Does he use design patterns?
  • Find out his comfort zone.  If he’s really into high level programming, give him a problem that involves bitwise logic.  If the programmer is an expert at Intel assembly, give him a high level problem.  Reaction and approach will be very telling in these cases.
  • Finally, don’t try to nail anyone to prove you are smarter.  I’ve known one interviewer who did this, for reasons beyond my understanding.  The point of the interview is to hire a candidate, not to prove your intelligence.  Your intelligence is already accepted, because you are employed, in the position you hold.

Defective Habits During or After the Interview Process

  • Not being prepared.  There’s no excuse for this.  Every single resume requires 30 minutes to an hour of dedicated attention.  You should go into the interview with a list of questions already prepared, just from reading his experience.  Note the time hit here: Each candidate you decide to interview can take anywhere from an hour of time to 3 or 4 hours of time, depending on how far along the interview process they make it.  Management often does not understand how time consuming the interview process is.  If you work at such a place, you should seriously consider your own options.
  • “We’ll give him a shot”.  No, no no.  Don’t hire a candidate unless you’re sure.  It’s too expensive for the company to hire candidates and then fire them later if they don’t work out.  The company should not be taking this risk unless they are fully aware that you really are unsure.  Be sure.  Hold additional interviews to make sure you’re sure.  If you go a lengthy period without being sure and the candidate is on the fence, you’ll need to pass.  It’s not fair to hire a candidate under those conditions.
  • Long waiting times.  If you truly like a candidate and he is “the guy”, you need to move on it.  You can afford to wait on a maybe, because maybes are a dime a dozen, but not “the guy”.  If management is dragging their feet, they need to be reminded that it could take months to find a equatable candidate if they move too slow to make an offer.
  • Focusing only on style.  I have seen so many developers do that that it drives me nuts.  The most important thing is not whether the developer codes with the same style as you or uses the same favorite library as you.  The important thing is whether they can do the job and whether they will play by the rules.  If they fit these two criteria, you’re gold.  You can tell if you’re getting into this habit if every K&R-Unix code sample looks “good” and every Allman-style Visual C++ code sample looks “messy”.


Ultimately, developer interviews are a tricky process.  The post was getting a bit on the long side, so I think I’ll have to do a follow up to it at some point soon.  Regardless, hopefully the point has gotten across and makes sense.  These are some of my tips based on my experience and hopefully you will take them into account in your interview process.

· ·



My Experiences With Software Outsourcing

In this edition, I wanted to discuss the somewhat controversial topic of software outsourcing. I have now experienced it personally, having worked at one company that heavily employed this tactic. On a technicality, the company actually was doing more off shoring than outsourcing, since the company had a second office in Ukraine and any outsourcing done was also in this country, in an attempt to pool resources and minimize risks. Because of this, I think I’ve become pretty intimate with outsourcing and plan to discuss the scenario I saw and the results that I can see.

The first thing to note is that at various times I was either directly or indirectly managing and mentoring other developers in a foreign country. There were a lot of challenges I saw with this mechanism and because I this I think I can provide a somewhat unique perspective on outsourcing and how the company handled it.


I need to give some background as to how my company handled the structure. The offices were treated as two separate offices with parallel hierarchies. Neither office necessarily had authority over the other, except for the president and CEO. However, there were additional levels of implied hierarchy, where it was clear that if certain people were involved that they needed to be listened to, even if there were disagreements. I believe this implied hierarchy naturally occurred due to (or perhaps, in spite of) the company’s resistance to putting a more formal structure in place. Now, this was the official hierarchy. Unofficially, and unfortunately, the company appeared to have no faith in the Ukraine developers getting the job done without being babysit. So, a parallel structure of project management existed in both offices, where the US Project Manager’s job was to babysit the Ukraine Project Manager, whose job was to babysit the developers in the Ukraine office. I will discuss this is detail below.I personally do not advocate this approach, but this is the approach they seemed to use.

Time Difference

The first major issue I noticed and noted was the time difference. Ukraine is 7 hours ahead of the eastern time zone, and so it left only a two hour window during the work day to intercommunicate and coordinate. It is extremely tough to give a day’s worth of instructions with this small window. Furthermore, as a developer in a US office, when you come in in the morning, the Ukraine developer is getting close to ending his day. This provided a number of challenges for both sides, including the fact that you’re just getting started and they’re in a panic because they know once your office is ready to talk, that they may not be able to get much or any more work done for the day. Additionally, it’s ultimately very hard to coordinate when you give instructions that, if you were in the same office, could be attended to that day, but due to the time difference, it has to wait a night. The trouble of getting critical information and then letting it sit for a night can be different for everyone, but oftentimes the information can become only partially represented because it may not be fresh anymore.

If you have new instructions to provide, there’s a good chance the developer won’t be able to attend to them until the next day. This leads to two critical problems that I noticed. The first is that schedules will need to be stretched, because the critical communication, which often needs to happen at multiple key points during the day is uncomfortably crunched into two short hours. Because of this, the developer cannot not attend to a critical piece on the same day that you need it. The second is that they will take the instruction, but not have you for reference to verify a piece they didn’t understand for most of their day.


Furthermore, the majority of communication is done via e-mail, instant messenger or Skype. None of these means are nearly as effective as having a person physically there to communicate with. This situation was further compounded by the natural language barrier, speaking with people who natively and fluently speak Russian, but not English. This wasn’t immediately clear for a while after I first worked with Ukraine developers. Communication was frequently done via Microsoft Live Messenger, and it just seemed the developers were responding slowly. It turns out that they were actually translating the phrases using a tool, such as Google Translate, and then translating back before responding. This was an unfortunate tactic, because for a long time, it seemed that they just weren’t listening, when in fact, many of the issues stemmed from the simple problem of bad translation.

Cultural Differences

One of the biggest challenges of outsourcing is facing a vastly different culture. I would say the most noticeable cultural difference has to do with communication style. In the United States, a degree of modesty is part of normal and required etiquette. Rarely is it acceptable to send an email or direct communication to more people than necessary. However, in Ukraine, I noticed that their style dictated more directness, which took some getting used to. For the individuals I worked with, it was common to send an email with an issue about a person and CC the CEO, President, and the entire development team, even though this issue could’ve been resolved with a much smaller group of people. This took a long time to adjust to.  I’m not sure if this is common or potentially just an issue with certain individuals.

One issue I saw in my company was that the company never invested any time in damage control. If a colleage was badmouthed, the time wasn’t spent to correct the misinformation, so without a rebuttal, damaging rumors become accepted truths.  In addition, there was a different level of work ethic and responsibility. Deadlines often were not enforced equally among the offices. I believe this was mostly due to upper management’s approach. Upper management appeared to approach things as if, because they were cheaper, they would get more leeway.


In this post, I talked about and addressed some of the challenges with software outsourcing. In the upcoming part II, I will explore this further and start to draw some deeper conclusions based on what I’ve experienced.

When it goes live, Part II will be here:


Theme Design by