Speeding up time to market for software development projects

In order to meet the ever expanding needs of business, technologists need to shorten their delivery times.  This is no less true in software development projects.  Perhaps I’m looking in the wrong places, but I’m seeing a lot more articles on the need than ways to meet that need.  So here are some things that you can start doing today to start delivering business value to your users in a timelier manner:

Understand the end user

You may find it strange that my first point about delivering software more quickly is to add more work to the development team.  However, a significant cause of time and cost overruns in software projects is the constant need to implement desired features without understanding the underlying needs.  If you understand the wants and needs of the end user before you start, you will be able to design a better software system the first time, significantly reducing the need for costly rework.

Right-size the development team

Don’t assume that adding more people to the development team will proportionally decrease the time-to-market of the software product.  When a team grows from one to two people, you double the number of people needing to understand the requirements; you double the number of people needing to know about changes, you increase communication issues due to the development team needing to understand each other’s code, the need for project management increases, etc.  Smaller teams are more agile, so keep teams as small as reasonable to achieve the desired results in a timely manner.

Right-size the development effort

Larger projects require disproportionally more effort to keep the code base easily maintainable.  If you do not make the effort to keep the code base clean on large projects (if your team is made up of unskilled developers), the result will be a tangled mess that can will always be too buggy to be shown to an end user.  Conversely, if you build your small project as if it could scale to easily handle a team of tens of developers and millions of users, you are certainly wasting time and money fixing unneeded scalability concerns.

When in doubt, start simple

Complex features lead to a disproportionate amount of effort, both in clarifying the business requirement and in creating an appropriate solution.  If the complex solution is the appropriate one for the situation, then put it in, you’ll save time later.  If not, put in the simplest solution that minimally meets the business requirements.  If your solution is complex, it is likely a sign that something is not understood (and it could be misunderstood by the development team, the business stakeholders, the end user, or any combination of the above).  If you don’t understand it, then it will change later.  Save time and money now, and change based on feedback if need be.

Use development tools whenever possible

I’m a big fan of using development tools, whether they are libraries such as JQuery, frameworks such as NHibernate or CSLA, or a hand-rolled tool like a JavaScript generator I made a couple of years ago.  These tools are often made by developers, for developers, and speed up development time considerably.  Many good developers out there disdain these tools because they are inefficient and inelegant, but the minor losses in elegance and execution efficiency are more than made up by the gain in ROI.  These developers need to remember that their job is to deliver working software as efficiently as possible, not deliver the cleanest code base possible.

Be careful in choosing third-party frameworks/plugins

And by third-party tools, I’m thinking of CMS systems, eCommerce systems, or user-interface control libraries.  Essentially, be wary of anything that promises full features out of the box.  These tools are great if and only if you are planning to use features exactly as they’re intended to be used.  Modifying these systems is often more trouble than it’s worth.  Most of the time, these tools are crammed with mostly-functioning features, rather than focusing on providing a few completely functioning ones.  The costs updating and maintaining features built with these tools can easily surpass the costs of creating and maintaining the same functionality built from scratch.  I’m not saying that you should avoid these tools, I’m just saying that you need to think twice before trying to bend them to do something that they weren’t explicitly designed to do.

Push your boundaries a little bit each project

Technologies available to create applications faster, better, more reliably, etc., are being created every day.  It can seem overwhelming at times to see how many new tools are available to evaluate.  I can’t speak for all developers, but I can’t get a good sense for what a technology is and is not good for without starting using it in a live-fire situation.  Starting a new project depending on entirely new tools is a recipe for disaster, but starting a new project with no new tools is a recipe for obsolescence.  Each software project you encounter, try something new.  Keep the scope small to keep the risk down, but keep the effort meaningful.  By constantly evaluating new techniques, you are putting yourself in a position to deliver greater value in the future.

ASP.NET WebForms vs. ASP.NET MVC

When .NET came out in the early 2000s, Microsoft replaced Active Server Pages with ASP.NET WebForms.  That was the preferred approach to web development in the Microsoft world until recently, when ASP.NET MVC came out.  (Silverlight is also an option, but I view that as a way to beautify an existing site, not act as the foundation for one.)  There is a lot of material out there that describes the difference between these platforms, but almost none of it is targeted for the high level business executive in technology, such as the CTO.  So here is my attempt at outlining the differences without getting into too much technical jargon:

ASP.NET WebForms

WebForms are by far the oldest technology in the Microsoft web stack still actively used today.  (No, I wouldn't consider ASP as still actively being used today.)  The framework was originally created to help WinForms developers write programs for the web without needing to learn about some of the peculiarities of web development.  While Microsoft cannot hide from these peculiarities completely, the framework made some tasks a lot easier.  Unfortunately, in order to make this happen, the creators of ASP.NET WebForms needed to send a lot of information to the browser, leading to potentially very large (therefore slow) pages as well as making highly interactive web sites more difficult.

ASP.NET MVC

Programmers eventually found some of the tools that WebForms provided cumbersome and awkward, so Microsoft came out with a leaner framework in the form of ASP.NET MVC.  The benefits were that MVC makes it easier to write JavaScript, saving trips to the server and improving the overall user experience.  The drawback is that the MVC developer needs to do some of the work that WebForms would do automatically.

Which one is better?  That, of course, depends on your circumstances.  Here are some pros and cons:

WebForms pros

• Good for getting something up and running quickly
• Easy to understand for WinForms developers
• Even in the hands of someone only marginally competent, code can still be understandable
• Relatively easy to create pages with a lot of functionality without making the HTML too confusing for the developers

WebForms cons

• A lot of HTML gets generated that slows down the browser and gets in the way of AJAX requests
• A lot of code in inaccessible code-behinds can lead to more testing through the UI than should otherwise be necessary
• Steep learning curve for those coming from other web programming languages

MVC pros

• Clean HTML means faster load times and easier JavaScript/AJAX
• More unit testable
• Shallow learning curve for those coming from PHP or Ruby On Rails
• Cleaner HTML leads to cleaner CSS
• More easily integrates with third-party JavaScript and CSS tools

MVC cons

• Can lead to unreadable code more easily than WebForms
• Pages with complex functionality will have complex HTML for the developers
• More tools/blogs/help available that focus on WebForms

In short, developer skill level aside, if you’re creating a highly-interactive site, MVC is the more natural tool.  If you’re creating a site with a lot of functionality on each page, WebForms is the more natural tool.  When in doubt, go with the tool that you or your developers are most comfortable with, unless you’re deliberately evaluating the other option.  There is nothing you can do in one format and not the other; there are just some things that are easier in one format or the other.  I personally prefer to work in MVC because of the cleanliness of the code that’s generated, but my bias is that I prefer to make my sites highly-interactive.

The difference between good code and good software

I’ve heard a lot of people speak and read a lot of blogs about how to write code.  Surprisingly, very few of these involved discussions on how to create better software.  And no, writing good code (or even great code) does not necessarily result in good software.  To see why, here are some characteristics of good code:

• Easy to read and understand
• Easy to maintain
• Appropriately unit tested
• Performs reasonably quickly – no tangled logic that slows the application down
• Errors are few, but easily fixed when found

To contrast, here are some characteristics of good software:

• Intuitive, easy to use with little to no training
• Meets all of the needs of the user (within reason), no work-arounds needed
• Performs reasonably quickly
• Errors are few, but easily understood when found

If I as a developer want to learn how to write code in a better way, I could find books, user groups, or blogs pretty easily in order to do that.  But better code doesn’t result in a better user interface, nor does it directly result in a better user experience.  You might be thinking that developers write the code and designers design the interface, solving the problem of developers not knowing how to design.  As a consultant, I’ve worked on my share of applications to know that designers don’t get involved nearly as often as they should be.  When they are involved, they too often do not know the actual needs of the end user, and instead focus on making the system look good and work well for his/her co-workers.

In summary, a primary criterion for determining the quality of code is whether the developer can understand it.  This criterion is easy to understand, since most developers are trained to look for it.  The primary criterion for determining the quality of the software is whether the end user can understand it.  This is much harder to understand, because all too often software is written with business stakeholder and developer/designer input without the feedback of the end user.  Yet all too often developers assume that if you write good code, good software will follow.  It's about time that we start recognizing the difference.  If we as developers start putting as much effort into creating better software as we do in creating better code, life for everyone involved will become significantly better.

Object Relational Mappers - Time Saver or Programming Hack?

If you have anything to do with development, you have probably heard about “Object Relational Mappers”, or ORMs before.  There is a lot of information available on what they are, but most are overly technical, not objective, or both.  So for those of you who aren’t directly involved in writing code, here’s my attempt at describing the purpose and use of ORMs.

ORMs are essentially tools to allow developers to map information in a database to classes in the business logic layer with a relatively small amount of effort.  The productivity gains can be significant, since some ORMs help the developer create objects, data access code, and update code easily after a database change.  From a developer’s perspective, ORMs can be handy because they can effectively translate between the tabular database storage model to “objects” that exist in code.

Despite their uses, ORMs have a lot of detractors within the programming community, especially with some of the more skilled open source developers.  Actual complaints vary, but the gist of their arguments is that these tools don’t generate objects or data access code that operate as efficiently as can be.  The code generated does not meet their standards of quality, and therefore they argue ORMs should be shunned.

Since most developers do not have unlimited time, I’d suggest using some sort of ORM whenever practical.  The productivity gains will far outweigh performance hits for the vast majority of situations.  I would agree strongly that ORMs do not generate the most elegant code, but that is a necessary trade-off that needs to be made to get useful functionality.  Remember, just because something does not meet your internal standards for quality doesn’t mean that it isn’t good enough for the customer.  Finally, don’t be afraid to look at different ORMs.  Choosing the wrong ORM can cause problems for the developer and increase costs in the long run.  Choose the right one (or at least an adequate one), though, and your productivity (or your developer’s productivity) should increase significantly.

Things instrument repairmen do better than software developers

As most of my readers know, I started my career as a software developer as a career change from repairing band instruments.  I generally liked fixing instruments, but I eventually decided that it wasn’t for me.  But because I didn’t start my career writing software, much of my outlook on software development is rooted in the way I approached repairing instruments.  There are some noticeable differences between the development and instrument repair mindsets, so I thought it would be interesting to come up with a list of things that the average repair person does better than the average software developer.  I came up with five, in no particular order:

Right tool for the right job

As a repairman, I learned early on that not all tools work equally well in all situations.  Methods for removing dents in tubas would pretty much destroy a trumpet.  Methods for padding a saxophone wouldn’t work at all on an oboe.  I had one type of glue for saxophones, another for clarinets, and still another for oboes.  There are numerous types of hammers to take dents out of trumpets.  We did this not only because the right tool saves time and money, but also because the wrong tool could literally do more harm than good.

On the other hand, many developers don’t seem to have many “tools” in their toolbelt.  They become experts in a particular technology, and then use that technology to solve all their problems.  They’ll bend that technology to do things it was never meant to do just in the name of staying within one platform.  Languages and platforms try to cater to everyone, rather than try to focus on a particular type of problem.  Instead, more technology professionals should focus on the types of problems they want to solve, rather than the types of technology they want to use.

Know when to stop

Most instrument repair personnel are very keenly aware of the budget of their customer.  In most cases, repairs are done on instruments done by musicians/schools with small budgets or on instruments for young students.  In neither case does the customer want to pay a lot of money for the repair person to get it right.  Instead, the repair person is responsible for determining which repairs are worth the money to do.

On the other hand, many developers try to create the best solution possible, regardless of need.  While I understand this point of view, we as technologists need to start keeping costs appropriate to the problem at hand.  There are times when making sure that the application never fails, moves almost instantaneously, and is built to withstand thousands of concurrent users is appropriate.  There are times where one or more of those is not.

Interviewing

When I was first getting into the repair business, my wife (then fiancée) was applying to several graduate schools, so I had no idea which part of the country I’d end up in.  So I took as many interviews in each of our possible landing spots as I could.  I noticed a remarkable difference in quality of the interviews – some were clearly thought out, while others were clearly unplanned.  What they all had in common, though, was that I repaired something for each of them.  There was never a question of whether they would check to see if I could repair something before hiring me; the only question was which repairs were most indicative of my general skill level.

On the other hand, I find it shocking how few technologists think of asking potential candidates to write some code during a job interview.  With laptops and networks readily available, it would be easy for any company to administer a quick one hour programming exercise to any candidate.  Yet most interviews I’ve been on involved talking about programming, maybe even a whiteboard exercise or two, but very little actual programming work.  This makes it much harder to determine if a potential programming candidate is up to the job.

Know the customer

In order to find what repairs are appropriate for a customer’s goals and budget, a repair person needs an understanding of what those goals and budget are.  In order to do that, most reasonably good repair people will spend several minutes with a customer, asking what their problems are and looking at their instrument, before going over options with that customer.  Having several of these interactions a day allow repair people to become very good at eliciting the short- and long-term needs from their customer.

Software developers, on the other hand, tend more to writing code based on what they, not the customer, think is right or appropriate for a given situation.  This isn’t entirely the developer’s fault; I’ve certainly had clients who were not interested in having a detailed discussion of different approaches in the development process, so I was forced to guess.  I do think that experiences like these cause software development teams to focus on delivering what they think is best unless the customer explicitly says they want to be involved; but the reverse should be true.

Find creative solutions to problems

Until recently, there were very few vendors out there who provided a wide variety of tools appropriate for repairing band instruments.  Even now, individual repairs quite frequently defy the tools that can be bought.  Repairs still need to be done, though, even if there isn’t a tool out there perfect for the job.  Repair professionals, therefore, must be good at creating their own tools.  I mean that literally.  It’s not uncommon for repair shops to have raw steel, brass, and lathes available for the primary purpose of making tools when an appropriate one isn’t available to purchase.

Developers, on the other hand, are much less likely to make their own “tools”.  Instead of trying to determine how best to fix the problem, and then building software to do that, developers more often than not hand-code the solution.  Tools can easily be made to simplify development tasks.  I’ve personally built a JavaScript generator that would create copies of script that could easily be debugged locally, but could be loaded quickly in production.  I’ve used code generators that built abstraction layers over databases simplifying data access and architecture.  We need more of this ingenuity in software development, especially in the Microsoft community.

A few final notes

By reading this blog, you may think that I’m trying to put band instrument repair on a pedestal.  Keep in mind that my goal here is not to compare the two careers, but instead is to tell software development teams of approaches to work and customer interaction that works well in other industries.  There are certainly things that the average developer does more naturally that the average band instrument repair professional, but that’s out-of-scope for today’s blog.  And no, I don’t regret the career change; I find solving business problems using technology a very rewarding career in more ways than one.

Why more technologists need to know marketing

I have to admit: before I got my MBA I had very little respect for Marketing as a profession.  I thought of Marketing as a combination of Advertising and Sales, and I didn’t have much respect for either.  I thought the result of Advertising was to inundate us with commercials and magazine ads that did little to entertain and even less to sell a product.  I thought of the Sales process as the attempt to ram as many products/features down a customer’s throat as possible, without regard to that customer’s needs or wants.  My MBA studies taught me that Marketing should be so much more.  I still think of Sales and Advertising done poorly as described above (though I do have respect for Sales and Advertising done well), but what I overlooked was that it is Marketing’s job to understand the customer.

This is important to point out because technologists, as a whole, know little about how to delve into the mind of the end-user/customer.  One result is that during the requirements gathering process for new software projects, I see a lot of implementation teams create a solution that matches as close as possible what the business stakeholder asks for.   The questions during this process are not "what problems are we trying to solve?", but instead are "with what technology should we implement this functionality?".  To illustrate what the differences are between these two approaches, here is a quote from Henry Ford:

If I'd asked customers what they wanted, they would have said "a faster horse".

Ford’s customers wanted easy transportation, and were used to horses.   They couldn’t conceive of transportation solutions other than horses (or wagons drawn by horses, oxen, etc.).  Instead of going to his customers and allowing himself to remain within their experience, he met their underlying needs with a novel and unexpected solution (affordable automobiles).

How does this apply to software development?  Here are some examples of common development efforts and how they commonly don’t match the user’s needs:

• Designing a form for data entry needs to be user specific.  I can say from personal experience that different users want different things in their user interface.  A form that would work for a typical engineer would be downright confusing to a typical retiree, and something a retiree would like would be cumbersome to a typical software developer.  Software developers and designers need to start being more sensitive to these differences.
• Upgrading an application from a legacy technology to a newer one should involve a redesign.  Most legacy systems have been “organically grown”, which is a euphemism for “when stuff is added, it is put wherever there’s space”.  (Yes, I’ve been on all sides of that situation.)  Business stakeholders in this situation usually ask for a strict move to the new technology, since that saves time and money in the short run.  But as long as you’re rebuilding, why not redesign the application in a way that best meets your user’s needs?
• The technologies or platforms used for a particular project are often chosen based on product familiarity rather than user’s needs.  The best example I can come up with for this is that I read somewhere (and I wish I remember where) that if you’re trying to target teenagers, you’ll get a wider audience by creating a Facebook site than a traditional web site using a Content Management System.  Yet how many of you, when tasked with creating a site for a company that caters to teenagers, would think “CMS” first before even thinking “Facebook”?

The bottom line is that in order for software developers to create better applications, we need a better understanding of marketing.   If that doesn’t convince you, consider this.  Of the five trends in IT for the next half decade, three (Social Computing, Mobile Computing, and the Consumerization of IT) are all directly related to Marketing.  The need for more marketing in technology is here, so it’s time to get on board.

Project Risk and Fixed Bid vs. Time and Materials

When I was getting my MBA, I read that by outsourcing projects under a fixed-bid basis, you (as a company hiring an outside firm) are lowering your risk in the project.  This is true, if you believe that your primary concerns in the completion of your project are whether it is completed on time and on budget.  Your primary goal should be delivering business value, not meeting a budget.  (Yes, I understand that budgets are important.  Keep in mind that a budget should only be a means for planning resources and comparing ROI and meeting a budget does not guarantee that you receive business value.)  By choosing a fixed bid route, you are actually increasing your risk of not delivering business value.  It’s not hard to see why, if you look at the process from the point of view of both the business and the implementation team.

When a project is on fixed bid, the implementation team is incented to keep the scope as small as possible.  This obviously makes it more difficult to make changes if one or both sides feel that the change alters scope.  My experience has been that scope request changes on fixed bid projects result in hurt feelings on one or both sides, doing little to build a feeling of teamwork between the parties involved.  This results in significant push-back when scope changes, even necessary ones, are requested.  When a project is billed on a time and materials basis, the implementation team is more willing to change scope because the focus becomes on meeting the business stakeholders’ wishes rather than avoiding losing money.  (There is a risk that your implementation team will be less efficient when they are billing on time and materials, but if they are concerned about building a good reputation and earning your repeat business, believe me, they will do what they can to deliver your functionality in a timely and efficient manner.)

On the other side, it follows that the business has more control over the project when it is being billed on a time and materials basis.  In this case, it is the business that has the financial risk; therefore it has the right to control the scope and delivery of the project.  Lastly, by running a project on a time and materials basis, the stakeholders are forced to determine which features are important to them, and which ones are merely nice-to-haves.  The reason should be obvious: when on fixed bid, the goal of the business team is to get as much value for their money as possible.  However, cramming as many features as possible into the implementation doesn’t necessarily result in a better product.  Having to pay for each feature individually really allows the business team to focus on what’s really important.

I am not trying to argue that projects billed using time and materials have less risk than fixed bid.  Overall, it is important to point out that one approach does not have more risks than the other, but each has its own risks which should not be ignored.  In the end, choose the approach that works best for you, your team, and your outsourcer, but don’t assume that fixed bid is best just because it appears to have low risk on the surface.

The dangers of gold plating

The term “Gold Plating” (when not actually referring to covering something with a thin layer of gold) comes from Lean manufacturing, essentially referring to the process of creating a part better than what its specifications require.  Applied to software development, it means putting more effort into a particular component of the software that is not needed, such as an added feature, making a needed feature unnecessarily complex, or unnecessarily fixing performance issues.  There are numerous reasons why a particular developer might choose to gold plate a certain feature, but some of the more common are:

• Desire to meet a self-directed (and situation-agnostic) sense of quality
• Desire to avoid getting angry phone calls due to an application crash caused by rare circumstances
• Lack of understanding of what the end user actually needs

I’ve written about what happens when a developer has a misaligned sense of quality in software in a previous post.  It should be enough to say, though, that those involved in creating software need to start defining quality as lowering the cost per needed feature, not creating the best code base and/or user experience possible.  If a particular feature is needed, then great, by all means do it.  Nobody likes making or using mediocre software.  There are certainly cases when that extra effort pays off in the long run.  Just be sure that you are putting this extra effort in because the user needs it, not because the software team wants it.

I certainly can sympathize with the desire to avoid an angry phone call with a user due to something the application is or is not doing.  Bubble-wrapping the application is not the answer, though, for a variety of reasons.  In this case, the software architects and the business stakeholders need to have a frank conversation about what risks are acceptable and which ones are not.  The risk tolerance should change based on the type of application involved.  For example, a software team should be much more careful about making sure that every possibility is covered in creating an emergency responder system for a building vs. creating a social site for a non-critical internal app.

Finally, a lot of gold plating occurs because the software team genuinely thinks that a user would want that particular feature.  However, most people I know (including me) do a very poor job of understanding what it is a user wants without asking.  To do a good job of understanding the end-users needs, the development team must go to the end user and understand what it is they are trying to accomplish.  Once you understand their goals, then and only then can you start making educated guesses as to which features are needed and which ones are gold plating.

If none of that convinces you, remember that 40% of software features go unused according to a not-so-recent Gartner study.  Not only does adding these features add to the application the first time add to the costs of developing the product, but the presence of these features adds to the cost of extending and maintaining the product.  If you are able to stick only to the features that are needed, you will be able to reduce costs, increase ROI, and lower your headaches in product maintenance.

Can technical project managers be effective without hands-on development experience?

If I were to come up with an ideal set of skills for a project manager, it would include the following, in order of importance:

1. Ability to create a full project plan
   1. Determining the critical path
   2. Determining which resources are appropriate for available tasks
   3. Planning the project execution timeline
   4. Creating milestones
2. Tracking project status
   1. Determining what action is appropriate in the event of a time or budget slip
   2. Making sure that action is taken and that it has the desired results
   3. Determining the cause of a time or budget slip
3. Ensuring that everyone involved in the project has what they need to move forward
   1. If not, removing obstacles/provide needed information

These are necessary items to occur in any non-trivial project. However, between hearing developers speak at user groups, hearing developers talk about project managers at other companies, reading blogs about project experiences, etc., I’ve come to believe that too many project managers out there reactively track status by asking the team for periodic status updates, and do little more. This approach is an issue because:

1. Critical path planning gets done poorly, when it is done at all
2. Poorly done critical path planning means resources aren’t added when they are needed
3. Asking the team for a status only works when the team is both qualified and aware of all the tasks that need to be done
4. Problems are never prevented because they are never seen until it is too late

However, without intimate knowledge of the software development process, identifying and fixing issues before they affect time or budget is difficult. This can be true for project managers who have knowledge of project management techniques, but lack the specific technology and/or business domain knowledge. But because of the expectations I outlined at the outset of this blog post, project managers are very often the ones held most responsible for the success or failure of a project. I cannot think of a greater disconnect between expectations and ability to meet them for any position.

I can’t think of an easy fix for this, though. Making sure that all software project managers had hands-on experience in software development might be a solution. That isn’t going to happen any time soon, in no small part because the skills necessary for being a good project manager are quite different than the skills necessary to be a good developer. I’d guess that most project managers would not like hands-on development, and that most developers would not like hands-on project management. Moving to a Scrum environment might be an option too, where the development team takes over the status tracking and the business stakeholders determine scope, but that makes it harder to budget resources on the enterprise level. Does anyone have experiences they'd like to share of techniques that did or did not work particularly well?

How IT is not aligned with business

One of the hot topics on IT related web sites lately is aligning business and technology goals.  While I think there are plenty of things business people can do to get more out of their technology (and that could be an entire discussion on its own), I’d like to focus on what technologists can do bring more business focus to their jobs in this post.

Most technologists I’ve spoken to believe quite strongly that they understand business and have what it takes to design business applications, yet most of them fail in doing so.  Here are some examples:

What’s the best way to develop a mobile application?  Web, native application hand-written for each environment (Android, iPhone, Blackberry, etc.), or a third-party solution that creates custom apps for each environment?

That was a question I had overheard at a user-group meeting describing the strengths and weaknesses of different third-party solutions.  Why does this developer think he’s business-focused?  Implicit in his question about what is the best way to get information to users of mobile devices; he is thinking about the balance between time-to-market (and therefore development costs) and creating a smooth, understandable interface for his users.  Where he needs to improve is that he fails to understand that the appropriate technology used will depend on the circumstances.  When time and budget is the primary issue, going with the easier-to-produce web site built for mobile apps is likely solution.  When impressing your customers or creating the most intuitive interface is needed, creating native mobile apps for each platform used is probably the way to go.  In all other cases, you have to determine the best approach that best balances the needs of your users with your budget.

Which is better, ASP.NET WebForms or ASP.NET MVC?

This was a real discussion I had with two very good technologists.  One argued that WebForms was the better technology because it had all sorts of inclusions increasing developer productivity.  The other suggested that MVC was the better technology because it resulted in cleaner HTML, and therefore you could write highly-interactive websites with it more easily.  Implicit in each argument was the business need: the WebForms guy was thinking about cost per feature, the MVC guy was thinking about creating websites with the “wow” factor with the lowest possible cost.  Here again neither technologist thought that the appropriate technology for a situation would change on the situation.

Do you have any SharePoint needs?  Do you need help with reporting?

One time I was on a sales call and the salesman asked these questions, pretty much in these words.  From a sales standpoint for a consulting organization, these questions make sense because they’re easy for us to fill.  Do you have any SharePoint needs?  If so, great!  I have a SharePoint developer right here ready for you….  Unfortunately for sales people, business problems usually aren’t so straightforward that you can just drop a piece of technology into the business and reasonably expect problems to be solved.  Instead, we as technologists should be looking at the underlying business problems first.  For example, instead of asking “Do you need help with reporting?”, ask “Do you feel that the information you are getting is sufficient for your decision making?”  Then you can start a conversation about what the problem actually is.  Is the business having problems interpreting information they already have?  Is the business having problems storing and digesting the information that they are getting?  Is the business having problems gathering the information they need in the first place?  All of these problems can be solved with technology, but reporting will not always be the solution.

To start solving this problem, we as technologists should start with the following:

• Understand the business problem first before trying to create a solution.  As in the example above, insufficient knowledge cannot always be solved with reporting.
• Explicitly state and agree on acceptable risk (downtime, security, errors) and associated costs.  Most developers I know have their own risk tolerance, but rarely actively think about it, much less communicate it effectively.
• Remember that your job is to solve a business problem, not implement a specific technology.  Just because a particular solution is easier to implement or cooler to create, doesn’t mean that it is appropriate for the circumstances.

Obviously following these three steps will be insufficient to bridge the gap between business and IT, but if we all could do it, it would at least be a start.  Keep watching the blog, as I’m planning a post about what training might be appropriate for technologists. 

Why I don't think of myself as an ASP.NET developer

I’ve been asked by several people recently whether I’m interested in being a mobile application (or SharePoint, database, Silverlight, etc.) developer.  I’ve never really liked that question, but I didn’t understand until recently why I didn’t.  The problem is that question assumes that I’m going to be focused on a particular technology, but really IT professionals should be focusing on being experts on solving particular business problems.  Let me explain.  Programming is programming, whether you’re programming for the web, desktop, mobile, firmware, whatever.  The languages differ, some of the particular problems differ, but if the developer is reasonably knowledgeable and dedicated to learning, they should be able to pick up new skills specific to a new platform relatively easily (especially with the number of technical bloggers out there).  So while the knowledge of a particular technology, such as mobile application development on a particular platform, is useful, it’s not the most useful way of determining expertise.

Instead, we need more technology professionals who focus on a certain business need.  Such business needs might include external marketing, finance, or competitive research.  To be especially efficient, such a technologist may choose to focus further on a particular industry.  For example, an external marketing specialist may know how to lead conversations to learn what user interface is appropriate for a public-facing app, and be able to design something that both delights the user and is technologically feasible.  A finance specialist may know accounting and finance rules, but also would be extremely fluent in programming languages and platforms that best fit financial applications.  In other words, such a specialist would be equally knowledgeable of the technology they are using as well as the business function they are serving.

While people like this exist, if technologists wish to be partners in shaping business strategy, we need significantly more.  Having more technology people value MBAs would be a good start, but by no means would be a cure-all.  So my question is, how should technologists go about getting the business knowledge necessary to move outside pure technology?