Building Software In-House: Too Much Control and Flexibility (part 1).


As domain-specific software becomes more available, businesses face a dilemma: whether to acquire commercial off-the-shelf (COTS) enterprise management systems or to build them in-house. Companies choosing to create a product internally are often rewarded with flexibility and control over their development process and its results. However, when expanding, they can outgrow their ability to support the developed software.

Working as a programmer at a medium-sized logistics company, Si-Trans, in 2010, I witnessed the long-term implications of an initial decision to build an information system in-house. While this decision was appropriate in 1997 because COTS alternatives were scarce and inapplicable, it created a favorable climate for inconsistent, ad hoc management practices within the entire company, in particular, software creation and maintenance. These practices ultimately contributed to Si-Trans’ inability to see an opportunity in the early 2000s when it was feasible and advantageous to adopt a COTS-based solution. This solution would have scaled better for the company’s growth and would have helped avoid an outstanding technical debt in the old system. By the end of 2011, Si-Trans finally considered the acquisition of an off-the-shelf information system, after having suffered substantial financial losses from the protracted in-house development.

1. Si-Trans: Context and Business

With the advent of powerful and flexible business-oriented enterprise management systems, companies that do not possess considerable software engineering expertise got a viable and often practical alternative of acquiring commercial-off-the-shelf (COTS) systems instead of building in-house ones [17]. Commercial acquisition promises lower costs of ownership and lower development-associated risks at the price of losing control over what is developed [12]. At the same time, in-house development allows an organization to have total control over the created software, but it comes with typically higher costs and a risk of outgrowing the organization’s processes [6].

My experience is related to a company, Si-Trans, that experienced the hardships of in-house development. Having developed an internal information system over a period of 15 years, Si-Trans started out from reaping a competitive advantage from the system and ended up almost incapable of sustaining the development. In 2010–2011, I worked in the company as a programmer and closely observed the implications of building an internal system for a long timespan, in which circumstances and requirements had changed. After having lost money on fighting through the old system’s technical debt [1], the company decided to transition to a COTS alternative in late 2011.

This practicum goes through the chronological story of Si-Trans and evaluates its management’s strategic decisions in software development and procurement. Common understanding of the “buy versus build” issue, as it is expressed in software engineering literature, serves as a basis of the evaluation and reflection.

Before the narration dives into details, it is crucial to know the business model and organizational structure of Si-Trans, as these were major factors that determined successes and failures of the in-house development. The rest of this section is devoted to the description of the Si-Trans business.

1.1 The Business Model

Si-Trans is an international logistics company established in 1995–1996 in Moscow, Russia . It rose from the “primordial soup” of companies in the 1990s Russia when the idea of individual capital was spreading among the wide masses of Russian people. The founders of Si-Trans realized that they could exploit Russia’s geographical position and the global economic situation of that time. Specifically, they took advantage of Russia’s intermediate location between China, where tons of goods were produced, and Europe, where tons of goods were consumed. To earn money from connecting this demand and supply, Si-Trans started transporting cargo between China and Europe. As the company grew, it developed expertise in related areas, such as insurance and customs services. By 2010, Si-Trans provided the following services:

• Multimodal transportation of goods: businesses in Western Russia or Europe ordered a run of goods from a warehouse in China (e.g., in Hong-Kong, Beijing or Shanghai) to their location in Europe (e.g., in Germany, Romania, or Italy) . Then a Si-Trans employee analyzed modes and schedule to suit the client’s needs. After a contract was signed, a payment was processed accordingly, and the goods were shipped from China. The usual obligations of Si-Trans were finished when the goods were delivered to a warehouse of the client’s choice.
• Customs brokerage: as Si-Trans carried goods over borders of several countries, it gained skill in customs operations: handling documentation, estimating costs and schedules, and negotiating time constraints with government agencies. Si-Trans offered these services to other companies that would otherwise have to struggle with custom clearances themselves.
• Cargo insurance: insuring cargo that travels through several countries was and is not trivial because of local differences in legislation and common practice. After Si-Trans had built up related knowledge and connections with local insurance companies, it became possible to sell insurance services that help other companies avoid an overhead from handling individual country-based insurance agencies.
• Storage: Si-Trans owned and rented warehouses in China and Russia. Since extra storage space was usually available, it was possible to make money by subletting it to other companies. Si-Trans offered it as a separate service as well.

