Non Technical Factors Influencing The Development Platform Selection

Recently, I have been working with a number of early stage companies engaged in the debate over what development platform would be best for their company. The options considered are varied with the most significant division occurring between the Microsoft and Open Source/Linux camps. Database selection, program language, O/S, Hardware, Cloud Computing versus conventional hosting are all in the decision mix.

Oddly enough my experience has been that the decision to go down one path or another is significantly influenced by "non-technical" considerations. Companies can use business, prior experience and in some cases less than rational arguments to select one platform over another.

This is an interesting challenge from a consultant/adviser perspective. A technical consultant's initial reaction is to steer people away from the more esoteric reasons for choosing one platform or another. However, the less then purely technical reasons for selecting a development platform need to be understood, dealt with, addressed rationally to obtain a consensus within the organization and to recommend the "best" development platform for an organization.

The following are common non-technical arguments that frequently influence the development platform decision.

The CTO (main programmer) Knowledge Base - Early phase companies are highly dependent on single individuals. A key person in a startup is the main programmer setting up the systems and coding away to get the company up and running. Their knowledge base is usually restricted to a certain universe of development platforms. Frequently, a company will assume that the platform selection of the programmer is the right one. No questions are asked, no assessment is done, no performance criteria is considered.

What happens if this individual leaves the company? The main programmer may have made the right chose and they many not have. If they leave the business the company could be stuck with an obsolete platform, a platform that does not scale, or a platform that is expensive to maintain.

Available Expertise - Platform decisions can be based on the availability of resources in a certain geographical area. If an area has an abundance of programmers using one programming language versus another the tendency is to select a platform for the available pool. This reason has merit. A business certainly needs resources to build and maintain products. However, a company should not make a platform decision exclusively based upon available resources. Technical pros and cons need to be brought into the discussion. Just because there are a lot of technical resources available to build a certain platform does not automatically mean the platform is appropriate for your business.

Business Fear Of Open Source - There still exists a large pool of business people that are skeptical about the safety and security of Open Source based software products. Many executives harbor the fear that Open Source software is subject to embedded "Easter Eggs" and tunneling hackers that could somehow topple an Open Source based platform. This may be a surprise for technical professionals and does require the technical staff to "educate" business owners on how Open Source projects are run and operated. Open Source is certainly a viable platform and should not be discounted because business owners have not been educated about the merits and security of Open Source products.

Brand Prejudices And Bias - Everyone has their bias and prejudices when it comes to product selection. Brand prejudices also exist in the development platform world. Business and technical people will have brand name prejudices(Microsoft, Oracle, IBM, RedHat, etc.). Buying into a development platform based on a bias without associated technical merit is not a good way to select a platform. Not considering a platform because there is bias against it is also not a reason to ignore a platform.

The Latest Hot Platform - Developers are subject to adopting the latest new programming language, DB or upgrade. This is what keeps the industry evolving and improving and is a great way for technical people to upgrade their skills, learn something new and command more money for their services. Adopting a new and emerging programming language may or may not be a good chose for a company. Just because something is new and emerging is not a reason to adopt or reject it as a platform chose.

My Competitor Or Potential Partner Is Using The Platform - If the platform used by a competitor or potential business partner is working for them then it certainly merits consideration. Equally important is to determine what if anything is different about your company. product or service. If the competitors platform puts a company in a position where you lack differentiation, scalability or flexibility to increase market share the company may want to consider other options.

Conclusion - The selection of a development platform for a company is a major decision that has long term consequences for an organization. Startups are especially susceptible to making hasty and uninformed development platform selection. Spending a bit more time on the decision and grounding the decision by considering technical as well as business input will lead to a more defensible outcome. It will also build consensus within your company and the confidence that the company is making the right decision.

Game Platform Preparation For Legalized United States Online Gambling

The impending legislation to legalize online gambling in the US has ignited debate and speculation on how to prepare for and successfully launch and operate online gambling operations in the US. One of the major challenges for operators and game platform developers will be their ability to provide robust and scalable game content to address the large and sophisticated preferences of the US population. Building and managing reliable and scalable game platforms is a non-trivial. The act of crafting an online game strategy and executing the production, delivery, operation, integration and maintenance of games, game platforms, payment processing, age/identity/location systems is worthy of some serious planning.

Licensing Versus Build - I crafted a blog several months ago called "Should An Online Game Operator License Or Build Games?" I suggest you also read this blog to determine if building your own games/platform or having a third party provide you with a solution is the best way to go for your company. This decision has long term strategic business implications that are difficult to reverse once a path is chosen. The decision does not have to be binary. There are hybrids. However, the decision has significant impact on cost, staffing, organizational flexibility and market differentiation.

Even if you do decide to license games and a game platform the following points should still be taken into consideration when evaluating a vendors product offering.

