Archive for December, 2007

Why Choosing the Right Technology Matters

December 31, 2007 10 comments

Choosing the Right Technology can Make or Break a Ship DateThere is a lot of debate these days about whether or not the technology behind a product matters. Does it matter whether you choose C# or Java as your programming language? Does it matter if it’s on Windows or Linux? Does it matter if it’s MS SQL or MySQL?

The conventional wisdom is to view this issue from an end-user’s perspective. To the end user, the technology doesn’t matter. It’s the product that’s important. If the product is good, the users don’t care if it’s written in Java, C# or Cobol. They just want something that solves their problem.

But a lot of software companies and IT shops are using this argument to imply that the technology they choose for development makes no difference. Who cares if they choose Perl or Ruby or C#? After all, the end users don’t care, so why should it matter to them?

The fact is, choosing the right technology matters more than most people think and could be the difference between shipping a great product and creating vaporware. Today, it would be comical if an IT shop chose Cobol as their development language or banked on FoxPro as their database backend for new projects. If the technology didn’t matter, these should be sound choices, but it’s obvious to most in the software business that banking on these particular technologies would have disastrous results. So the question is why? Why does choosing the right technology matter?

There are a number of reasons:

  1. Attracting the Right Talent – By far the most important aspect of choosing the right technology is making sure you can attract the talent that can get the job done. If the best brains in the world, the ones that can get jobs anywhere, avoid your project because of the technologies you have chosen, you’ll be left with second tier software engineers who are forced to accept a position purely for financial reasons. As tough as is to find truly talented people in the US job market today, you want every advantage you can get. So, choose the technology that will attract the best possible talent.
  2. Time to Code – The amount of time it takes to write a solution to a problem plays a huge factor in choosing the right technology. If you plan to write a program that will be used in the 2008 Super Bowl on February 3rd and you are starting to write code now, you better choose technologies that can provide huge shortcuts in writing the code. Delivering a solution on February 4th, no matter how good, is completely worthless. On the other hand, if you are choosing shorter coding time when time to market is not an exceptionally important factor, you may be picking a technology that does not scale well as the application grows in popularity.
  3. Execution Speed – As computers get faster, there’s less and less concern with the execution speed and hardly any thought is given to which technology should be chosen based on this criteria. But talk to any serious game developer and they’ll set you straight about the importance of execution speed of their code and why this factor alone has kept them one generation behind on the latest language developments. When C became popular, game developers were still doing assembly. When C++ was big, they finally made the switch to C and while C# and Java have taken over, games are still largely written in C++. The reason? Execution speed.
  4. Code Maintenance – Choosing the right technology from the standpoint of code maintenance can mean the difference between longevity and M.C. Hammer. If the code cannot be easily maintained, enhanced and expanded, it will collapse under its own weight.
  5. Future Support – Will it be around in the future? This is a tougher question to answer, but if the future support of a technology is largely in question, it might be smart to avoid it. If a technology does not hit the mainstream, it will be harder to find talent and there will be a lack of state-of-the-art development tools, affecting time to code and execution speed. Choosing popular technologies that are well supported by the industry and profitable companies can be an easy way to avoid future pitfalls.

Although the casual gamer enjoying a video game couldn’t care less if the game he’s playing was written in C++ or Python, the success of the game largely depended on the chosen technology. That’s why you’ll find larger more sophisticated IT organizations care a great deal about the underlying technology of the products they choose. They want to make sure the future viability of the products and companies they choose are sound.

At Axosoft, our choice to adopt Microsoft .NET and SQL Server as the technologies of choice has given us a significant competitive advantage providing us an edge in each of the 5 categories mentioned above. From attracting the right talent (developers often leave their jobs just to use newer, more exciting technologies) to shorter time to code to execution speed, code maintenance and future support. In each of these categories, .NET provided Axosoft with a significant competitive advantage allowing us to grow faster and provide a more solid product.

Categories: Development, Team, Tools

Rules for Being a Green Software Engineer

December 24, 2007 8 comments

Yes, Develpers CAN be More Green - it’s our ResponsibilityRecently, I got a link to The Story of Stuff by Annie Leonard. This is an amazingly well done 20-minute video about how stuff is made, sold and disposed. She does a phenomenal job of putting the Story of Stuff together and selling the viewer on the importance of being Green. If you only have 20 minutes, I’d rather you watch her video than read this article, so go do that if you haven’t already.