Si-Trans was built around the core service of international logistics, so geographical distribution of operations was inherent to the company from its very beginning in around 1995. The 2010 distribution of offices is shown in Figure 1. Although I do not have precise data about how Si-Trans was spread over countries before 2010, anecdotal evidence suggests that it was distributed among countries from the beginning.

Publications: Building Software In-House: Too Much Control and Flexibility (part 1).
Figure 1: Si-Trans’ locations and transportation examples as in 2010.

1.2 The Organizational Structure

The organizational structure of Si-Trans persisted over the years: regional divisions in Europe, China, and Russia reported to top management. Several independent units, such as accounting and finance, also reported directly to management. Figure 2 shows the structure of Si-Trans as of 2010. Unfortunately, I have no accurate information about what the structure of Si-Trans was before the early 2000s, but the source code and the database design I worked with assumed the same structure as in Figure 2.

Publications: Building Software In-House: Too Much Control and Flexibility (part 1).
Figure 2: The organizational structure of Si-Trans in 2010.

Top management was located in the central headquarters in Moscow—they were several nontechnical executives making strategic decisions. Legal and systems administration teams dealt with issues in all locations, and they were able to succeed because of their low workload.

Regional divisions handled everyday issues related to the main service—logistics. Transportation staff made sure goods passed customs, traveled in acceptable conditions, and went into the right hands. Client relations staff handled all communication with clients, analyzed transportation tradeoffs, and planned routes.

2. The Buy vs. Build Issue

This section describes the conventional engineering wisdom on the topic of buying or building software for business.

2.1 Approaches

Over the last decade, researchers and practitioners accumulated plenty of guidance on whether to buy software or to develop it internally [13]. We focus on the case when a company’s business goals are best accomplished with software, but the company does not plan to take advantage of selling the software. The general approaches with respect to buying or building are as follows [4, 14]:

• Build: create software organically—with a staff team of engineers. This is a fully internal option: the company performs all development phases itself, from analysis to deployment. This direction will also be called building software in-house.
• Buy: completely adopt an externally developed system. Although financial details might differ , in the scope of this practicum we will call this approach COTS acquisition or buying the software . It is essential to perform search, analysis, and selection for this strategy.
• Outsource: have a 3rd party develop software. In this case, a company creates a specification for the needed software and goes though a process of finding a contractor who would implement and potentially maintain the software.
• Hybrid: combine the above techniques at different stages. For example, a company may design an architecture and split the desired system into components. Afterwards, the company may acquire available components, develop the crucial ones in-house, and outsource the rest.

Clearly, there is a spectrum of choices that differ in how much software the company produces itself. Acquiring COTS for all needs and building everything internally are at the opposite ends of this spectrum. Choosing an exact point is a strategic decision for the company: it determines the company’s competitive advantage, expenses, and flexibility of other choices for many years into the future [11, 10].

2.2 Making Decision

The literature on how to choose between buy and build offers guidance on three aspects of this decision:

• What the common benefits and pitfalls of building and buying are [12, 17].
Building software in-house promises more flexible development, easier change of goals, and adaptation for an environment. However, building is generally considered to take more time and more resources to deliver a product, which might be not sufficiently tested or interoperable with other products on the market. Buying is believed to be less flexible because of a potential mismatch between an acquired system and the company’s needs, but it is also considered to have lower costs of ownership in a long term, shorter deployment schedule, and generally more reliable software.
• How fitness of a company/product pair for either buying or building should be estimated [15].
The commonly known factors to consider are following:
– Required time to market [6]: if a system is needed in the short term, buying looks more attractive because typically customizing and deploying a ready system takes less time than developing one from scratch.
– Presence of internal expertise [17]: a company that wants to build the system should have or hire staff qualified enough to do so. It is not only about technical expertise, but also about domain knowledge and management capabilities: adequate requirements have to be elicited and put down as a specification, and software should be assembled according to the specification.
– Availability of solutions [9]: COTS products in the market have to cover at least the most critical requirements to be considered. The more of them are available and the longer they have occupied the market niche, the bigger benefits from buying are. A higher degree of competition in the niche is considered a sign of more mature solutions provided.
– Risks of building vs. risks of buying [3]: failing to develop a working solution in-house is evaluated against over-relying on another company. Some sources state that in-house development is more predictable than relying on another company because all internal data is available. For example, a rate of development progress, staff working on a system, and the total cost of development are known when creating an organic system. At the same time, this data may be unknown about a company that provides COTS. Hence, that other company’s failure is harder to anticipate and accommodate.
– Stability of requirements [2]: if requirements for the system are expected to change and are not likely to be covered by available solutions in the market, building internally might be a better solution. In the organic case it is at least theoretically possible to evolve a system for the new needs, while many commercial solutions cannot be changed sufficiently.
– Presence of standards [12]: the more a subject domain is standardized, the less risky buying is. When standards are present, emerging software is more likely to adhere to the standards and interoperate with the acquired system. Also, standards are known to be a suitable basis to create a hybrid solution on.