The Primary Challenge(s) For Online Game Development - Online gaming is fundamentally different then most web applications. Online gaming is transaction intensive. The amount of transactions that occur per second in a popular online gaming site far exceed anything witnessed on a standard e-commerce site. Game applications are "state machines" that must be aware of what has happened, at a detailed level, at any instant in time in order to proceed to the next state. Game applications are data intensive requiring the capture and storage of every detail of game play. This level of detail is required to support the "state machinery", to address the need to audit previous game activity and to support financial transaction processes. Underlying the game play operation is a banking operation that has to be 100% accurate. Gaming platforms have to be secure to avoid internal and external attempts to influence game play and or to extract funds from the game system. Multiplayer games are social networks that include interaction in social and financial terms. Gaming sites are subject to legal scrutiny by state and federal authorities. To sum it up online gambling systems are complex and held to a higher standard then other web applications.

So how does a company, operator, IT or development staff successfully build and operate an online gaming platform.

It Is All About The Database - In many ways this is also true for web applications that are not gaming related. I start here because in almost every online game system I have built, managed or operated the DB has been the primary challenge. In the early stage of development the DB selection, architecture, IT layout, query creation and table design need to be fully vetted. This requires projection of loads, data types and usage patterns. Each DB has its strengths and weaknesses. The way the DB is constructed has an impact on performance, security, reliability, cost and talent required to make it operate efficiently.

Why is the DB so critical in a gaming application? Gaming applications are "transaction" intensive resulting in the accumulation of data at a rapid rate. Games require quick response time to keep up with game play and require knowledge of the "state" of play to determine the next step in the game play sequence. If a system/DB fails to address these fundamental requirements resulting in an incorrect outcome, hesitation in game play, slow response time, or an incorrect result the game is over so to speak. The DB is largely responsible for making sure the game platform is in equilibrium for maintaining the stability and viability of the game platform.

DB selection is important. Developer's and business owners have their prejudices. Prejudice should not cloud your judgment for the DB selection. Databases used in high transaction banking operations come closest to the type's of DB's appropriate for gaming systems. However, these can be costly and prohibitive for startup operations. Certain open source DB's are good alternatives with the caveat that DB architecture and design are even more critical when selecting open source DB solutions.

Avoid monolithic DB's and plan for sharding and or clustering of the DB to segment the DB. The divide and conquer approach provides isolation and will help to avoid an overload of any one server. Design a DB to allow it to be spread over multiple machines. This provides you with an option to add hardware to address DB performance issues.

Who writes the queries and who is in charge of the health, welfare and design of the DB. The answer is simple; NOT THE PROGRAMMERS!! Programmers are not normally DB architects and have a habit of developing queries without taking into consideration the big picture and an overall architecture. Also, some "frameworks" auto generate queries. This is also not a good idea. Each query should be specifically crafted to optimize performance.

Game development organizations should have a DB architect on staff to implement a DB design, create tables, create queries and to interact with business owners, project managers and developers determining the philosophy, design, table structure, layout and setup of the DB. The responsibilities of a database architect are different from a database administrator and are often confused. This confusion is understandable because some database architects can and do administer databases. The distinction between the two functions is very clear. An architect established the DB design, creates tables and queries. An administrator loads the DB on the hardware, does the backups/restores an sets up the monitoring of the DB.

Application Layer - The games will need to run on their own hardware separate from web serving and database activity. This will optimize game performance and provide isolation in case there is a problem. Reacting to problems quickly is important because of the financial implications.

No single application server should act as a "controlling" or traffic router in the application server mix. This will defeat the purpose of distributing traffic to decrease the risk of impacting the entire system if one server has an issue. All application servers should be created equal.

Web Servers - Web server technology, load balancing, logging, etc. has become standardized allowing operations to handle large transaction volumes associated with typical web traffic. Keep game play responsibility away from web servers. Web servers will handle registration, log-in, traffic monitoring and content serving. The heavy lifting will be done by the application servers and the DB. One exception is graphic content. Place graphics on separate web servers.

Caching - Caching is a way of storing information/results on application or web server without having to go the the DB to fetch the information. Caching is most effective when certain data is consistently being used and retrieved. This will off load strain on the DB and distribute the load to the application and web servers.

Plan and Design For Multiple Delivery Platforms - Plan for Facebook, mobile and multiple language deployment. Do not design your game platform to deliver content in only one environment. Develop your application to be deployed in social networks, on mobile devices and with multi language support. Social networks and mobile are especially important given the trend for consumers to exclusively interact in these environments.

Small Foot Print Client - The age of heavy, large and complex game clients is gone or has been marginalized for use in console game environments or MMOG worlds. Keep you client development light weigh allowing players to quickly engage(download) your games.

Age/Location/Identity - For compliance reasons your game system will have to know where a player is accessing your system from, where they reside and how old they are. This can be a fully automated implementation or a combined automated manual process. The implications of allowing a player to play on a gaming site this is underage or from a jurisdiction that does not allow online gambling will be severe. Creating these systems requires expertise in risk managment(AI) and access to multiple data source that provide the operator with comprehensive coverage of the target population.