Then I got to thinking, as software engineers, what’s our responsibility for being green? I did a couple of searches and ended up with nothing. The general view appears to be that software developers are automatically green. After all, how could software not be green? It’s just a bunch of bits, right? Software hardly has an environmental impact, or so is the consensus.  Can software be any more green than it already is?

As I thought more about the subject, I realized that in fact there is a huge variance in software greenliness (new word?).  The notion of green has always existed in software development under a different name: “Simple!”  Yes, simple, is the word we have used to describe the most green software in our industry and some of the most successful software products of all time have been the greenest solutions. I’ll get to some examples in a minute.

But software developers don’t think in terms of developing green software.  On the contrary.  Because we assume all of our solutions are by default green, we end up doing things that have a huge negative environmental impact without realizing it.  As software engineers we rely heavily on a few fundamentals to help us determine the best possible solution:

  • Moore’s Law – By far, the most influential theory on software development for more than 4 decades has been Moore’s Law. Not truly a law of nature or science in the traditional sense, Moore’s Law was simply an observation based on the historical trend of integrated circuits approximately doubling their number of transistors every couple of years. Faster, cheaper and smaller computers being just around the corner has been the most perfect argument for writing slower, bloated and more expensive software for millions of developers over the years. I confess, I have been one of them.
  • Cost of Development – As software engineers we are taught to do cost analysis in the following way:

– Algorithm X takes 1 month to develop and takes 1 minute to finish its calculations
– Algorithm Y takes 2 months to develop and takes 30 seconds to finish its calculations
– The resulting algorithm will be run thousands of times every day, enough to keep at least one or two servers extremely busy.
– Which algorithm should we choose?

We would do a quick cost analysis and conclude that 1 man-month of a developer’s time (in the US) costs at least 2 or 3 times more than an additional server. It would be hard to argue for choosing Algorithm Y when the up-front hard costs are 2 to 3 times as much as Algorithm X.  So the slower, less green, Algorithm X wins.

  • Laziness – As software engineers, we hate solving the same problem over and over again, so we build libraries of code and reuse other libraries as much as possible. This is generally great and very green! But, increasingly, we rely on 3rd party components that are thousands of times larger than the portions we actually want to use. As a result, we ship a product that requires ten times or a hundred times more disk space and memory than if the product was developed completely in-house. Of course, developing completely in-house could mean you’ll never finish the product and is not practical, but like everything else in life, there’s probably a good balance that can be maintained that makes sense for the project.

We are taught these things in school and at work. Being efficient from an economical standpoint, not a coding one, is the most important rule. Laziness and not reinventing the wheel at all costs is a trademark of a software engineer’s mentality and we can always rely on Moore’s Law to automatically solve our coding problems within a couple of years. By following the traditional wisdom, software engineers can save a little on development time, but very directly we are forcing the rapid adoption of newer, faster PCs with more memory and disk space.

We, as software engineers, are the number one marketers of hardware. We help PC manufacturers sell hundreds of millions of PCs every year just so users can run our software at a reasonable speed. That’s why when the ship-date of a product like Windows slips, stock analysts lower the estimated sales of Dell and HP. But it’s not just Windows that helps sell hardware – Windows just happens to have the most impact because it’s the world’s most popular software application. The new Windows Vista Flip 3D feature that allows you to switch between apps will probably be responsible for the sale of millions of new machines because of how painfully slow it runs on older systems.  This new feature of Vista is by far the most Visible – it’s even in the Vista commercials – so it will be the first thing that any new Vista user will want to try.  When they realize it doesn’t run on their machine, it’s time for an upgrade.

So as software creators, we are largely responsible for the adoption of new hardware. The smallest things that we do can make a big difference. We can’t simply wash our hands free of the environmental responsibility and put the blame on the hardware guys. Sure they want to sell more hardware, but we’re essentially their free sales force.

Rules for Writing Greener Code