• How each potential option affects a company [7].
To build software, a company may have to go through an organizational change: it may need to form requirements engineering, programming, and testing teams and provide for their communication with other units. Buying software may lock in certain processes and communication paths; therefore, the organization might change to follow the processes ingrained in the acquired software [12]. This might pose a risk for the company’s business goals because the ingrained processes might enforce not an optimal way for the company to be organized.
Apart from a potential organizational change, acquiring 3rd party software results in the dilution of control [17]: many companies contribute to the success of a system’s exploitation, so the control pattern becomes complicated. Since vendors make ongoing decisions, effort is required to keep the system in adequate operation. An apparent impact on the software procurer is the reduction of his control over the evolving software. This impact is often considered negative because the company needs to account for someone else’s interests and actions when planning its own strategy.

3. Initial Decision to Build In-House

During its first years, Si-Trans needed an information system to share information between its distributed branches. In 1996, a decision to build the system organically was made, as it is shown in Figure 3. This section relates this decision to the global environment in which Si-Trans operated.

Publications: Building Software In-House: Too Much Control and Flexibility (part 1).
Figure 3: The timeline: 1995-1996. The early days of Si-Trans.

3.1 External Factors in 1990s

When communism was officially dismantled in 1991, Russia faced a serious challenge of adopting a market economy. Not being culturally and organizationally ready for a sharp change in this direction, Russia had to go through a period of economic turmoil that lasted until the early 2000s. The country saw vast corruption, hyperinflation, decline of whole industries, problematic property privatization that gave rise to super-rich oligarchs, and national currency devaluation. In addition to its economic trouble, Russia went through several political crises. Not going too deeply into details, tension between the Executive and Legislative branches shook the whole government apparatus. The Judicial branch lagged behind the fast changes of the two other branches. Hence, a serious disconnect between the letter of the law and the actual way it was administered was typical of the 1990s.

This economic and political instability had strong ripple effects on individual businesses. It affected two major aspects of Si-Trans’ business routine. First, frequent changes in legislation and regulations altered, sometimes unpredictably, how everyday business issues such as taxes, certifications, and customs clearances were handled. Second, the transportation market was not stable: turnover of companies was very high, often due to illegal action from their competitors, e.g., corporate raids or arranged criminal cases. It was impossible to predict which of Si-Trans’ clients would stay or would go the next month.

The turmoil in Russia did not prevent Si-Trans from looking into business optimization. And so the idea of an information sharing system for remote collaboration was conceived.

3.2 Need for Information System

Due to its geographic distribution, Si-Trans needed a means of coordination between teams. Use of information processing software promised a huge leverage over telephone communication and emailing. There was also a potential to automate routine processes, such as report generation. Moreover, a system might store operations data for future reference and provide analysis and planning tools.

The quality attributes of concern were, presumably, stability—uninterrupted operation, security— data confidentiality and integrity, and performance—supporting an interactive mode for operators. The level of these attributes that Si-Trans needed was, as it often happens, ”just good enough”. The company just needed a system that could help with running operations and not hurt the business.

An important requirement was that the system adhere to Russian practices and regulations: personnel management, customs forms and declarations, service contracts with other companies, tax reports, handling finances, and so on. Also, Si-Trans could not afford to hire regular staff fluent in English in order to work with enterprise management systems developed abroad, such as SAP products, so localization was essential.

The alluring promises of business informatization pushed Si-Trans towards making the first step in obtaining a transportation support software system.

3.3 Decision to Build

In around 1996, Si-Trans adopted the approach of in-house development. The development of an information system started with a single developer. According to common knowledge among Si-Trans employees, this person did not have software engineering training.

