Posts in  position


YAGNI: Ask about actual scenarios even if the features seem reasonable.

Reasonable feature requests

It's difficult in software development to shift the focus to problems and goals instead of features, features, features. As I've written about before, it's ideal to focus on the value first, and match the features to the value.

Sometimes we encounter feature requests that seem reasonable enough that we don't feel the need to back track to discover the value. This happens for many reasons:

  • We've encountered similar requests in the past, maybe with other projects, and it seems natural to add it to the current project.
  • We make assumptions about the value of the feature and the feature seems reasonable to attain the value.
  • We assume what scenarios would prompt the request and assume these situations exist.
  • Sometimes this all happens subconsciously!

Ask anyways

However, I've been surprised how many times:

  • What was needed in a past project wasn't actually needed and all of the sudden it's being added to yet another project under the assumption that it was of value historically. This becomes a self-perpetuating problem!
  • What was of value in a past project isn't of value in a current project.
  • The value isn't what we assume it to is, the problem we think we are solving isn't the same as past problems or the goals aren't the same as past goals.
  • The situations we assume exist probably don't, and even if they do, they may not be the same magnitude of a problem as in the past and thus might not require the same type of solution.
  • Past solutions (features) may not have been ideal.

Just ask!

Just this week I encountered a request that upon further inspection was prompted by a subset of the problems in a past project. Subconciously, I almost implemented the feature with the full set of problems in mind from the past. By inquiring about situations that prompted the request, we were able to create a solution that was a subset of the past solution! This reduced the time and money necessary to deliver value to the customer.

TLDR: Even if a feature seems reasonable, ask about the situations that prompted it. I've often been pleasantly surprised :)


Pattern: One Clearly Defined Project At A Time


All the time.


Prefer working on one project at a time. Finish it before moving on to the next. The project should have a definitive start and end centered around clearly defined business objectives.

I don't mean to suggest you shouldn't have multiple projects in your work life. Just prefer to minimize the number within a context, say a team of people working together. That said, there is value in minimizing the number of teams you are involved with :)


A common issue in software development is run on development. This introduces many risks:

  • Failure
  • Budget overrun
  • Infrequent delivery of results
  • Inability to measure success/failure of investment
  • Vestigial feature explosion
  • Incomplete feature explosion
  • Confusion about what the software does
  • Confusion about what the software should do
  • Buggy software
  • Lack of real world feedback
  • Lack of learning - reflection rarely occurs
  • Lack of trust - trust is built on results
  • General sadness for everyone as the work drags on with little or no results :(


Constrain each project based on a set of business objectives. Keep the list short and projects will start and end quickly.

If higher priority objectives arise, decide if they can wait. Ask what the value of doing it now versus a few weeks or months from now. If there's really no value (other than maybe excitement) then wait! If not, then decide what to do with the current project.

In my experience, working on clearly defined projects one at a time means we spend less time on each project, we know when we are done and we can quickly move on to the next highest priority objective. This often negates the need to interrupt a project.

Tips for interrupting a project

  • Replacing objectives - New objectives replace current objectives
    • Craft a project to address the new objectives and in the process discuss what has been done for the current objectives.
    • Determine what should remain
    • Determine what should be removed - if the objectives change there are going to be features that aren't necessary. Get rid of them or be prepared to pay to support them in the long run.
  • Different objectives
    • If at all possible discuss how to wrap up the current project with a subset of the objectives accomplished.
    • If that's not possible, put the work aside and switch gears.
      • Plan a time to come back to the current objectives. It's easy for months and years to pass. These easily become features that you may not get any value from but you pay to support.
      • If new and current objectives affect the same system, discuss removing or setting aside the current work so you can focus solely on the new objectives.

The value of code reviews

Next week I'm going to pair with Sean Massa to talk about Code Reviews in Node. In lieu of this I thought maybe I should write down some of the things I look for in a code review. My perspective on this topic is definitely not unique, but after years of doing these I think I have some ideas about what works and especially what doesn't! My first inclination was to dive in and organize anything that comes to mind into tips or patterns. Before I do that though, first I wanted to ask myself: "Why do code reviews?"

Why do code reviews?

Certainly there are derivative reasons, but I find myself coming back to these two:

  • Improve quality
  • Shared learning

I'm sure there are other possible reasons, but this should be enough to get started. To avoid duplication, I found these fantastic posts that justify why these are important:

Improving Quality

Ask "What were the requirements?"

Misunderstandings and miscommunication are a leading cause of problems in software development. Especially with the prevalence of the mediating involvement anti-pattern. Writing code is a translation of the original idea and as with any translation, runs the risk of "lost in translation."

If you're a part of the team, revisit the topic to make sure you validate your assumptions. If you're not part of the team, invest some time in understanding the purpose before doing too much code review.

Once you know the requirements, watch for discrepancies.

Ask "How do we know this works?"

Once we know what it should do, we can investigate how the author verified it.

  • Manual Verification? - If the author used manual testing, it's possibly worth keeping track of that somewhere so the same manual tests can be repeated in the future. Study or inquire about these.
  • Automated Tests? - Review them to see if they match the requirements.
  • On faith? - Even if it's simple, it doesn't hurt to manually verify the happy paths. If it's complex, consider automation.

Ask "How can we improve testing?"

  • Are there missing scenarios?
  • Is there an elephant in the room after implementing a feature - things that haven't been discussed that could be a problem?
  • Is there a way easily automate testing?
  • What testing scenarios could be added?

Ask "Do the tests help us communicate that we are done?"

Does our testing give everyone on the team, non technical people included, confidence that we are done? If not, how could it? Where would this be most beneficial?

Ask "Are tests explicit?"

  • Can you easily identify the AAAs (Arrange, Act, Assert)?
  • Are the tests difficult to understand?
  • Are the tests concise?

The tests should be reviewed like any other code!

Ask "Does the code make sense? Is it easy to follow?"

If the code is difficult to understand now, imagine how difficult it will be in a few months when anyone, the author included, is re-visiting it.

Here are some simple refactorings that can be done:

  • Rename abbreviated terms
  • Reorder code
  • Replace comments with composition
  • Extract class from parameters

Ask "Is this code simple?"

Complexity happens naturally, simplicity takes work and creativity. A second opinion can easily identify simpler alternatives.

  • Prefer explicit over magic
  • Prefer less code
  • Prefer declarative code, separate what from how

Focus on what matters

There's only so much time in the day. What little time you have for code reviews, make sure it's well spent. This requires prioritizing what you review. As I've said before, ask "Does it really matter?". Focus on complexity, the business domain, challenging problems etc. Don't worry about administrative CRUD interfaces. Focus on areas you routinely have problems. Focus on what keeps you up at night!

Identify repeat issues and do a root cause analysis

Keep track of common problems, instead of relying on the review to fix them, focus instead on using reviews to identify them. Then, work as a team to address the problems. Some examples:

  • Code formatting, style, and layout inconsistencies - perhaps invest in a tool to do this for you
  • Missing error handling - perhaps identify patterns or languages to get around these issues
  • Unused code - perhaps invest in a static analysis tool

Using code reviews to catch repetitive issues is going to be a problem when the code review misses it or fails to happen.

Ask "Does the commit log help organize the changes?"

One overlooked area of feedback is the commit log. Look for problems like

  • Files committed separately
  • Infrequent commits
  • Commits based on components of technology and not business value. IE: a commit for the controller, a commit for the model, a commit for the database changes and a commit for the view. Instead it's often much more useful to have these organized into one commit per use case/story/feature, especially when doing code reviews!

Shared Learning

This normally happens as a consequence of doing code reviews. However, if we are cognizant of it we can maximize the benefits and actually avoid doing things that can inhibit learning.

Review together

Do the code review with the author involved, there's no faster way to learn than having both people sit down together. Obviously this can't always happen, but for significant functionality it's probably a wise idea.

Don't rely on reviews to catch your mistakes

There's a trade off between wasted time reviewing and not enough, there's no guarantee every piece of code will be reviewed. Instead of relying on a review to catch mistakes, try to minimize the mistakes that you think are likely so the review instead focuses on highly valuable topics like simplicity, readability, verification and other areas where you can learn from others. Do the very best work you are capable of so you can learn new ideas from the reviews.

Avoid doing the work for the other person

Code reviews should be a process of feedback and discussion. Obviously there are times when you're refactoring and you just have to do it yourself. If you are intentionally doing a code review, try to involve the author in the changes.

In my experience, when I make the changes myself and ask the person to review them, I see more repeat behavior of the same problems, not a reduction. As a reviewer, be very cognizant of this risk.

Review sooner rather than later

The longer you wait, the more likely things that are important to discuss will be forgotten and the more likely the code will be in production causing problems anyways. Quick feedback is always beneficial. The longer you wait, the less beneficial a code review will be.

Pair programming

Pair programming is like the best form of code review, it happens instantaneously. Of course, make sure you use this judiciously. For example, there's probably no reason to use it on an administrative CRUD interface.

Don't use reviews to fix problems from people who don't give a ...

When people repeatedly make negligent changes and just don't care about the quality of the code, the code review won't help. I've made the mistake of trying to cleanup after this behavior and it never helps.

There's no way code reviews will solve this problem, they can only identify when it may be happening. Don't try to be the hero that always reviews this person's code, you will be very unhappy. Perhaps do some pair programming with the person to see if it's negligent or accidental, and then deal with it outside the code review process.

Assume good intentions

Unless you are dealing with someone who doesn't give a ..., assume the person does until proven otherwise. This will lead to a much more productive learning experience.

Ask why if something doesn't make sense

Sometimes you see something you don't understand, instead of inferring it's not necessary or was a "bad decision." Ask why it's there.

Avoid taking offense and try not to be offensive

We all take pride in what we do, keep it constructive. Likewise, if someone is coming across offensively, point it out politely. It's tempting when you get repeat behavior or rudimentary problems to become frustrated, but remember these can be a sign of a problem in the process, it's often a sign that people are rushed. Sometimes code reviews cannot fix the underlying problem.


At the end of the day, a code review is an opportunity for feedback. We do them to improve quality and to learn. The specific techniques will be subjective but keep the end goal in mind. Leverage techniques of testing, refactoring, automation, design and every other aspect of software development in the process.


Pattern: Establish Trust First


The first few discussions with a new consultant.


Ease into starting a project with new consultants. First invest in building some trust.


The first discussion is a great opportunity to talk about your business with the consultant. This understanding is invaluable and should be easy to talk about without advanced preparation. In subsequent discussions gradually introduce goals and problems.

Shared understanding is a great way to establish trust. Look for ways a consultant offers value through past experience, advice, and other feedback. This initial value can go a long way towards establishing trust.

Not to mention what it means for a consultant to invest the time to learn about your business and showing interest in what you do. Holding several discussions gives everyone a chance to reflect and bring even more to the table in subsequent discussions. This can be a quick way to weed out consultants that don't have the time to deliver quality solutions.

This is also an opportunity to show the consultant that you are willing to invest the time to build a quality solution.

Wouldn't your rather learn a bit about each other to see if the relationship will be a good fit?


  • Make the first meeting only about your business.
  • Subsequent meetings can lead into objectives (goals and problems).
  • Assess the trust you have established, keep notes!
  • Avoid talking about solutions in these meetings. Solutions in software development often take significant time to develop. Work on establishing the trust necessary to justify investing time in devising solutions.
  • Avoid talking about costs in these meetings. Costs are unknown before a thorough analysis of solutions. Instead talk about pricing methodology to determine if it will fit into an investment model you are comfortable with.

Pattern: Reduced Risk Initial Project


The first few projects with a new consultant.


While taking on the risk of working with a new consultant, minimize other risks including time, complexity and low value. Nothing builds trust like a completed project that meets your objectives!


  • Minimize Time - Work with the consultant to identify a project that can be completed within a time-line that is quick for your organization. I would recommended something around a month or less.
  • Avoid asking "Can X be done within a month?" Instead let the consultant identify the time-frames and compare relative time-frames to find the quickest projects.
  • Ensure that quick does not mean rushed. Quick means there isn't a large time investment. Rushed means efforts will be doubled up which actually increases risk.
  • Stick to a simple objective with clearly defined value and simple measures to gauge progress. This will lead to a much more definitive end of the project.
  • Maximize Value - Make sure the project is of high value. It's exponentially more difficult to build trust if there's not much value to be gained from the relationship. High value leads to better commitment on both sides. Honestly, I never recommend low value projects, I've never found a company short on high value projects but I've seen plenty of low value projects get in the way.
  • Avoid Complexity - If you have a set of projects that seem equal in value and time, pick the least complicated project. Complexity almost always leads to unknown risks.
  • Be prepared to discuss several sets of objectives to see which project minimizes these risks the most.


  • Complex, higher value projects will have to wait.

Antipattern: Mediating Involvement


Mediating involvement happens when information flows from person A to B to C, where A and C rarely talk directly. A & C could be individuals or a group. In some cases there are multiple Bs!

Think about the telephone game where everyone sits in a circle passing a message around until it comes back to the source. It's often crazy what gets back, even with the best of intentions. Imagine having a conversation back and forth between the first and last person in the circle!


Full disclosure: I've been guilty of being a mediator, it's not about blame, it's about what we can do to avoid these issues:

  • Miscommunication / misunderstanding
    • Even in direct conversation this happens.
    • It's even more likely in complex matters like software development.
  • Lost in translation
    • The mediator is very likely to summarize perspectives. Important aspects can easily be lost.
    • What if there was a miscommunication / misunderstanding in conveying the original information to the mediator?
  • Lack of creativity
    • Less minds = less creativity
    • Can't draw on the experiences of those that aren't involved.
  • Assumptions waste time and resources
    • Sometimes I'll ask a follow up question and a mediator will give me an answer they think is accurate when it's not.
    • Only after the software is built do we find out otherwise... ouch!
  • Unrefined information
    • No ability to carry on a quick back and forth conversation to refine ideas.
  • Huge delays in feedback
    • When it does happen, it often takes days for SIMPLE questions!
  • Follow up fails to happen
    • Follow up always runs this risk, even the most organized of people make mistakes.
    • I've never met a mediator who hasn't failed to follow up multiple times, even on critical issues!
    • Sometimes the mediator doesn't understand the value of following up, so there's no impetus to follow through.

In my experience:

  • Nearly every time someone speaks for someone else, I have a follow up question they can't answer.
  • Nearly every time I think I understood what someone said for someone else, eventually something comes up that was miscommunicated or misunderstood.
  • I've been blown away by the ideas that come from those that are often excluded.
  • The majority of times people say they will follow up I have to ask multiple times or just go to the source directly.
  • Countless times I've had to give up on mediators following up and make assumptions.
  • Most miscommunication / misunderstanding traces back to mediation, it's rarely from direct communication.
  • Software development is complex and time consuming. If it's not worth the time to involve everyone in simple conversations it's not worth the time to be developing the software.


This is very simple to mitigate. When a situation arises where involvement is needed, directly involve the responsible people in a conversation. This can't always happen immediately so keep track of these situations in an area visible to everyone so they can be addressed as soon as possible.

  • Clearly define roles and responsibilities
    • Users, Buyer, Consultant, Stakeholders, Subcontractors etc
    • Introduce everyone as soon as possible
    • Exchange contact information (email, phone etc)
  • Foster a team approach.
  • Everyone should avoid speaking for anyone else.
  • Consultant's shouldn't mediate the involvement of employees and sub contractors.
  • Analysts / managers shouldn't mediate the buyer nor the users.

Why analyzing value gets you results.

It's very common to hear from customers, "What will it cost to build X?" Naturally, I want to understand what X will accomplish. I consider this process understanding the value Y, the desired outcomes. Sometimes customers just demand a cost, but for those that are patient in analyzing the value these are the benefits they will reap:

Optimal solutions

My expertise is custom software development. If I don't know about Y I can't leverage my expertise to propose and build optimal solutions to achieve Y. I also don't have the opportunity to point out deficiencies in X. Imagine someone telling their doctor what medication to prescribe.


If you ask for results, you will likely get them. If you ask for features, there's no guarantee of results.

Significantly less wasted time

If I don't understand Y, when X doesn't accomplish it we'll have to try something else. You would be surprised, but when this happens I usually get requests for changes and new features, again with no guarantee of achieving Y. This has happened on every project I've worked on when Y wasn't discussed. Not only does this waste my time, it wastes yours. We are both stuck with the conundrum of who should pay for this wasted time.

Software development is an involved process, it's not just my time. Success requires your involvement in planning, implementation, user feedback, stakeholder feedback, testing, training and many other aspects. It's easy to overlook/underestimate this time commitment. Either way we both lose if we build failed solutions.

Timely results

If we reduce wasted time, you will get results faster.

Reduced cost

Less wasted time means less cost. Identifying and steering clear of low value projects means more of your money can go to high value projects.


Complexity in software happens naturally, simplicity takes expertise. Simplicity brings a whole host of benefits. If the focus is on features, features (complexity) will be maximized.

Maximum value

If the focus is on value, then value will be maximized! Low value features will take a back seat to higher value features.

Minimized maintenance

In my experience, maintenance cost is exponentially proportional to features. Minimal features means minimal maintenance.

If your business needs to make deliveries you could buy a Lamborghini. However, the cost to maintain it will be much higher than many other equally viable choices.

Flexibility to change

The more features the more difficult it will be to introduce and/or change features in the future. For every feature we must be careful not to "break" it with any updates. Naturally, if we don't minimize features, over time it will become very difficult to introduce change. Ironically, I find the features most likely to get in the way are the ones that aren't even used!

Reduced unused features

Do you want to pay to maintain features you don't use?

If I know Y, when your business changes I can make recommendations about which Xs can be removed. If not, in my experience, they never get removed.

Here's a great post on why less code is better.

Reduced training cost

The more features, the harder it is for users to learn to use your software. Keeping things simple for users means less training. Training cost is proportional, probably exponentially so, to features.

Pivoting on effectiveness

If we both know the desired outcomes we can devise simple methods to monitor the effectiveness of the resulting features at achieving the outcomes. When features prove ineffective we can alter/remove them and try other strategies.

Disciplined investment analysis

If we discuss value we can compare it to cost and make sure we're both making a wise investment decision. Without this analysis it's very easy to propose features that can lead to a marginal or negative ROI. In business it takes extreme discipline to make an investment decision. All too often I see everyone wrapped up in features and value takes a back seat. If we make this our focus, it's less likely to happen and you are more likely to see a significant ROI.

Increased investment capacity

This analysis will naturally take longer the first few times it's done. Over time everyone will become more effective and efficient and the time will be significantly reduced. The capacity to make wise investment decisions in software will be magnified!

Free investment analysis

There's ample opportunity for any company to invest in high value projects. Low value work competes for limited resources to develop high value projects. Low value work is unlikely to make you happy, at least not compared to high value work. If you demonstrate an interest in maximizing value, it means we're much more likely to have a successful business relationship and we're both much more likely to prosper. Because of this I provide this analysis process for free. When we're done you will still make the decision if we move forward. That means before I charge a penny you will already be guaranteed to get something of value!

Identify missing perspectives

When discussing value we're likely to stumble upon roles that usually aren't involved until much later, if at all. These roles often provide perspectives that can avoid sub optimal solutions before we even start. One of these roles is the buyer, the person who sets the final expectations of outcomes. Imagine how difficult it is to achieve an expectation for someone you've never met! Also, users of the resulting software are often left out. For example, if we're trying to save time or expand capacity, doesn't it seem like a good idea to involve the person that does the work now?

It's very easy to identify missing roles when we discuss value and run into questions that can't be answered.

Reduced risk

All of these benefits can be had by simply investing in an analysis of value. Once you get good at this it's often only a few hours investment per project. Is it worth the risk to skip this step?


Deliverables should not be the objective.


This is pretty common in a software development project:

We want BizTalk, .net, ruby, Nodejs, SQL Server, Sharepoint, Oracle... 


This is pretty common too:

We want a table of customers.
We want an export of invoices. 
We want a list of orders. 
We want the ability to apply discounts. 
We want a report of inventory.


This is very rare:

We want to provide more value to our customers.
We want more customers and to do that we may need to increase the frequency of doing X.
We want to increase customer satisfaction.
We want happier employees.
We want to expand Y and to do that we may need to automate Z.

When I hear this, I know I can make a difference.

Be careful what you maximize

This is my opinion:

Deliverables (ie: features, technologies, software) should be a means to an end.


If you want to maximize business value, the end should be a business objective. If you want to maximize features, technologies and software then let those be your ends.

I'd prefer to minimize features, technologies and software. They aren't cheap to maintain!


Successful software development is about creating value, not software

In my last article “Why objectives and value are important in software development” I gave examples to show that it's important to diagnose before prescribing technical solutions. But what does this entail?

Ask why

Diagnosis can be as simple as asking "why". When someone presents what, ask why. Sometimes the response is more of a what, in which case you may have to dig deeper, keep asking why! This can be like peeling the layers of an onion. At some point you find the center, the core objective.

Successful business objectives create value

Businesses exist to create value. Objectives are guiding principles to create value. For example, most businesses value profit. One objective to create profit may be to expand the customer base. Value is often intangible, for example employee morale. An objective to increase employee morale may be to pursue equitable workload distribution. Objectives are a means to the value (end). Value and objectives are numerous, focusing on them will hone the skills necessary to identify and create value, another reason to ask why.

Assess value

Eventually after peeling back enough layers, you will arrive at a rather fundamental objective.

Let's say someone asks, "Can we generate a PDF of X every night and email it to Y?" Follow up with "Absolutely, but first can we talk about what this will accomplish?" If other people are affected by or invested in the request, involve them too. Make sure to involve the person that will write the check. A typical response might be "Right now John creates this by hand and it consumes a significant amount of time." So we've identified a possible objective, saving time. Again, objectives are a means to an end, in this case it's probably about money.

Objectives often create more than one type of value. Now that you have an understanding of the objective, use it to ask further questions to assess related value. Go grab John and include him too! These are some things you may consider:

  • "How often are there mistakes because it's done by hand?"
  • ask John "Does this drain on your morale?"
  • "How much time will be saved? Over what duration?"
  • ask John "What could you accomplish if you didn't have this burden?"

Involve everyone in this exploration and expand upon what value is desired, quantifying and qualifying it as you go.

Identify investments

With a shared understanding of value, everyone can brainstorm investments in software or otherwise. These options can be analyzed to quantify the level of value they may create and the potential cost. Neither the value nor the cost can be quantified exactly in advance, that's the nature of making investments and taking risk. However, an estimate of a solution without determining if it will create value puts everyone in a much riskier situation. Assessing the value reduces risk.

With enough practice, this approach will hone your ability to make successful investments. Who wouldn't want that?

Also, I'd recommend throwing out any notion of the original request and working from the value to identify solutions. Sadly, the original request is going to bias your thinking, just try not to let it narrow your vision. There are many ways to accomplish an objective and to create value. Keep an open mind to maximize the value.

Further reducing risk with measures

With clearly identified value, the team can find ways to measure how much value is created. In the example above, find a way to measure how much time is saved, count historical mistakes, ask John how we can measure the time or if he already measures it. Measure historically if possible, starting now and going forward. Monitor how things improve (or not). Keep these metrics simple and estimate what it will cost to measure them. Make sure it's worth the investment to measure. A few good measures can help the team improve future value analysis: maybe the value was less than expected, maybe it was more, maybe there was unidentified value.

Maximizing investments

If you don't do this analysis, how can you compare one business investment to another? Some investments are more lucrative than others. Who wouldn't want to tackle the most lucrative of investments first? If you have several pending investments and you've done a value analysis of all of them, you can easily prioritize based on the value!

Since we have a more accurate measure of value and cost, we can prioritize based on ROI. Think about this: if the people who will make the investment have determined that the value they think is possible is low relative to the cost or potentially a negative ROI, why would you make that investment? Likewise, if they have identified a high ROI investment, why wouldn't that be at the top of the list of priorities?

A better approach: objectives first

Though asking why can help you start this process, it's best to start with objectives first. Goals and problems are plentiful, encourage people to track them and bring them to the team as objectives and not as requests. This will eliminate the bias in a particular solution and will eliminate the need to backtrack to the objective.


When doing business, we should assess objectives first, thoroughly ask why, and determine what value we hope to create. Identifying technical solutions should come after, along with an assessment of their value and cost. Successful software development is about creating value, not software.


Why objectives and value are important in software development

I need...

Developers get these requests all the time:

  • I need a table of X that I can sort any which way and export to Excel, can you build that?
  • or I need to generate a pdf of Y, can you build that?
  • or I want a system to reconcile Z, can you build that?
  • or I want a query to pull X, can you build that?

All of these request have a common form, a want/need for a specific technical solution.

Absolutely we can do that

Developers will typically reply absolutely, I'll get started right away! The developer will expend considerable time to fulfill the request. Upon completion, or perhaps earlier if a developer practices iterative releases, the customer realizes what they asked for won't meet their objective. It won't solve their problem or achieve their goal.

Scope creep

Naturally, the customer makes subsequent requests to tweak or replace the original request. Eventually they may arrive at a solution that meets their objective. They may also run out of time and/or money. If they are paying by the hour, the cost keeps rising. If they have a fixed bid, the developer is suffering and/or disputing the changes. Either way someone isn't happy, and that's no fun!

Self prescribing

The above scenario would be akin to being sick and choosing your own medication before going to see your doctor. Then, going to the doctor and saying "I need an antibiotic, can you give me that?" The doctor would administer the drug. Several days later you're still sick, so you go back and ask for a different medication. This repeats until you get better, but maybe you end up dead!

Or, say your hot water stops working in your bathtub. You call a plumber and inquire "I need my water heater replaced, can you do that?" They replace it and that night you still have no hot water. You call them out again and have them replace the faucet in the bathtub. That night, still no hot water!

Maybe these things happen at times, but it's not the norm.

Diagnosis first

Patients rarely will ask a doctor for a particular prescription to their ailment, and even if they do, the doctor will step back and discuss symptoms first. Same thing with a good plumber, they'll ask you why you need your water heater replaced. Either way, the professional is diagnosing the problem before prescribing a solution.

If diagnosis comes first in software development the developer can bring a variety of viable solutions to the table. Discussing objectives first can save a lot of time and money.

Why does this happen?

There are plenty of reasons, chief of which is we all like to be problem solvers. Most of us will try to diagnose our medical and plumbing problems too, we just defer to the doctor/plumber to make the final call.

I think developers encourage this too, we're avid problem solvers and we love a new challenge. Instead of listening first, we prescribe.

Sometimes solutions are repetitive, so naturally customers see patterns and offer suggestions.

Sometimes in the middle of a development effort, a suggested feature seems simple, and it may be, so why not add it?

It also happens when customers are charged by the hour. Instead of paying the developer to diagnose the problem, they can do it themselves and "save money."

Objectives first

No matter what the cause, it's clearly beneficial for developers to practice listening to the customer's objectives first. Developers should thoroughly understand the objectives before prescribing solutions. Customers need to participate by describing their objectives until everyone understands. Once the diagnosis is complete, then everyone can feel free to suggest ideas, but I would recommend deferring to the developer, they are supposed to be the expert after all.


The Value of Using ReSharper with Visual Studio

ReSharper is an absolutely fantastic complement to the Visual Studio development experience that provides immense value. It's a requisite in my day to day work with Visual Studio. In many ways ReSharper features form the basis for the criteria I use when evaluating a development environment for any platform.

ReSharper helps me reduce bugs.

Many bugs can be avoided with good automated testing up front. Testing also helps prevent recurrence of bugs. One barrier to testing is the wide variety of tools and the lack of integration with development environments. This barrier decreases the dividends testing can provide and justifiably in some cases costs more than it is worth, or at least mentally seems to.

ReSharper lowers this barrier by providing integration of a consistent test runner. Out of the box it supports NUnit (one of the oldest .net testing packages) and MSTest from Microsoft. Plugins can provide coverage for other frameworks. Recently ReSharper even added support for testing JavaScript via QUnit and Jasmine frameworks! The testing tools are one of my absolute favorite features. I can run a test or set of tests with a keystroke and get results in an integrated, visually appealing test runner. Running tests with this level of granularity and integration is a very rare feature in testing platforms. It allows me to thoroughly test components before assembling and testing the entire product.

If I have a bug in existing code, features like Stack Trace Explorer make it easy to track down and identify the issue.

Lowering the barrier to testing makes automated testing more economical versus manual verification. At the end of the day I can work faster and the resulting product is more reliable. In my opinion, this testing integration alone covers the cost of the license. I save at least 2 hours a week using automated testing with ReSharper over F5 debugging. It also leads to at least one less production bug a month and gives me immense confidence in what I do allowing me to work even faster.

ReSharper helps me maintain code and avoid "re-writes"

Poorly maintained code is difficult to change, difficult to understand and in some cases difficult to read! This is often referred to as spaghetti code. These design problems lead to stagnant progress evolving a software product to the ever changing demands of business. Writing, understanding, maintaining and evolving software is hard work and is often tedious.

ReSharper reduces repetitive and tedious tasks evolving code by providing a plethora of automated refactorings. It's challenging enough to decide WHAT refactoring to apply, let alone to carry it out. Most beneficial refactorings can be automated and ReSharper does just that with integration and shortcut keys! Having these tools available at a keystroke means I don't wait to change code that is troublesome. ReSharper allows me to avoid the need for a "re-write" by continuously evolving the code to meet the needs of business. Paired with easy automated testing and I have confidence that my refactorings aren't introducing bugs!

Maintainable code means I don't have to worry about re-writes, ReSharper can even help tackle the worst of spaghetti code and evolve it to something more maintainable over time. The costs and risks in a "re-write" are phenomenal. Day to day refactorings save me at least an hour every week manually refactoring my code and it expands my ability to do so. Continuous refactoring also reduces the likelihood of a delay from code that is difficult to change.

ReSharper helps keep my code consistently formatted

Style preferences aside, most developers agree consistency is a good idea. Each project often has a particular style that is an artifact of the time it was created in. Often there's no reason to change the style, but it can be extremely difficult to enforce it when I adopt new styles.

ReSharper allows me to setup shared settings for multiple machines or when I work on teams. They are applied hierarchically so I can have whatever level of consistency I desire. These settings allow decisions in the past to be enforced via simple Code Cleanup commands and don't require me to spend time worrying if I am following consistent rules for any particular project. Instead, I can focus on the content and get consistency for free!

I save at least 30 minutes each day, I know this because I use the silent cleanup ctrl+e,f immediately followed by ctrl+s and find myself doing it in applications that don't support it :) If I stumble on code that is inconsistent, I setup rules and apply cleanup as needed to get a better idea of what it does.

ReSharper helps me comprehend code faster

As systems grow, so does the code behind them. This can become difficult to organize and even more important to navigate. Folders and projects only go so far and the Solution Explorer is a very crude way to get where you need to go, it's not very keyboard friendly! I spend a significant amount of my time reading code, so having a barrier to navigation is extremely unproductive.

ReSharper provides a bevy of features to ease navigation. A single Navigate To shortcut with contextual support can get me where I am going quickly. The Go to Type, Go to File and other Go to features make searching and jumping to any place in code lightning fast. ReSharper even supports integrated decompilation and navigation with dotPeek. Paired with refactoring and testing, superb navigation further allows me to evolve and comprehend code.

ReSharper also makes identifying unused code with solution analysis a simple task and helps remove it with Safe Delete. Unused code just leads to confusion and begets more unused code!

Every day I navigate to different places in my code 100s of times, ReSharper provides features that shave multiple seconds off each navigation, the amount of time is incomprehensible, at least 30 minutes every day, and that's only estimating about 4 seconds saved per navigation, it takes longer than that to do anything with the solution explorer and a mouse.

ReSharper helps me type less

Even the best of languages can be verbose, C# is not immune and wow is all I can say about Visual Basic. Why should I spend time typing syntax when I could be focused on content?

ReSharper provides many completions to make writing code less burdensome. It also supports several levels of templating and generation to reuse common patterns. These templates are customizable and can be shared with other team members with ease. One of my favorite templates is a test method snippet. When I want to add a test I don't have to type the scaffolding, I can focus on the content. I write more fine grained tests because of this which increases maintainability of my tests! I also thoroughly enjoy code generation of method declarations so I can focus on what the method does!

Less typing saves me even more time every day, at least an hour a day versus manually typing everything out, the biggest savings is in avoiding compilation and other mistakes that shift my focus from content.


Of the above, which are by no means comprehensive of the value I get out of ReSharper, I've enumerated a savings of at least 13 hours per week. That's time I re-invest in content instead of tedium. This is likely a conservative estimate as I feel my productivity is more than doubled with ReSharper.

If you are a developer, what would these savings mean to you? If you fund development teams in your company, what would these savings mean for your company?