I propose a set of software development guidelines for developing greener solutions:

  1. Choose Faster Code over Future Hardware. Yes, if you wait 2 years and run your code on a future device, it will run twice as fast as it runs today, but that’s exactly the wrong attitude. To be a green developer, don’t use the fastest machine you can find as your acceptable performance benchmarking system. Instead, use a machine from 2 or 4 years ago with less memory, slower CPU and smaller hard drive. If it can run on that machine with acceptable performance, your contribution to the rapid replacement of hardware is significantly less.
  2. Include Environmental Costs in Your Cost Analysis. You might find that writing slower code and buying more servers costs a lot less than the cost of another month of development, but don’t forget the hidden costs of more servers. These days the data center electricity alone that a server uses in a given year can cost as much or more than the server itself, not to mention rack costs, cooling costs, bandwidth costs, software costs and the environmental impact of all the materials and manufacturing processes that goes into creating the server itself.
  3. Be Memory Conscious. With most developer machines having 2 or 4GB of memory these days, developers often forget that there are hundreds of millions of PCs out there with just 256MB of memory (or less!). Even 256MB is an unbelievable amount of RAM. I couldn’t imagine having that much memory on a computer at the start of this decade and now I have 2GB! It’s because developers use memory as if it was free. The argument is that memory doesn’t cost anything. You can pickup 1GB sticks for under $100! The problem is for a large number of machines that are not capable of having 1GB of memory, you need to replace the entire machine and guess what happens to the old machine?
  4. Build in-house When Possible. Using 3rd party components and external controls can be a great way to save time in the development of an application, but make sure you’re not using 100MB worth of components for 1MB of gain. If the ratio of things you use in your 3rd party controls to things you don’t use is 1:100, that’s bad. It’s not just bad for the environment; it’s even bad for your end-user experience.
  5. Go Back and Solve it Again. Every developer knows at least a dozen areas of their software that they could have coded more efficiently. Often the performance of re-solving critical areas can gain an order of magnitude in performance improvements. But we never go back to do it again because we’re busy adding the next new feature. Going back and solving problems we have already solved might seem like a waste of time, but it’s often very satisfying to cut down hundreds of lines of code to just a few lines and make it much much faster.

How Coding Green Translates to Shipping Great Software

So you might be asking yourself how do these rules relate to Shipping Great Software OnTime? To answer that question, let’s take a look at some of the characteristics of green software:

  • Simple – The more Green a software application is, the simpler it is. So if two products can solve the same problem equally well, the greener solution will generally win. Examples include Google Search beating Alta Vista. Gmail beating Hotmail and Yahoo Mail. Flickr beating virtually all other photo sites at the time. The trend is clear.
  • Fast – Greener software is going to execute faster and as a result enjoy faster adoption. Again, given the choice of two products that solve the same problem equally well, the one that executes faster will win. A great example here is the rapid and surprising adoption of FireFox. Although it still has not beat IE (a product that ships with the OS, giving it a significant marketing advantage), the adoption of FireFox has been a phenomenal and surprising success. Between IE and FireFox, clearly, FireFox is the greener tool which runs faster and consumes significantly less resources. When you ask a FF user why he or she switched, the number one reason is that FF is much faster.
  • Lower Resource Usage – Greener software takes less system resources to execute. Again, given the choice of two products that solve the same problem equally well, the one that requires less resources will be preferable. Although FireFox can be used as an example again, I’m going to use the example of Apple’s OS X. As far as operating systems go, OS X is definitely greener than Windows. The latest version of Apple’s OS X Leopard runs well even on a PowerPC G4. That’s a chip that’s about 4 generations behind today’s latest CPUs. That would be the equivalent of getting Windows Vista to run on a Pentium 3. When you ask recent “switchers” from the Windows platform to OS X why they switched, a recurring theme is that OS X is faster, more reliable, it’s not as choppy and things just work. Lower resource usage is a significant advantage of OS X in this case and you sure don’t see a lot of people switching the other way to ask why they switched.

I suspect that some of you might want to ask me “then why didn’t DOS beat Windows? DOS is clearly the greener OS.” The answer is that the solution has to solve the problem “equally well.” DOS, although greener than Windows, was also single-threaded and provided an awful text-based interface. It was not intuitive to the average user and was limiting in hundreds of other ways. So DOS did not provide an equally good solution to the OS problem.

Writing greener software could be a significant competitive advantage, and as a byproduct, it could be better for the environment. It seems to me like a big win all-around.

What’s the Developer’s Incentive to Ship?

December 17, 2007 5 comments