The system had a thick client architecture: a single central SQL database was established in the headquarters in Moscow; thick clients were distributed over locations in different countries so that Si-Trans employees could exchange data through the database. A thick client was a Windows application with a traditional point-and-click GUI. Thick clients of Si-Trans had complicated business logic wired in their source code. The big picture, though, was quite simple: clients sent SQL queries to the database and received datasets in return. In the beginning, the system offered a basic feature of viewing and editing several database tables with cargo movement information.

3.4 Interpretation: Building In-House as an Adequate Response

My overall interpretation of the 1996 events is that, despite lacking a clear vision of requirements and alternatives, top management of Si-Trans intuitively went in a reasonable direction for the context they were in. There was no explicit decision of committing to internal development as opposed to relying on another company to provide an enterprise management system.

Choosing between adopting COTS and in-house development was easy because there was no adequate commercial solution present on the market. Had the solution been present, it would have made more sense to go with in-house software production anyway. There are several reasons:

• An unstable and volatile environment: the evee-changing environment produced a lot of requirements drift. How many clients do we serve? What rate of transportation will we have in 6 months? What regulations on customs clearances will be passed in the next month? How will political climate change Russia’s relations to neighbors? All these questions might have had unpredictable answers, so the company needed a lot of flexibility. In-house development provided the flexibility.
• Absence of strict time limits to produce the solution: the company was left to its own devices. Given the chaotic spirit of that time, there would have been no disaster if the system had been deployed 3 months later. The information system project started as an experiment, without the desire of top management to invest up-front into it.
• An immature domain of enterprise management systems in Russia: to my knowledge, no enterprise management system was an accepted leader at that time. No related standards were recognized either.

The architecture chosen for the homegrown information system was, in my opinion, adequate for the needs the company had in 1996 because of:

• Existing technology support for the thick client architecture: popular implementation frameworks of that time favored the client-server paradigm. Hence, the initial development investment was low, and the system was quick to deploy.
• Few employees at Si-Trans: there were no more than 20–30 system users in the company. Therefore, the homegrown system could easily meet the performance needs.
• Small implementation size: the system’s code was, apparently, not large in the beginning. Also, the size did not grow fast with only one staff programmer. As a result, stability issues with the system were manageable.
• Simplicity of the initial functionality: in the 1990s, the internal system provided only basic support for information exchange with only few complicated business rules. Therefore, these rules were easy to change.

Software development in Si-Trans started in a constantly changing environment with little guarantees. Even existing laws and regulations were not guaranteed to have been observed. All that gave a rise to the management style of Si-Trans that, I believe, defined the future of the company. There are several characteristics to this style:

• Inconsistencies in management: a decision made on day X may contradict another decision made on day X+1. For instance, one top manager decides to deploy a system at a new location immediately, while another top manager overrides in the next day saying there is no hurry, but the first manager does not know about this decision. This situation produces utter confusion among software and administration teams.
• Strive for flexibility in decisions: if several alternatives arise, it is likely that the one that minimizes commitment and cost will be taken, not the one that is advantageous in the longer term.
• Experimentation: many initiatives are started by top management not out of need to cut expenses or meet business goals, but because of their fear of missing an unknown opportunity. This leads to spending time in experiments that spread resources, but can find something new or missing in the context of a volatile environment. Insufficient planning: Si-Trans’ management was very reluctant to do long-term analysis, estimation, and planning. Many decisions were reactions, not preventions, and they were aimed at fixing situational problems that often were symptoms of deeper issues.
• Strive for control over fine-grained details: managers looked for absolute control over lowlevel details of how Si-Trans worked. Specifically, they exercised a lot of fine-grained control over the software process. For example, a top manager might have envisioned a particular UI (that actually contradicted the conceptual model of the application) and did his best to make sure the UI was implemented, with little respect for software engineers’ reasons for objecting.
• Reluctance to invest into long-term benefits: many decisions were as if the company would exist for merely several months. For example, no documented analysis of Si-Trans’ computing needs has even been carried as it was viewed as a “too fundamental” process that would yield no immediate profit to the company’s main revenue activity—selling transportation services.

4. Changes in the COTS Suitability

Si-Trans survived the chaos of the 1990s and was successful in its business during the 2000s. As the early 2000s passed, changes occurred in Si-Trans, its environment, and the information system. This section describes events that happened in the interval approximately in 2002–2006, as shown in Figure 4. Further statements about the history of Si-Trans are based on the substantial anecdotal evidence obtained from Si-Trans employees and on information extracted from code. However, the changes described below occurred over several years, so I will not give any precise time reference for them.

