A common dilemma of many tech managers and businesses in general is when presented with a business problem, do you build your own software or do you buy? For some companies, this is an easy answer. Some development teams are not equipped with the skills to build a particular tool or product. Other companies just do not have any budget available for the product needed, but do have ample resources to work on development. But for the teams and situations that fall in that middle or gray area, what do you do?

So, how do you decide to build or buy? Through my experiences I have compiled a short list of questions you need to ask yourself as a technology manager.

1. Do I have a budget to buy this product? – If not, the answer has been made for you. You will need to build a product that does the task, or at least can hold you off until there are available funds for purchase. Beware of the trap of building a ‘good enough’ product that then stays long past its shelf life.
2. Can my team build this? – This question has a couple of things to consider. Does your team have the skillets to build the product. Development teams have roles, and sometimes its obvious. For example a web team that builds games is just not going to build a billing system for you. Second, do you have the available resources and time? You may have the talent, but will you be able to set aside the right talent for the time required? They may be needed elsewhere.
3. Does developing in house cost me in other ways? – Once again this speaks to your talent base. Maybe you can put a developer on this application for the time required, but are you missing out on future development opportunities? Is this project so far from their original skills and desires that you will diminish team morale? Less tangible than cost, these are still important to consider.
4. Will the commercial software suit my needs? – My experience has been that many products have a set fee, but then you need to factor in the additional cost of customizations or additions that will suit your business needs. Or you think you can get away with a basic implementation, but soon need to upgrade, incurring additional costs. Or if you are paying for a subscription model, there may come a time when this may not be cost effective anymore.
5. What will the cost be to build? – Again there are a couple of things to look at here. First, how many development hours will a project take? To get a good assessment, you need to be skilled at creating project estimates. If done incorrectly you can end up in a losing proposition. Ask yourself, does your company have a history of feature creep? If so, this project will inevitably take much longer than originally thought. Finally, what is your possible productivity loss? Does putting 2 developers on a six month project keep you from developing a new tool that can be monetized? As Opportunity costs are just as important as accounting cost.
6. Could this be outsourced? – Sometimes the solution is not to build in house, or buy, but rather to have a custom application developed for you. It has been my direct experience that a lot of outsourced code, while possibly cheaper initially has cost more to grow over time. Digging through lines of code to fix bugs or to add a feature ends up wasting a lot of time. If you expect the contracting company to support the product, make sure they have been around awhile, and that you feel confident they will be there in the future. Also make sure their business model allows for incremental updates and support. Many consulting teams work on building and deploying full tools, and are not interested incremental additions.

I have to admit with the increased amount of opensource code in the community and advanced APIs to work with, I tend to build. We can usually find a good opensource product, edit and grow it for our needs, and save a lot of time and headaches. Or we buy a small commercial component that takes care of some aspect of the tool that we could/should not build, then build around that component.

Do you have similar issues? How do you decide whether to build or buy? Maybe you made a decision and wish you had chosen the other? Did I miss a major point in my decision process? I’d love to hear from you. Join the discussion in the comments. We should all learn from each others experiences.

image by msmail

Related posts:

1. Keep Teams Lean Developing effectively starts with the team. Of course projects requirements,...
2. Web Development is a Creative Career Web developers are different breed of technologists. We are increasingly...
3. transparent background Let me give you a little information about where I...

Related posts brought to you by Yet Another Related Posts Plugin.

All good developers need time to decompress. This ability to decompress comes in 2 basic flavors.

The first obvious method would be getting away from the mundane routine of coding. This form of decompression is common to most jobs. Developers like anyone else can benefit from some time away. This can come in small doses, like 20 minutes of web browsing here and there, or in longer form, like a vacation. A lot of developers are able to decompress by surfing the web. This is because the web is a passion for us. Even though we may be are on YouTube watching a video clip, we are also taking in subtle ideas about all the sites we are visiting. “Does this site implement comments in a unique way?” “Would it work for us?” We notice features, navigation choices, GUI elements and are constantly tucking them away into our mental toolbox.

When we find ourselves working on a project where we may be able to implement an earlier idea we saw, we try it. Developers enjoy being creative and applying new concepts and ideas to our work, no matter what the project.

The second way most web developers decompress will come as a bigger surprise to non-technical managers. As I mentioned, web developers are passionate about their trade, and a good developer enjoys working on new ideas. This may mean working on something we have not been assigned to, or re-tweaking code that was written a while ago. Even writing code for personal sites. Google embraces this notion and encourages their employees to use 20% of their workweek for side projects. And it has paid off for Google. Many features you use in Gmail, and Google Calendar each day came from developers own R&D time, and not through committee or assignment. While this may seem like more work, or a distraction to others, this is a huge perk for developers, and results in increased productivity and creativity.

Just like a writer, developers can get a creative block, and need time to step back and come at the problem with a different mindset. Its that creativity that will help your site or application in the long term. If you allow your developers to decompress and in turn build their knowledge base, they will have the clear mind, creativity and skills to tackle their regular projects more efficiently.

photo by Subnet24

Related posts:

1. Web Development is a Creative Career Web developers are different breed of technologists. We are increasingly...
2. Using the Basecamp API to Create Project Reports A few months ago I wrote a post describing the...
3. Iterative Development is Effective Here at SmartMoney, we have been using iterative development techniques...

Related posts brought to you by Yet Another Related Posts Plugin.

A few weeks ago I wrote that good design is a dying but important art. While I do believe that is true, there is also too much of a good thing. Sometimes you can get too caught up in the ‘ideal’, worrying and designing things to be perfect. Deciding what is the right blend of ideal and pragmatic is also an art, and in my opinion one of the most important tasks of a developer or manager.

I have worked on many web projects in many roles. I have been a junior developer, senior developer, and the technical architect where I was not going to do any of the actual coding. Whether developing or designing you are constantly faced with a challenge. Developing the ideal or textbook vs a real or pragmatic approach. My philosophy is to lean towards pragmatic. I believe you should be versed in the textbook methodologies as they are very useful and it is wasteful to reinvent the wheel. You need them in your arsenal to apply when necessary. In the end if we have a production quality piece of code that runs with minimal issues, and can be updated, do I really care if my developers used the ‘correct’ factory or design methodologies for the project? I do not. The correct methodology for me is the one that works and gets the job done on time. Again I want to re-iterate that does not mean I believe in sloppy, spaghetti code. I certainly do not. But I definitely value function over form.

A lot of these development styles are fads. Yes things are constantly being improved, but just because something is new, its not always better. Extreme programming leads the way to another style. Configuration and initialization files were all the rage for years, now abandoned in favor of self describing code. Developers could sit and debate the correct factory to use for a job in the same time I could code the whole project.

We are builders, we take a tool (programming language) and we create product. So
just like there are many ways to build a house, the same holds true for web development. Sure some methods are better than others, but if your team is talented enough most of the decisions they make will be good enough for the job.

You need to build the product for as long as its lifespan. Not every house is built to stand 500 years, and neither is code. Just like a builder in Montana does not build a house to be hurricane proof you should not build for problems you don’t have. You should build code in a way that it can be modified and extended should the need arise. But if you are building a niche craft site with only a handful of users and 5 products to sell, do not waste time designing to be the next Amazon.com. When you add more products you can worry if your shopping cart class has the extendability to grow, just get the code live.

My advice is if you are a senior tech lead or manager you should keep up with the new methodologies that are making a wave. But don’t chase them all, and don’t distract your development team with all of them. They have a lot of code to write and having them chase the next development fad is not in anyone’s best interest. As a manager you should know when to push your developers towards a certain technology, and where to adapt it to fit your team’s and company’s needs. You may spend 2 years designing the perfect framework for a job but that is just not practical, and in most companies it will not be tolerated. Most senior managers do not care about how it’s done, just that it was completed under budget and on time. As a tech manager your role is to find the most effective blend of ideal and practical to keep management happy and your developers skill set ready to tackle the next project.

Related posts:

1. Hello world! Welcome! This is my first post, so let me introduce...
2. Software: 6 Questions to Ask Yourself When Deciding to Build or Buy A common dilemma of many tech managers and businesses in...
3. product versus project manager For years, SmartMoney had project manager(s).  This was more of...

Related posts brought to you by Yet Another Related Posts Plugin.

For years, SmartMoney had project manager(s).  This was more of a necessity during our early years, when projects were large 9-12+ month long beasts.  Our projects were managed in a more classical software development approach commonly used at the time. Projects had weekly status meetings, pages of specs and documents that were always in need of updates. In other words, projects had a lot of busy work.

Those days are over. Projects are now smaller and more iterative. Because of this change, I feel instead of a traditional project manager the web now needs product managers.  In this role, the product manager is someone who works for the side of the product itself.  They do not simply setup meetings and coordinate between groups, rather they are knowledgeable in the web and the product being developed.

A product manager may be a technical generalist. They are familiar with modern usability requirements, and testing  They know SEO, web analytics, and know how to monitor a products successes and failures.  If it is a larger sized project or product, they should also become that products evangelist.  They are responsible for getting a product marketed and featured to ensure its successes. They are involved in developing a complete strategy for the product. This means they are not only responsible for getting the project to completion, they play a large role in monitoring and making the product succeed. Now this doesn’t mean they would be marketing geniuses also. In many companies it simply means they would coordinate with the correct marketing resources to help the product succeed.

This is a very important but overlooked role in technology.  With teams getting leaner and more agile, developers are usually not able or available to monitor a project’s success once deployed.  At SmartMoney, we move onto the next iteration or project almost immediately after deployment (usually simultaneously).  Beyond monitoring the errors and making sure a product physically runs, the development team does not often watch how it performs, or if users are having difficulties.  We rely on usability testing and user feedback through email and customer service to tell us how a product is being received in the real world. A product manager would be able to analyze the usability, and determine what features or areas need a second round of design and implementation.

Some companies may have dedicated SEO, analytics, usability, and marketing departments.  I find this rarely works.  This generates a lot of reports and emails that get passed around but never looked at. Passing around reports creates an illusion of agreement. Just because you create and send a report to 5+ managers, that doesn’t mean people really agree to its contents. But because of the inevitable lack of feedback, the sender usually feels that no response implies consensus. One good hardworking generalist who understands the web and the product you are creating, who is in direct contact with your technology teams is worth more than many departments of specialists to me.   If you don’t have this person where you work, consider retraining someone who shows an aptitude towards these talents.  As you move towards more iterative projects, you will find this position really fits in with the overall success of effective development methodologies.

Joel on Software has a great article on this topic, which he describes a similar role he calls program manager: How to be a Program Manager. Its not exact as he talks about the role in traditional desktop software development mostly, but a lot of principles apply.

Related posts:

1. Find the Right Blend of Ideal and Practical Web Development A few weeks ago I wrote that good design is...
2. Web Development: Because We Care As a web developer you make a product (the website...
3. Software: 6 Questions to Ask Yourself When Deciding to Build or Buy A common dilemma of many tech managers and businesses in...

Related posts brought to you by Yet Another Related Posts Plugin.

Here at SmartMoney, we have been using iterative development techniques for years. Even before the term was made popular in the technology field, we ditched the long drawn out style of project development. For the most part, we now employ a more cyclical style of development where individual features are coded, tested, deployed. New features are added based on lessons learned from the earlier cycle. From there we try to gauge the public’s reception to the feature through usability testing and feedback, then either work to improve that feature, or begin work on additional features within the same short cycle.

In the past we tried creating wikis for our projects and writing document specs. These are really a waste of time, and just do not work. They take weeks to create, and are often outdated as soon as they are delivered.  Better yet, even if they are not outdated, they are usually ignored. Iterative development gives you the opportunity to deploy, test, and most importantly to be wrong.  If a feature is not accepted by your users, you can easily refine or remove it.  You are more apt to admit your mistakes and remove a feature that took 2 weeks to deploy, than one that took 6 months.

The problem with getting buy in for iterative development at most companies is usually not with the technology group. Developers and technology managers usually embrace the techniques. It keeps things fresh, it involves less red tape and lets developers get to what they love – code. I find for me it keeps things moving. You feel less stale when you are always moving through these mini life cycles.

I find resistance to this style of development tends to come from the business side. Groups like marketing and sales prefer a larger “completely finished” project to sell to clients. Project managers tend to prefer larger projects to maintain their value on the project. The larger the project, the more management it will need. Finally, some people just don’t consider it a web project without a large cycle of gathering specs, creating wireframes, refining code, QA/Testing, repeat ad nauseum, then finally deploy. These are the people in your company that need to be sold on the benefits of Iterative development. I found an article today that discusses getting business people and anyone who needs it to embrace the philosophies of Iterative Development.
Embracing an Iterative Approach to Site Development. Its a quick read, and simply states some cost and time benefits you may find useful when trying to sell the idea to someone where you work.

Iterative development is practical and effective because it ensures you are keeping your projects lean and agile.  I really recommend looking into this style of development and trying to find areas where you can incorporate it into your workplace.  Even if the majority of your projects employ long spec-code-test-deploy cycles, you may be able to work with these methodologies in small ways.  Try to take a large project and see what can be broken down into manageable iterative chunks. My experience is that you will most likely have luck looking at the back-end development needed. This area of a project has the lowest visibility, as most project stakeholders care about the UI. Get familiar with breaking down the requirements to a bare minimum, coding for that minimum, then repeat the cycle if necessary. Once you have a few wins, or successful iterative projects, you may find others in your company are more willing to adapt their style as well. The benefits will speak for themselves.

Related posts:

1. deployment schedules are not effective Simply put, deploying code on a set schedule is not...
2. Knowing your users will help make effective decisions If you are reading my blog, there is a very...
3. Use Project Collaboration Software We use BaseCamp here for managing projects. It is extremely...

Related posts brought to you by Yet Another Related Posts Plugin.

Let me give you a little information about where I am coming from. I would like to show you that you can merge modern development techniques such as getting real, agile development, pragmatic programming in a corporate environment. Currently I am the Director of Web Development for a large financial website. We publish original content, as well as magazine content. We also offer a full suite of market and personal finance research tools. I have a lean tech team of 7 developers (5 web developers and 2 DBAs). The average tenure on my team is 8 years which is rare in this field. Even rarer is how we kept much of our talent during the dot com boom and the years of recruiter phone calls with free Knicks tickets. Not only has the economic climate changed even Knicks tickets, as a perk, are worthless these days.
We have managed to stay lean and put out great product for years. I have always incorporated a practical style of programming and development with my team, combined with the reality of corporate America. I have named this style “effective development”. We have been developing this way for years now, even before these techniques had a name or following. It is not a pie in the sky style, rather it combines technology ideals with business realities to allow teams to deliver good product. While I think some of the newer ideals are great, and worth reading/following, I hope to show you some real life applications of these styles, and what has worked for us here. Because in the end, you are judged by the product you put out, and not the process used to get to the final product. I promise the next post will start to contain some ‘meat’ and practical advice.

Related posts:

1. Find the Right Blend of Ideal and Practical Web Development A few weeks ago I wrote that good design is...
2. Iterative Development is Effective Here at SmartMoney, we have been using iterative development techniques...
3. product versus project manager For years, SmartMoney had project manager(s).  This was more of...

Related posts brought to you by Yet Another Related Posts Plugin.

Welcome! This is my first post, so let me introduce myself. I manage a group of developers for a large website, where I initially started as a junior developer 10 years ago. I have decided it is time I share some of my thoughts, experiences and practices that I have gathered over these years. I know it is cliche, but I have a truly pragmatic approach to life, which flows into my general philosophy of work and software development. Not everything comes down to specs, documentation, and methodologies. In fact, the end result is what matters, hence being ‘effective’. In the end, effective development accomplishes goals, and gets projects out the door.

Related posts:

1. Find the Right Blend of Ideal and Practical Web Development A few weeks ago I wrote that good design is...
2. product versus project manager For years, SmartMoney had project manager(s).  This was more of...
3. Iterative Development is Effective Here at SmartMoney, we have been using iterative development techniques...

Related posts brought to you by Yet Another Related Posts Plugin.