Developers Must have an Incentive to Ship in order to Ship Software On TimeThe company always has a substantial incentive to ship. Usually, it’s financial. If you don’t ship the software, you can’t sell it. If it’s an internally used tool or a line of business application, then the company’s incentive to ship is to increase user productivity (again a financial incentive). To the company, shipping the software affects the bottom line and the incentive to ship is clear.

But what’s the incentive to ship for the software developers? Those are the guys that control the real ship date.  In nearly every company I have ever seen, there is virtually no incentive to ship for the developers. In fact, in most companies, developers have an incentive not to ship! Sure, you can argue all you want that if they don’t ship, they risk the chance of losing their jobs as the company might suffer layoffs. Theoretically, improving your company’s financial well-being so you can keep your job should be a big incentive.

But Windows Vista didn’t ship for 5 years, 3 years later than the original plan. How many developers lost their jobs? Zilch. Plenty of companies are financially secure enough to withstand slipping ship dates without resorting to layoffs. Whether the software is for internal use or if it’s the core product that the company sells, developers don’t feel much pain from slipping ship dates. As the ship date continues to slip more and more, the sense of urgency, importance and chaos continually increases, adding some spice to an otherwise boring job. So there could even be hidden incentive not to ship. That’s a flawed system.

If a developer does the identical work the day after the software ships as the day before the software ships, from the developer’s perspective, shipping software is a non-event. After all, what’s the big deal about shipping software if I’m going to continue to do the same thing I was doing yesterday? Some individual team members are independently goal driven to ship. Hopefully, that’s the makeup of your team. But if I had to guess, judging from the norm of slipping ship dates for software projects everywhere, I suspect the vast majority of teams are made up of developers who are not overly anxious to ship software. What can you do?

Building an Environment that Encourages Shipping

Google is famous for the “20% time” it gives its engineers to work on projects they like. The way this works is that engineers are allowed to spend 20% of their time on whatever project they want, not necessarily the one that the company is banking on. Ask any engineer what they think of Google’s 20% time and they’ll say something that resembles “awwweeeesome!” But ask a manager or an executive of any company about Google’s 20% time and they are filled with fear. Fear that something like that would cut their productivity by 20% – how could they possibly afford that? The typical executive might even think Google is leaving productivity room on the table and at some point they could eliminate the 20% time and improve productivity by 25% (going from 80% to 100% is a 25% increase for those of you keeping track).

That’s a short-sighted view. Here’s why:

Most engineers at Google “save up” their 20%-time until the appropriate time in their main projects when they can work on their fun projects. Take a wild guess as to when the appropriate time to work on their 20% fun project is. You guessed it. It’s immediately after their main project ships!

Now imagine you are an engineer who [thinks s/he] has a brilliant idea. Over the past 8 months, you have saved up 30 days of 20%-time to work on your brilliant idea, but the only way you can start working on it is if you ship your main product!

How driven are you going to be to ship your project as soon as possible when you know your fun project won’t start until your main project ships? Are you going to allow scope creep? Are you going to work on that cool new feature you thought of that nobody cares about or are you going to hammer out the features from your todo list? Now you understand why Google’s release cycles and continuous application improvements have been relentless and have far outpaced the industry average.  They have a pool of engineers who are eager to get on with their own projects and the only way to do that is to ship.  Now that’s motivation!

We do something very similar at Axosoft. We never called it 20% time. We just called it a “fun side project.” After major releases of OnTime, we generally brainstorm and come up with a number of side projects that developers want to work on. They can do whatever they want. Software, hardware, web apps, automatic tuna sandwich maker, whatever. Then we spend the next 30 days working on fun projects.

This is the equivalent of taking a vacation, but rather than being stressed by the typical airport security, hotel and other vacation-related nightmares, you actually get to do something you love! For most developers it’s even better than a vacation! Software engineers love to build stuff.  Most of us get a tremendous amount of satisfaction from seeing ideas come to life.  The more exciting the ideas, the more satisfaction we get and nothing is more exciting than our own ideas.

It’s easy to provide a good incentive for developers to ship.  Just don’t think of it as a loss in productivity!

You May Not Know the Business You Are In

December 10, 2007 2 comments

It’s Important to Know if You’re in the Sailboat Business or TransportationHere is a simple question:

  • What is the business of Seagate and Western Digital?

If you confidently answered “Hard Drives!” you’d be wrong.