Publications: Building Software In-House: Too Much Control and Flexibility (part 1).
Figure 4: The timeline: 1995–2006. Change of circumstances.

4.1 Changes in the Business Environment and the Company

In early 2000s, the legal environment of Si-Trans became less fluid and more predictable as a result of Putin’s stabilization strategy. Common practices at customs, tax agencies, and financial audit agencies solidified. The main outcome was that report forms became fixed and, therefore, they could be generated automatically by software. The risk that forms will radically change decreased.

The market for logistic services also became more solid: transportation companies in Russia and Eastern Europe were either driven out of the market or made a solid position there. The set of Si-Trans’ clients included several companies with permanent relations. Therefore, it became much easier to predict type and volume of demand. Competitors and their strategies also became more apparent and amenable to analysis and prediction.

By 2005, the Si-Trans staff had grown to approximately 100 people. They were organized into the same structure as described in Figure 2: regional divisions handled client interaction and transportation; other concerns were handled centrally in Moscow. Every employee who worked with clients and transportations had to use the information system, so the number of system users grew drastically.

Despite the company’s growth and the stabilization of the major external factors, the management culture remained the same in the company: top management acted as if there was still the same degree of uncertainty as in the 1990s. Even in 2010–2011 I observed the same style as the company seemed to have in the 1990s (see Section 3.4).

In addition to the business and organizational context, the information system’s evolution is another important factor in the COTS suitability.

4.2 Changes in the Internal System

The organic information system grew steadily over 10 years. The situation in 2005 was:

• Apart from the essential information support on transportations, customers, and employees, the system offered more complicated functionality to exchange data about contracts, payments, money transfers, and warehouses.
• The number of system users increased to approximately 100.
• Regardless of the implementation growth, no documentation apart from source code comments was created. The high-level design knowledge was carried in the heads of software engineers.
• The architecture remained the same: a single database handled requests from thicks clients spread over the continent of Eurasia.
• The technological platform on which the system was built grew old; new versions offered attractive features (e.g. transaction support), but migration attempts were not successful because of technical difficulties.

In addition to these internal changes, it is significant that a COTS alternative to the internal information system emerged.

4.3 Changes in COTS Availability

In 2002–2003, a significantly advanced version of a COTS product for enterprise management, 1C:Enterprise [5], was released. It featured:

• Ready-to-deploy components for personnel management, accounting and finance, wares management, contact management, document management, and tax report generation. Their flagship component was the bookkeeping support, which was widely used and recognized in Russia.
• Different options for client-side applications. Thick, thin, and web-based clients were available.
• A more scalable architecture. It was possible to decouple data storage and client request processing. Also, it was possible to have several databases and client processing servers in order to distribute requests between them.
• A platform that comprised a domain-specific language (DSL), an API for common functions, and a development toolkit. All of that could be used to develop new components and to integrate them into the 1C system. 1C components could communicate with other 1C components through calls in the DSL as well as with components based on other technologies, such as .NET, through COM interfaces.

By 2004–2005, many Russian companies have been making wide use of the 1C platform. As a result, the demand for 1C programmers grew and drove their salaries up. The job market replied with a higher presence of 1C expertise by 2005. Nevertheless, Si-Trans ignored the success of 1C:Enterprise and continued to develop the internal system.

4.4 Interpretation: Missing Out on a Beneficial COTS Alternative

Over these 10 years, critical factors that influence the “COTS vs. build” decision changed. If Si-Trans had to make this decision back in 2005–2006, it would have been more reasonable to base the information system on the 1C COTS for the following reasons:

• The legal and business environments have stabilized. There was no point of being extremely flexible anymore. Moreover, long-term investments into COTS were much less risky in the light of knowledge that Si-Trans will not cease to exist in the next month.
• Si-Trans’ internal information system became obsolete because it reached its architectural limits. The size of the user base grew to exceed the ability of the architecture to support the required performance.
• The in-house system grew beyond the software team’s ability to support it. As the system increased in size, its technical debt piled up because of a number of factors that we will discuss further below. The source code had grown too big to be effectively handled by a small team that was under constant pressure from the management.
• The 1C platform was reliable and tested enough to have been adopted. It also took a place of a de-facto ERP standard in Russia. Had Si-Trans bought into 1C in 2006, they would have (a) accommodated for the company’s growth, (b) avoided subsequent issues with the system developed in-house, and (c) taken the control over software development from the hands of the chaotic top management.

According to the software engineering wisdom outlined in Section 2, these facts indicated that in 2005–2006, it had been appropriate to switch to the 1C software. However, top management made a different choice—and chose to stick with the initial in-house approach. The reason for that was, in my opinion, that the transportation services, which were the core of Si-Trans, lacked any support in 1C: it had no data model or user interface to operate transportation. And the management probably decided that implementing it there would be too much work. Nevertheless, I think that the other alternative—to continue maintaining a lot more modules than just the transportation one in-house—was far less practical at that point.

to be continued..

© Ivan Ruchkin, Institute for Software Research Carnegie Mellon University, May 9, 2012.

[1] Eric Allman. Managing technical debt. Queue, 10(3):10–17, March 2012.
[2] Carina Alves and Anthony Finkelstein. Challenges in COTS decision-making: a goal-driven requirements engineering perspective. In Proceedings of the 14th international conference on Software engineering and knowledge engineering, SEKE ’02, pages 789–794, New York, NY, USA, 2002. ACM.
[3] Lisa Brownsword, Carol A. Sledge, and Tricia Oberndorf. An activity framework for COTSBased systems. Technical Report CMU/SEI-2000-TR-010, Carnegie Mellon University, Software Engineering Institute, 2010.
[4] David Carney and Fred Long. What do you mean by COTS? Finally, a useful answer. IEEE Softw., 17(2):83–86, March 2000.
[5] 1C Company. 1C:Enterprise 8 - the system of programs.
[6] Allen Eskelin. Technology Acquisition: Buying the Future of Your Business. Addison-Wesley Professional, 1 edition, June 2001.
[7] M. D. Feblowitz and S. J. Greenspan. Scenario-Based analysis of COTS acquisition impacts. Requirements Engineering, 3(3-4):182–201, March 1998.
[8] Brian Foote and Joseph Yoder. Big ball of mud., 2000.
[9] Patricia K. Lawlis, Kathryn E. Mark, Deborah A. Thomas, and Terry Courtheyn. A formal process for evaluating COTS software products. Computer, 34(5):58–63, May 2001.
[10] Jingyue Li, Reidar Conradi, Odd Petter, N. Slyngstad, Christian Bunse, Umair Khan, Marco Torchiano, and Maurizio Morisio. An empirical study on Off-the-Shelf component usage. In Industrial Projects. Proc. 6th International Conference on Product Focused Software Process Improvement (PROFES’2005), 13:13–16, 2005.
[11] Jingyue Li, Reidar Conradi, Odd Petter N. Slyngstad, Christian Bunse, Marco Torchiano, and Maurizio Morisio. An empirical study on decision making in off-the-shelf component-based development. In Proceedings of the 28th international conference on Software engineering, ICSE’06, pages 897–900, New York, NY, USA, 2006. ACM.
[12] B. Craig Meyers and Patricia Oberndorf. Managing Software Acquisition: Open Systems and COTS Products. Addison-Wesley Professional, 1 edition, July 2001.
[13] Abdallah Mohamed, Guenther Ruhe, and Armin Eberlein. COTS selection: Past, present, and future. In Engineering of Computer-Based Systems, 2007. ECBS ’07. 14th Annual IEEE International Conference and Workshops on the, pages 103–114. IEEE, March 2007.
[14] Maurizio Morisio and Marco Torchiano. Definition and classification of COTS: a proposal. In Proceedings of the First International Conference on COTS-Based Software Systems, ICCBSS ’02, pages 165–175, London, UK, 2002. Springer-Verlag.
[15] Vijay Sai. COTS acquisition evaluation process: The preacher’s practice. In Proceedings of the Second International Conference on COTS-Based Software Systems, ICCBSS ’03, pages 196–206, London, UK, 2003. Springer-Verlag.
[16] Joel Spolsky. Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity. Apress, August
[17] Kurt Wallnau, Scott Hissam, and Robert C. Seacord. Building Systems from Commercial Components. Addison-Wesley Professional, 1 edition, August 2001.

[Total: 1    Average: 5/5]

Leave a Reply

Your email address will not be published. Required fields are marked *