Prepare For System Audits - A game system will be subject to audit to assure that the system is secure and the outcomes are fair and random. The game systems will be audited by third party organizations. They will determine go and no go. They could shut you down if your system is deemed vulnerable to internal or external attack. Prepare your code and system layout to make this process as painless as possible. Obtain the auditors guidelines beforehand to make sure you are not over or under designing you system for audit and compliance.

Payment Processing And PCI Compliance - The credit card companies have formed an alliance that dictates the level of security your platform will have to have to take credit card transactions. These guidelines are detailed and require a PCI knowledgeable individual or company to help you implement a PCI compliant platform. If you are caught not complying your credit card transaction processing could be terminate. Run through your own PCI audit before launching.

Tracking And Analytics - Google Analytics will not cut it. A system should be created that ties web traffic together with game play and payment processing activity. This is the only way you will get a complete picture of player behavior, marketing results, traffic and revenue per player.

Hosting and IT - Unfortunately "Cloud Computing" may not be an option because it is difficult to enforce PCI compliance in a Cloud environment. This will require the operator to locate a hosting facility in a jurisdiction that allows online gambling operations and has the infrastructure, bandwidth and expertise to support a sophisticated gaming operation. This may be one of the biggest challenges for game operators.

Denial Of Service And Intrusion Attacks - In Europe it is common for a gambling site to be subject to a denial of service attach and then a ransom to stop the attachk Get you hosting, network provider and development team together to craft a strategy to deal will the attacks.

Intrusion attacks conducted by robot scans of your URLS will also be common. The goal is to figure out a way to reverse engineer the URL to get access to your data. So, be careful how you construct your URL's. Do not forget about the URL's you put into e-mails and other promotions. The attackers scan these as well.

Engage a security service company to regularly scan you URL's for vulnerability. This we be required for PCI compliance as well.

Web Services - Your architecture and applications should be designed as web services with the appropriate standard communication protocols (SOAP/XML/Hybrids). Your applications will be accessing data from external systems and supply data to external systems. Do not back your platform into a proprietary setup.

Monitoring And Support - Support for game platforms go well beyond the needs of standard web applications. 7/24 of course. However, the financial implications to players, your company and to payment processors can be severe if the game system has downtime or unexpected failures. Do not skimp on monitoring software or you IT support staff.

In Conclusion - The eventual legalization of online gambling in the US will open up new and lucrative opportunities for businesses. It will also provide challenges for these businesses and their technical staff/partners to deliver and support operations that meet the requirements of their players, regulators and payment processors. Be prepared and design game systems with this in mind.

The Hands On Engineering Manager Paradox

The current economy appears to be breeding a crop of job descriptions looking for people that will program, create systems architecture, speak the business language of upper management, hire the engineering staff, manage the staff, put together an engineering budget, setup the servers, etc. To put this politely, not going to happen. Or at least not for very long.

I certainly have been in situations were I was doing all of these things. However, realistically not all of them very well. Sure, in a very early stage start up you might need to ask someone to initiate multidisciplinary tasks. However, no one is going to be good at all of these tasks. Setting an expectation that someone should be able to handle them all could have negative long term implications for the individual being asked to perform these tasks and for the organization as a whole.

There are fundamental differences between the skill sets to manage an organization and to build systems. There are a few people on the planet that are versatile enough to flip back and forth between these modes of operation. However, even for these people, the work load gets to a point where there needs to be focus to establish any real progress on any of the tasks.

I understand why a business owner would want to have all of these tasks encapsulated in a single individual. Budgetary constraints, investor pressure to control staffing, the institution of a lean and mean startup culture to name a few.

In some cases the business owners that are looking for these interdisciplinary individuals do not come from a technical background and do not fully understand the focused concentration level required to create a system that scales, is reliable and can be understood by the rank and file technical staff. The last thing you want this person to do is to be spending time managing the day to day operations of your engineering group when they are deeply involved in getting your system designed, built and up and running. Conversely, if an individual is beavering away programming, configuring servers, installing hardware, etc. and not paying attention to day to day engineering organization management the entire development process could come to a screeching stop.

The practical consequences of proceeding along with this model are as follows:

Someone Else Is Managing The Engineering Group - If you are asking a programmer or systems architect to manage your engineering group you will wind up having another person in your organization stepping in and managing the day to day operations. This could be one of the co-founders, product or project manager or an executive staff member.

Your Early Design And Systems Have Issues - We all remember the Friendster debacle. This system could never adjust to the popularity of the service. It fundamentally lacked an architecture or any real supported systems structure. Was the engineering managers asked to do everything resulting in a lack of focus on a reliable sustainable systems architecture?

Staff Churn and Organizational Dysfunction - What a bad way to start a company. You will be facing enough challenges trying to get your business up and running the last thing you need is a bunch of frustrated engineers wanting to quit because nothing is working right and they are being mismanaged.

The stress of a struggling system and a disorganized engineering group stresses out other parts of the organization. This can lead to some serious confrontations between various individuals and groups.

So how do you avoid the downside of a single engineering manager simultaneously executing managerial and technical tasks and still stay within the budget?

Engineering Team Management Oversight - In the early stage of the business or organization establish someone with management skills to oversee the engineering group. This could be someone on the executive team or it could be an outside consultant. Have this individual work with the engineers to staff and organize the group, deal with personnel issues and act as a liaison for the engineering team to make sure their concerns and issues are voiced. Conversely, this individual will communicate management directives to the engineers in way that they can translate into concrete action.

Engineering Process - Establish a development process that is well undertood by all members of the organization. Make sure that process matches up with the business goals of the company. In a start up or small company realize that just about everyone in the organization is part of the development process

Architecture and Platform - Clearly state the business objective of the company and obtain a satisfactory systems architecture plan to achieve the objectives. Get outside advice if necessary and entertain a number of options. Once you establish your platform and architecture they are very hard to change.

Short and Long Term Objectives - You may be in a mad rush to get something up a running. This is understandable just make sure you do not fool yourself into believing that a rushed system is extensible and sustainable. It will most likely have to be replaced or significantly modified to run your business. Do not blame your engineers for getting something up and running quickly and then castigate them later when they tell you the system will have to be changed to accommodate your growth.

Engineering Organization Staff Planning - Be prepared monetarily and organizational for what it takes to run a real company. In the early stage of your company you may have a few programmers and consultants getting you going. This will be short lived if you are moderately successful. Have a good understanding of what it will take to effectively run an engineering group. Anticipate the need for an engineering manager, architect, DBA, programmers, QA, product management and IT support.

Crisis Management - Watch for signs that the engineering group is in a perpetual state of crisis management. If nothing appears to be going right or you appear to be exerting a tremendous amount of time and energy to get tasks completed you are in crisis management. Take the time to determine what organizational or technical issues are causing the problem. Address this issue immediately before you develop a perpetual crisis management culture.

Focus and Prioritization - Of all the tasks and items you want the hands-on engineering manager to perform determine the most important priority for that individual and clear the deck for them. Get the high priority items complete. Do not let the manager become distracted. This is especially important for technical and architectural tasks. Ping ponging back and forth between tasks is exhilarating but very dangerous if you are building a team and a system.

In conclusion, the current investment market places pressure on engineering organizations to consolidate functions and tasks into single individuals. This is understandable and a reality. However, do not fool yourself into believing that managing an engineering organization is not a full time responsibility requiring multidisciplinary skills not often found in a single individual. Understand the implications and compensate for the challenges an organization will face if the engineering managers is expected to be multidimensional. Prepare for the future realizing that eventually the organization has to build an engineering organization to be successful.

Build Versus Buy

The decision to build or buy an application has significant implications for an organization. It may be one of the most important business decisions an organization makes. Early stage companies frequently do not take the time to evaluate all of the repercussions of the decision resulting in unexpected long term consequences. The buy versus build decision is hard to reverse once it is made and should be well thought out before a final decision is made.

The best way to avoid a bad or irreversible decision is to clearly state the short and long term goals of the company and see how they match-up a with a build or buy strategy. Build versus buy impacts many aspects of a business including budgeting, strategic business relationships, control, customization, time to market and company culture. Each one of this should be evaluated before the build versus buy decision is made.

The following is a list of recommended items that should be debated before a final buy versus build decision is made.

Control - How important is it for your organization to be in control of its destiny? We all want to think that we are in control of our business. The decision to build versus buy has a big impact on the extent of that control.

If you decide to license an application control of your business begins to shift to the vendor. The vendor decides when releases will be made, the quality of the applications, the features and the core technology.

If you build an application internally your organization increases its control over its own destiny. Features, releases schedules, customization, interfaces, technology and are all dictated by your organization.

Differentiation - It is difficult to differentiate your company's product in the marketplace if you license mission critical parts of your product. A software vendor can only customize your product to a certain degree and still service its other customers. If you license a piece of software your company will have to find other ways to differentiate itself.

Customization - A software vendor will customize your software but it will cost you extra and may not be exactly what you are looking for. The vendor has to maintain continuity with the core application that is licensed to other companies restricting the degree of flexibility it can exercise. It can also be expense to customize an application. If your change request is significantly off track from the vendors road map the majority of the costs will have to be paid by your company.

Time To Market - Licensing a piece of software will allow your company to enter the marketplace faster. If you develop your own application the company will have to build a development staff, purchase additional hardware and actually build the application. This takes time, money and resources that could potentially be used for other projects.

Budget - In most cases a software licensing arrangement should cost you less compared to an in-house developed application. The licensing company will be leveraging their development costs over a number of companies thus decreasing the cost for your company. Building an application internally is expensive even if significant portions of the development are outsourced.

Managing - Managing a vendor and managing an internal development organizations are two very different processes. If a company is developing a product it will have to create a development process to manage the development. If a product is licensed the company will be managing the vendor who in turn will have its own internal development process. The degree of sophistication and professionalism of the vendor will dictate the extent and difficulty of managing the vendor.

Managing an internal development group provides more visibility into product development allowing for faster changes and the acceleration and deceleration of products releases. Managing internal development teams can pose its own unique challenges requiring multidisciplinary coordination. The developers and associated support require special attention including training and technical management.

Staff - If you are developing your own product a development staff has to be created. This means hiring, firing, outsourcing, motivation, reward, direction, scheduling and communication. Some form of HR support should be instituted to oversee the organization and make sure management is addressing personnel, motivation and salary issues.

Replacement Cost -What will it cost to switch gears and go from an outsourced piece of software to an in-house development plan. The reverse should also be modeled. It is not uncommon for an early stage company to change its product and development strategy as it matures. Creating a budget and organizational structure for both the build and buy scenarios is a good early stage exercise. If you do need to change your strategy you will be prepared for the impact on the bottom line and the required organizational changes.

Hosting - If you are licencing software from a SaaS vendor your hardware and hosting costs should be low. If you are licencing software to be hosted by your organization do some research on the cost of the hardware and the associated hosting costs. If you are developing the application yourself the hosting and hardware are entirely your responsibility. This has staffing implications requiring you to add IT personnel to provide 24/7 hardware, systems and telecommunications support.

Culture - How you approach product development has a big impact on your companies culture. A company with a fully loaded development staff has a very different culture then a company that is licensing most of its software and infrastructure. Be cognizant of the cultural impact of these decisions. Are you a marketing company, development company, sales company or a mixture of all or some of these categories. Your culture will have a big impact on your ability to hire and attract the talent you are looking for.

Each one of the items I have mentioned is a subject in and of itself and deserves a much deeper consideration then I have provided in this article. If you are pondering a buy versus do some more research on each one of these areas to make sure you make the right decision.

If you have a specific question about build versus buy please contact me at kflood6@gmail.com.

Engineering Managers as Hiring Managers

In these challenging economic times you might be thinking about activities other then hiring. However, in many ways this is the best of times for companies looking for talent. Even if you are downsizing you most likely still need qualified individuals to maintain your operation and to grow the business. Downsizing itself could lead to highly skilled people leaving your company. Engineering managers need to always be on the look out for qualified people and ready to close them when they become available.

Engineering managers face special recruiting challenges. Technical people are usually more interested in managing technology, creating services and products then managing the hiring process. Despite this, all departments need talent. In engineering, the need to identify candidates with very specific skill sets is ever present. Engineering teams always seem to be under extreme pressure to get changes on the site or products out the door. Recruiting and hiring engineering talent is a never ending organizational commitment.

Surprisingly success in hiring engineering talent starts well before a single job description is created or an interviewed scheduled. When crafting an architecture and platform for your product and site the development team should think about how hard or easy will it be to recruit people to work in the environment you are creating. What is the culture of the company and how is that going to impact your ability to attract talent. Where are you located? What is the target audience of your product or service?

Language/Platform/Database/Hardware: The coding language, platform, database, framework, hardware you select will make it easy or hard for you to attract talent to your company.

Be careful about using a language and environment that is dated and has lost ground to newer environments. For instance, you might be inclined to use native C as a coding language because of its performance characteristics. You may use a special messaging system like CORBA because it integrates well with C and you have used it before. You also may want to reconsider this decision and begin exploring the availability of people that understand these environments and if they do are they really interested in working with this code base.

The latest really hot, cool language and environment can also pose its own challenges. Sure Ruby on Rails and Javascript/Python are all the rage. However, if everyone is looking for the same talent then you might have a real problem after you get the first prototype up and running. Before you make the plunge into the latest and greatest do some exploration of the market and see if these people are out there and would they be interested in joining your company.

Company Culture: Companies all have unique cultures born out the the ideals of the founders, the product and service they are developing, the location they are in and the customers that they have or intend to sell their product too. Your culture could be your greatest asset or worse enemy when recruiting. People are very interested and concerned about the environment they are going to spend most of their time in. You need to ask the question how broad based is your company culture? Will it attract people and talent from a number of different backgrounds or is it very narrowly defined limiting you reach and ability to hire. These are very difficult questions to ask of an organization. Companies have a tendency to want to think of themselves as being very unique. That is great if the uniqueness takes into consideration embracing people from a variety backgrounds. It is not so great if your cultural screening process results in a severely limited pool of candidates.

Development Process: The process you employee to develop products is becoming more important for an individuals career advancement. You need to have a good answer for your candidates. Are you Agile, are you a hybrid of RUP. Do you use content management and rapid prototyping for some parts of your system? How does the development process fit the business model? A candidate wants to believe that when he or she puts this on their resume it will be recognized and has career advancement potential.

Location, Location, Location: It is true for real estate and is is true for hiring. Where you are located makes a big difference on who is going to work for you. Sure the Bay Area is a great address. It represents the latest and greatest and the best and the brightest. However, there are lot's of companies looking for talent in the Bay Area. What is different about you? There are great technology centers elsewhere that could also have good talent pools and do not have the extreme competition for talent.

Location becomes very important when gas prices are high and traffic is intense. Are you near any mass transit line such as buses, trains or even the airport? People are starting to realize a location that contributes to lower cost commuting options becomes a benefit similar to health care.

We Only Want Rock Stars: Well the thought is good but practically speaking not achievable. I strongly suggest that you do not predicate the success of your company on the acquisition of all rock star developers. If you think about it, it is unrealistic to assume that everyone you hire is going to be a rock star. There are so many rock stars in the universe. Also, are you sure you want a lot of these in your organization. Rock stars historically are hard to manage. They frequently manage you and dictate the direction of certain aspects of the platform and technology. What you really want is a rock star here and there to drive your architecture and some thorny aspects of your setup and platform. You want the rest of your people to be good talented people that work hard and are good communicators and collaborators. That is what makes a good team. These people are also hard to find but there are more of them.

The Interview Quiz: Many engineers and engineering managers will create a test for new candidates. These questions are usually specific to a programming language, framework or the DB, etc. These are great and will give you a good idea if the candidate can work within your specific development environment. However, if you are looking at a candidate that is transitioning from one environment to another these questions are not going to help you. In these situations you might want to create more general questions focused on object oriented programming, build and deploy strategies and general web programming. What you really want to know is how smart is this person. Given a situation where he or she does not know the environment or has to solve a problem for the first time how will they handle it. In a fast moving start up you are always confronted with problems and technologies you have not experienced. How will this person adapt to these scenarios. Even for the person that answers your platform questions cold should be thrown some curve balls. You want to hire versatile and creative people that can deal with problems as they arise.

Team Dynamics: An engineer may be smart and know your platform well and still fail in the position. Why is that? Every team has a unique dynamic. Is your team highly collaborative? Is it a shop where every developer stays in there cubicle for days on end and then comes up for air after a build? How much interaction occurs between the development team and other department? Does this developer actually have to communicate and collaborate with people from other disciplines? What is the stress level in your group? How does the developer handle stress? What kind of hours do you expect this person to work? How flexible is your organization? How important is face time in the organization? One of the best ways to ferret out some these esoteric issues is to have a group interview with the candidate. Throw them into the group dynamic and see how they react. Also expose them to people from other departments. See what they think about the candidate.

Once you have this establsihed early the ground work for the candidates it is time to go and find them.

Friends and Close Associates: This is old school and a great place to start. The advantage is that these people are know entities, you do not have to pay for them and most likely a cultural fit for you organization. However, this pool of candidates runs out quickly. You only have so many really good friends. The downside is that having friends in your organization can be challenging when the company is facing real issues. What happens if you have to fire your best friend. Not a pleasant experience. Professional distance can sometimes be a good thing.

The Job Boards: Craig's List, Yahoo and others are a great places to get really cheap public exposure for your position. Craig's List in particular targets geographic areas. These are low hanging fruit. The advantage to these online services is that you will not be bombarded by ads to use their services. Tell the candidates how easy it is to get to your company, how great you are and all the fun things you do. Talk about the development process you have. Developers are keen to know what environment they are going to work on. Then give them all the technical requirements. Hopefully, your development platform has a catch or two in it to get the development community excited.

Online Recruiting Sites: I am talking HotJobs, Monster, TheLadder, etc. These companies act like a recruiter without any human contact. They have a large number of people posting their resumes. It takes a lot of work to find the person you want on these sites and it does cost money. I personally have not had great luck with them but this all depends on the talent you are looking for.

Linkedin: This site stands on its own and is the granddaddy of social network meets career contacts and advancement. There is not really anything quite like it. It continues to grow and is now adding other recruiting sites to its job searches. This is is real must because it is a "trusted" location to put professional information, seriously post jobs and look for jobs. You can do all kinds of research on the company and the people connected to the company.

Other Online Postings: Tech Crunch comes to mind but there are other online communication vehicle that also serve to post jobs and information about your company. Do not under estimate the power of distribution and eyeballs. These sites are popping up all the time. They need and want content to legitimize themselves. Your listings are a good source of content.

Conferences and Meetups: Get your company out there and be recognized. It is jungle out there with many companies looking for talent. You need to be visible. In San Francisco and San Jose they have the High Tech Meetups. There are also loads of conferences that would love to have you make a short presentation. Most of these events post you video to the net and create a min web site for you.

The Social Networks: This is a tough one believe it or not because the Facebooks, Bebo's Hi5's MySpace's and Twitter's are not really a place to be presenting your technical professional openings. Often these properties are used to establish one's personal identity and to communicate with people on a personal level. People generally do not like to mix career and personal identities. However, they are places to connect with all of your friends and friends of friends to at least inform then you are personally looking for talent. However, be careful how you pitch it you do not want to alienate anyone.

The Recruiter: Yes in this day and age of online properties and searches you are most likely going to need a real recruiter if your business is growing rapidly. The new age recruiters are using sophisticated online sourcing tools to find candidates, professional online networks, offline local networks and exploiting contacts with existing and preexisting clients. You are not going to compete with this. You need their help. All recruiters are not created equal. There is a wide range of types, specialists, personalities and recruiting organizations. No matter which one type you pick you need to find an individual or firm that is really going to get to know your business, culture, priorities and eccentricities. There is an advantage to actually interacting with a human being as opposed to a machine. There is no substitute for this yet.

I have worked with many recruiters in my time and have my own bias and prejudices. I like recruiters that dig in and really get to know the technical details of the platform, the personalities of the developers and managers and become familiar with the business model and competitors. You want someone that does their homework and is committed to not just showing you resumes. Get some references on your recruiter. They will become a real promoter and champion for you company. Make sure you get along with the recruiter, have a good rapport and good communication. Pick a recruiter that has recruiter for people like the people you are looking for. They will most likely have people in their stable that they can call on immediately. Most recruiters are not techies. So be careful about discounting one because they are not as fluent as you are in tech speak. They are communicators and sales people. If a recruiter believes in you and your team they will go a long way to sell your company. Make sure that get the import details and points. Tell them what companies are most likely to have your candidates. Keep tabs on them and make sure they are focused on your openings.

Good Luck finding talent and growing your company!!! Share your comments, experiences and successes with the rest of us.

Motivating Software Engineers

Motivating engineers is a touchy feely subject that engineers usually do not engage in. It is very important from an organizational perspective but by the very nature of the engineering discipline it is not a topic that gets the attention it deserves. This is a very important subject because most companies base their projections and business model on the underlying technology that supports the business. When engineers are motivated productivity increases, problems are solved more efficiently, turnover over is reduced, staffing becomes easier and ideas are generated that have a positive impact on the products a company produces. Motivating engineers is not the exclusive domain of the engineering manager. It is the responsibility of executives, managers, other departments and individuals within the organization to take into consideration the engineering perspective when establishing corporate culture, company events and business goals.


Clarity Of Purpose: Engineers like clarify and specifics when it comes to task assignments. The very nature of software engineering requires everything to be boiled down to a 0 and 1. This creates a culture of specificity that translates upward into goal setting. This clarity is not limited to product specifications. The engineers will want to know why they are engaging in a project, what is the end game and what is the organization trying to achieve from a business perspective. This will translate to buy-in and communication within the group and assure that the engineers understand the overriding goals of the project.


Focus: Software engineering is a tedious occupation that requires constant attention to detail rarely found in other occupations. It requires intense concentration during a development cycle to get a product developed properly. If the focus of the project is shifting, the goals keep changing or the definition of the project is in a constant state of flux then engineers will become frustrated. Commit to a project, stay the course, release the project and measure its results. Certainly change is a reality for all organization. However, if an organization is constantly changing product focus eventually this will lead to doubt about the decision making capabilities of the management team. Changing a products focus in mid-stream is especially demoralizing to an engineering team. Planning, design and coding will be wasted. No one wants to see an effort wasted on a consistent basis.


Early Stage Input To Process: Frequently engineers are brought in late to the development process. Goals are already set, business objectives are stated, some product requirements are established and assumptions are made about the time it will take to deliver a product. The engineers are then expected to react to these details and assumptions and provide technical details on how and when they are going to deliver. Engineers will see this as a disregard for their input. This lack of involvement results in a “why are we doing this” or “they really do not know what they are doing” attitude. Bring the team into the process early to understand goals, objectives, provide input and to get collective buy-in to the product.


Feedback: Both positive and negative feedback is welcome in a development group. Of course, you always have to be careful with negative feedback. When negative feedback is given it should be delivered in such a way that identifies an area that the engineer has control over and could have done a better job. Positive feedback should be given on a regular basis to make sure people understand what they are doing well and to reinforce the proper behavior.


Transparency: Keep the engineering team abreast of business activity, issues the company is facing, new strategic direction and activity in other departments. Engineers are bright people and naturally analytical. In the absence of information they will analyze and make assumptions. With only limited information they may make the wrong assumptions and translated them to the rest of the engineering organization. The engineers want to feel that they are a vital part of the company. If the management team is making decisions that impact the engineering organization they should make the engineers aware of these decision.


Game Play and Geek Culture: The use of the word geek is not meant to be derogatory. Engineers have their own way of communicating and having fun. In one of my assignments the engineering team had regular times during the week where we would play online multiplayer games such as World of Warcraft. The CEO would also participate in game play. This was a great way to bring the team together and to blow off steam. It was one of the better events that we had in the group. Warcraft was a game that developers could relate too. It was special to them and helped bind the group in conversation and healthy competition. In a more recent assignment we played online poker. Poker is not a developers game per say but it is a multiplayer game and does have the benefit of engaging other departments in a group effort.


The Power of Food – This may sound strange but the power of food and communal feasts is a way to keep engineers engaged and happy. Engineers spend hours and hours sitting in front of a computer monitor. Sometimes it helps to get them up and engaged with a larger community in a non confrontational way. A weekly or monthly food feast with various departments is a great way to facilitate communication and to collaborate in a casual setting. In addition, just having a regular snack and food stash is a great way to allow engineers to have a way of getting nourishment during the day. Engineers are often sequestered for hours and in some cases days working on a project. Not having to worry about how they are going to sustain themselves is a nice to have. It also demonstrates that the organization understands their situation and is supportive.


Engineers Love Challenges: Engineers are very competitive. This may seem strange because most of them may not engage in regular competitive sporting events. However, this does not mean that they are not competitive. They are intellectually competitive and want to be challenged in that way. They like to participate in team competitions. The concept of scrums or collaborative development is a manifestation of a team competition where a group works together to achieve goals. Engineers also like to solve complex problems and be recognized for these achievements. Managers at all levels of the organization should appreciate when a business problem requires a significant degree of intellectual horsepower to solve. This effort should be acknowledged.


In conclusion, motivating engineers is important for the health and welfare of organizations dependent on a technology platform and or product for the success of the organizations. Engineers are different culturally and intellectually. They require special attention to maintain their enthusiasm and commitment to an organization. Engineers are competitive and can also be social in their own way. The challenge for any organization is torealize these attributes and to explicitly address them to assure the success of an organization.

When The Agile Development Process Does Not Address The Business Model

I recently built a development team and development process around a very aggressive business model. The model could be described as a “marketing” centric model as opposed to a “product” model. In the midst of the organization and infrastructure building exercise I explored various development processes including XP, RUP and Agile. During the later stages of the organization’s growth I focused specifically on Agile to address some of the quality, speed to market and communication issues the organization was experiencing. After a lot of study and some trial and error it became obvious that Agile development was not the right fit. Much of this misalignment resulted from the forces being placed on the development organization by the business model and operational expectations associated with this model.

Short Cycle Development – The organization had an implicit expectation that changes to the production system were required on a daily basis. This translated into several pushes to production in a 24 hour period. Often product changes were pushed on Fridays and over the weekend.

Detailed Specification Requirements – The business owners wanted to know specifically what each feature would look like and were not interested in releasing “iterative” versions to incrementally add functionality to the application. This is directly correlated with the short cycle expectations and releasing product on a daily basis. With short cycles the product was difficult to break down into even smaller iterative bytes.

Quality Control - Quality was enforced by a QA department that worked from a detailed specification. Quality checking and an understanding of the change came after the initial development cycle using the specification as a guideline. Thus, the "waterfall" process at the backend of the process.

Aversion To Infrastructure Investments - The notion of investing in building a unit testing infrastructure was not a high priority. It was important to get product out the door so any investment in development resources not focused on direct product releases was discouraged. Also, the unit test infrastructure would have been best built at the initial outset of establishing the applications architecture. Coming back retroactively and adding this to the platform would have been very difficult.

Organizational Structure – This organization was a startup and leveraged individuals over a number of different projects for the purpose of preserving capital making it difficult to form true product teams where QA, PM and Development collaborated in defining, developing and testing the application.

The Scrum – It was hard to form a real scrum for a single release or product. The scrums turned out to be product update meetings on all outstanding projects. These were good meetings but not true “scrum” sessions. They were also hard to pull together because of the waterfall culture of the company. People had a tendency to meet and strategize within their organizations rather then cross organizationally.

In the end the development process evolved organically from the culture. It turned out to be a hybrid of RUP using Use Cases to cover usage models. Waterfall process was used to move the products through the cycle. The PM’s would define and build requirements; Development would build and submit to QA for testing and eventual release.

Was this the optimum process for this organization? Not really, releases were not always released on time. Some of this was due to the extreme need for speed leading to mistakes in specifying the features. Quality remained an issue because of the pressure to release and to the general lack of understanding of the impact of a change on the larger system. On the other hand rapid a short cycle release culture was institutionalized allowing for a rate of change to the production system that was relatively very impressive. Relative meaning, in relation to other development processes that dictate a more scheduled and less frequent release cycle.

In retrospect, one of the biggest mistakes made was to not build a unit test infrastructure early on in the architecture and design of the system. This would have allowed for a higher quality release to production while still maintaining a short development cycle culture.