Unfortunately, it’s clear that both Seagate and Western Digital themselves define their business as the “hard drive” business. How short-sighted. It’s highly unlikely that I will continue to own a hard drive within 3-5 years. Neither will you. Within 10 years, it’s unlikely that anybody will be purchasing hard drives for any purpose.

Why? Because there will be better, faster, lower power consuming alternatives with no moving parts. These alternatives exist today. Flash comes to mind, but price has been a barrier. While flash memory capacity is doubling every 10 months, flash prices drop by half. Hard drives have had a good 50-year run and Seagate is clearly in the hard drive business. Even though it’s clear what the future holds, Seagate and Western Digital don’t seem to be making the right moves to position themselves appropriately to take advantage of the disruptive technology that awaits them.

If I owned any Seagate or Western Digital stock, I would dump it now.

Flash is a disruptive technology. It’s a lot like what motor boats were to sail ships in the 1800s. Motor boats could go much much faster, but they were relatively small and their range was extremely short. Sailboat makers thought they were in the sailboat business and completely ignored the motorboat business, seeing them as just a short-range toy. Of course, over time, motorboats became better and their range eventually had the ability to cross the Atlantic. As a result, none of the sailboat manufacturers of the time were able to survive this disruptive change while motorboat producers thrived.

The problem was that they were all in the transportation business, but they didn’t see it that way. The people purchasing sailboats didn’t care about sailboats. They cared about getting people and merchandise from point A to point B as quickly and economically as possible. Over time, motor boats did a much better job. Eventually, airplanes did a better job for carrying people and the transportation of people via motorboats business also died. Today’s cruise liners are in the entertainment business, not transportation.

There are, of course, numerous other examples. CDs to tapes, MP3s to CDs, DVDs to VHS, but for now, let’s get back to Seagate, hard drives and flash. So is the Hard Drive market slowly going to transition to the Flash market? The answer is no. The storage market will remain the storage market.

People in need of storing information digitally will store it wherever is most convenient, fast and economical. Sound familiar? Do you really care about hard drives or do you just want to store your files? If the web or Google could store your files as conveniently, fast and economically as a hard drive, that’s where you’d store your files. But before we get to web storage, Flash will beat Hard Drives. Hopefully Flash memory makers will not make the mistake of thinking they are in the Flash business. Eventually something like DNA-based storage (or something entirely different) will beat out flash. Anybody in the flash business will go out of business, but the storage business will continue to thrive and expand.

What Business Are You In?

If you are a Software Engineer, don’t call yourself a C# developer or a Java developer. That’s the equivalent of Seagate being in the hard drive business. What happens when nobody needs a Java or a C# developer anymore? If you think that can’t happen, just look at all the Cobol and Ada developers today. How many do you know?

The same applies to your business. It’s time to think long and hard about the business your company is in. At Axosoft, when I released OnTime V1.0, it was a bug tracking application. Most competing companies who create a bug tracking tool see themselves in the bug tracking business. Some venture to say it’s a project management tool. I’ve always viewed OnTime as a tool to help software teams ship software on-time and not as a bug tracking application.

That view has lead us to build requirements management, help desk and now wiki inside the same product. It’s now obvious that OnTime is not just a bug tracking tool, or just a project management tool, but a tool that helps software teams ship great software. The focus is on driving the team to ship.

When trying to determine the business you are in, think of the problem you are solving rather than the way in which you are solving it. If you make MP3 players, you’re in the portable entertainment business. MP3 just happens to be a short-term technology that delivers digital music in an efficient way, but eventually, there will be a better way to deliver portable entertainment and everybody who is in the MP3 business will die. People will always continue to need a solution to their portable entertainment problem. Nobody has an MP3 player problem.

To create great software and to continue thriving, it’s important to know your business. To be alive 10 years from now, Seagate needs to continue being in the storage business and not the hard drive business. It’s crucial to know the difference.

Outsourcing is for Dummies

December 3, 2007 11 comments

Putting Space Between Parts of Your Team is a Sure Way to FailLet’s get one thing out of the way fast: There is no possible way to build and ship quality software on a tight schedule by outsourcing the development, period. If you are in the business of software, then be in the business of software and suck it up and build a team that can write the code. Outsourcing your primary application development is the equivalent of outsourcing the defense of a country. Here’s the primary thing you are admitting when you outsource:

By outsourcing the development of your software, your company is admitting that another company is better than you are at creating the very product that you want to create. You’re also admitting that they can do it cheaper and they can do it better than you can while still making a profit selling it back to you.

If that’s true, then why are you in the business of building software? You should be selling dogfood or cat litter. If you are in the business of selling dogfood or cat litter, then great, continue outsourcing. But even, a company that by any measure is in the “retail” business, builds their own technology and they consider it one of their primary business advantages. If considers it a major advantage to build their own technology and doesn’t outsource its development, then why would you even consider it?

Outsourcing breaks some of the primary laws of building great products. To build a great product, you must have a great team. Notice I didn’t say “you should” or “it would be nice to” have a great team, but rather you must have a great team. A team is inclusive of the designers and developers and testers and trainers and support personnel! If you think that the designers can throw the design over the wall and have the developers give them back a great product, you’re sadly living in a dream world. Although the threshold of importance is substantially reduced with each of the latter items (such as testing, training and support), the quality of those items are also substantially reduced when those items are outsourced.

Lets take a closer look at the most common area of outsourcing: support. Of all the parts of software development, support is by far the easiest to outsource. It requires the least amount of technical knowledge and support managers will often tell you it’s all about “respecting the customer” and “having patience.” So if you can find people in India or Romania who can provide respect and patience to your customers at less than 1/3 the price, theoretically, you should be golden. But anybody who has spoken to a support rep recently from Microsoft, Dell, HP or any other larger tech company who is supposedly saving money by outsourcing support knows from experience that no matter how much “respect” these customer service reps provide, you end the conversation more frustrated than the start, swearing into the air and vowing to never buy from that company again. Of course you end up going ahead and buying from them again because you have no choice, but this time you know, with a heavy heart, that your purchase price doesn’t really include the promised support. Ironically, from the perspective of these companies, their outsourcing strategies save millions of dollars and not just because of the lower cost of labor. The fact that you are less likely to make a 2nd call into an outsourced support center provides an even bigger savings. So here’s what happens when a large company outsources support:

  • Initial costs are substantially reduced due to lower labor costs.
  • Call volume is reduced (due to frustrated users who give up calling) implying that the new call center is doing a fantastic job or the overall support strategy is working great, reinforcing the behavior that outsourcing was the right thing to do.
  • Surveys will reveal nothing because A) nobody fills out 20 minute surveys and B) those who do are almost always complaining, so the percentage of complaints does not appear to be any higher than when the support was in-house.
  • It does not appear that outsourcing support has had any impact on sales. This is, of course, is only a temporary effect as customers often don’t have a choice, but as soon as they do have a choice, it’s over!

So, the outsourcing strategy may initially seem like a success, even while it’s failing miserably. If you can outsource support, then why not documentation or testing? Eventually, why not development? Nobody dares outsource Design. At least not yet. But the metrics are flawed and those who rely solely on metrics for the operation of their business shouldn’t be in business. They’ll get what’s coming to them.

Note that I’m not picking on India or Romania. It would be equally stupid for an Indian company to outsource its software development or support to a US company if labor costs were reversed. I’m also not against outsourcing from the standpoint of “keeping jobs in America.” That’s about the worst possible reason not to outsource. It disrespects humanity and implies that an American’s life is somehow worth more than a non-American. Outsourcing simply doesn’t make good business sense. At least not for a company that wants to be great.

The Optimum Team

At Axosoft, we often move people around, even as little as 20 feet, just to be closer to somebody that they expect to work with on a project. It’s amazing how much productivity can be gained by being next to a person vs. 20 feet away. It encourages conversations and questions about design items, issues, features and things that would have been passed on if the people were simply 20 feet further apart. Having these conversations allows the teams to build a better more solid product in a shorter period of time with fewer defects. Increase the distance by 20 feet and you lower the overall productivity and product quality by some amount. Increase the distance to 20 miles and your productivity and product quality tanks. Increase that by to 10,000 miles and an equally large cultural gap — and you can imagine what will happen. There is a reason why companies like Microsoft, Google and Apple have built corporate “Campuses” that are focused in a single location. The close proximity of all the engineers to one another is a good thing. It creates a healthy feedback loop, which helps increase productivity and increase the overal quality of products and what’s possible. So the optimum team is one who’s physical proximity is as close as possible and its different functions such as design, development, testing and support are not outsourced.

%d bloggers like this: