Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Clarification: I'm referring to companies that pay developers, professionally. I understand why a "hobby" or "for fun" developer wouldn't want to (or couldn't afford) a fully-features pay tool, and may prefer to tinker. I'm talking about situations where a deadline is bearing down on a developer/company and development time is diverted away from the goal in pursuit of a "Free" tool to accomplish what a pay one is available to do.
I've noticed a number of Stack Overflow questions recently (they're not new, I've just recently taken notice) where people are searching for free alternatives to popular development tools for things like ALM, database comparison, and other functions for which there's a trivially costly pay alternative. The "Free" tag on Stack Overflow has 350 questions, and it doesn't take long to see dozens of examples of "Is there a FREE tool to do X?" followed by discussions that must have taken the asker hours to research and participate in.
It's not just about paying less - I'm often amazed at the hoops that some developers (or, perhaps more accurately, their companies) will go through to avoid paying for something - in some cases, a pay solution will be avoided in favor of a poorly documented, buggy, feature-incomplete open-source solution that results in dozens of hours of work that could have been avoided.
I understand the most obvious reasons:
Company is short on cash
Don't pay for something when a (functionally-comparable) free alternative is available
"Hobby" developers don't have the cash to spare, and since they're just learning, it doesn't make sense to pay for a toolset they're only tinkering with
However, I think the "short on cash" reasoning is completely bogus - as a developer not long out of college, I made about $50K annually, or $200/day (meaning my company probably paid close to $300/day to have me in my chair, all considered). When you compare that price to a $300 tool, the obvious answer is "if it's going to waste more than a day of your time, you should buy it instead and get back to work". However, that's not what I observe - people seem willing to kill dozens of hours to avoid paying for something that only costs $50.
Help me understand - as a developer myself of tools I'd like to one day sell, I want to understand the mentality. Have I been spoiled by working at a company that's not afraid to spend? Is there an ingrained reason developers (or their companies) don't want to spend money? Can people not accurately estimate the costs of "Free" tools in terms of lost productivity?
I'm not referring to instances where a great free alternative is available. For example, any of these tools is a great example of something you shouldn't pay for. However, let's say one of those lacks a key feature you need, and which a pay version of the same library provides - people seem to lean towards hacking around with the free version to add the needed functionality (or scaffold in the needed functionality) instead of ditching the free tool in favor of the pay (and feature-complete) version. I'm not saying that's the wrong choice, but it's just a choice I want to understand the reasoning to. The important point is that I'd like to - my intent is not to be argumentative.
What you're not considering are Dependencies and Partnerships.
It's great when companies announce "Partnerships", their marketing and legal teams spend ages wording contracts and press briefings that basically announce "We're now joined at the hip!".
What you may not realise, is that every time you choose to use a 3rd party tool you are tying yourself to that company, unlike a partnership the dependancy only goes one way (like the Marketing and Legal blurb).
What happens if they decide to cancel the product?
Or they change how it works, and suddenly it's not compatible with how you are using it?
Or they double their yearly developer licence?
Here we use lots of open source tools, while there is only "community level support" and the ramp up time may be longer than for an off the shelf tool, we consider that worth the price we're paying.
We are part of that community. If a version is released that breaks our software, we have choices, we can continue with the version we're using, and choose to maintain that version our selves. Or we can participate in the project and patch the code so it will continue to work for us.
If the open source project falls by the way side, we're still left with access to the source code, so we can continue to build and maintain that too if we wish.
We believe going open source gives us far more freedom than tying ourselves to other companies, who can (and do) change their pricing policies.
Cost-per-developer next year could be twice what it is this year. Changing to a different product could equally cost as much or more.
My two cents.
Where I work I can download the free opensource tool the minute I find it. I don't even have to tell my boss that I'm using it.
If I find a non-free tool I might be able to download a free trial, without telling the boss, but if I want to buy the full version of the tool I'll definitely gonna have to talk to my boss and he's not just gonna give it to me. I'm gonna have to motivate why I need it. He is definitely gonna ask if there are any free alternatives and "I don't know." is not a good enough answer. So if I want the non-free tool I'm gonna have to evaluate all the free tools first.
If I convince my boss that I need the tool, he's gonna send a request to another department that's in charge of this kind of purchases and he's gonna have to convince that department that our department needs the tool. Usually not a problem, but sometimes it is.
Anyway, when we tell our boss that we need something it can take weeks before we get it. Therefore it's often much quicker to just use a free opensource tool and not bother going through that process.
I imagine that other work places might have a similar situation.
Two points to consider:
You're a professional software engineer. Not everyone interested in software development is. For some people, this is a hobby... and paying a few hundred bucks for a profiler (or whatever) just isn't worth it.
You're in the US, and assuming US-style income. That's far from universal.
First off, not everyone asking may be funded by a company.
Second, despite the time savings, ideally the salary for an employee is a sunk cost, it's already been budgeted and allocated. There very well may be "no more money".
When you look at licensing, that $300 thing is $300 for Tom, but then he can't let Joe, Frank, and Bob use it. All of a sudden, if the tool is popular, now it's even more costly. It's not like buying a stapler. And then you get back to what was ostensibly a petty cash purchase now becomes a capital purchase.
A free tool can be downloaded and used instantly (usually). Buying even a $50 tool can take a week getting the check from accounting, THEN it can be downloaded.
Finally, many times folks are looking for some little specific piece of a tool, not the entire suite. Yet they're forced to purchase the entire thing. The Whiz Bang Ka-Blammo Enterprise Tool Set when they're only interesting in the 17th bullet point off the feature list.
I'm never afraid to go to my boss at work and ask him to pay for some tools that will help to make me more productive. However, the work that I do for myself, and much of it is as complex as what I get paid for, has to be done with free or nearly-free tools. I have paid for some things where the cost-to-value ratio is really compelling, like Wing IDE for Python development. Visual Studio, on the other hand, is so expensive that I just can't rationalize the cash outlay no matter how great it is.
I certainly appreciate the rationale behind this question. If you are thinking about being a professional tools developer, you have to wonder if it is going to be possible to make any money at it. I would say that you have to very carefully consider what you charge for your products. While you can charge enterprise-class customers hundreds of dollars for a tool, and they won't blink at it, making the sale in the first place is an enormous challenge. With my startup company, we found that it took about a year to go from first handshake to getting a signature on a check. That's a long, long time when you are starving and living off of your savings.
On the other hand, if you can charge less and make it a compelling purchase for an individual developer who is reaching into his or her own wallet for a personal credit card, you can achieve the kind of decision-maker mind share that can greatly short circuit the year-long enterprise sales cycle.
A developer is paid, and generally motivated, to develop stuff.
Picking up a free library takes a bit of research, but then you can pull it in, try it, and keep doing that until you find one that fits. The process of selecting the appropriate free library/tool fits well into the developer's skill set.
In a business, you're right that it's possible to buy good tools. However, to do this you need to make a business case for the cost, and persuade your manager (and probably further up the chain too) that it's worth paying. This requires an entirely different skill set, and one which would take many developers outside their comfort zone. Most of the time, I think developers just can't motivate themselves to start down this route.
Even if "the company" might want to spend money on tools if it's cost-effective to do so, the average developer is not correctly motivated to support this company goal.
Going back to your original question, you were interested in how to sell development tools in this climate, when developers have this tendency to pick the free ones. Based on the above I see two options:
Make it compelling to the developer, so they think it's worth the politicking time to get their hands on it. Time-limited trial versions etc can help here: once the dev has learnt the tool and seen what it can do, they'll not only be happier to ask their boss to spend the money, they'll be better prepared to justify the spending in terms of time already saved.
Make it compelling to the manager, either so the developer knows they'll have an easy sell if they ask, or to skip the individual developer level altogether and sell directly to management. Anything with "enterprise" in the name is taking this approach.
I think there's a mental block against paying for something when you can develop it for "free". I think often developer time is seen as a base cost, something you're paying for anyway, so the additional time spent developing a tool isn't seen as an additional cost, it's something you're already paying for.
The complete opposite exists too. Some developers will blindly buy the first thing they bump into. But I think a lot of developers have various unhappy experiences with paid-for software. Community support can suck. Paid support can suck. Some people get disillusioned with the whole closed-source thing and prefer something open source just because it's open source.
As you're focussing on trying to eventually sell something, here are a few tips to convince people to stop hopping once they've found your wonder product:
State the features. I've too often found a site talking about a widget that just bombards me with latest news, changelogs, prices, yada yada... But doesn't tell me what it actually does! The first paragraph should concisely explain what it does.
Provide lots of example code, sample projects, documentation. Tons of it. The more use-cases the better. Now of course you also need to provide a navigation system so the user can find things but the more examples, samples and docs you provide, the quicker the user can test your whatsit.
Trials make the world go round. If you can, make sure I can test it before handing you any money. If I can't, I, personally, won't be buying it. Money back guarantees come in a close second but as I say, if I can't test it out, however good it looks, you're not getting my money.
Companies I've worked for look for free alternatives (and usually I mean really free, not just free of charge) because "pay ones" often have (or get over time) restrictive licenses on redistribution. I don't want to base my whole product around a for-pay library only to find out that I now have to pay them $1000 per copy I sell.
As a matter of fact, I earned a bunch of money last year porting a product that had been written using a third party web crawler/indexer over to use Nutch instead because the person who'd paid for the product to get written in the first place didn't realize that the third party web crawler/indexer was going to cost her more per license than she was planning to charge for the whole product, and because she also didn't realize that the third party product was built for intranet rather than internet crawling and so ignored robots.txt.
Some times the "management" does not want to buy anything for the "developer" thinking that the latter is getting paid to develop the software. I've been in situations like that and it was really hard to convince the mangement to buy a set of UI controls we needed for a web application.
I personally prefer free tools, because learning how to use a tool is not 5 minutes. to really master the tool you need to spend a lot of time using it. Id rather not waste time in learning something that is not universal and cant be used always. learn once, use anywhere.
Many of those payed software is not that amazing for me to fight with my boss for it. Total Commander is the only tool that is worth the fight, however from time to time I look for free alternatives and I even consider writing one myself.
When was the last time you read your GNU manifesto. Has the concept of copy left been forgotten? Maybe you've forgotten your roots. The world of software development started from the sweat of the "hobby" or "for fun" developer. Remember those two developers in their garage who later made and sold those operating systems? It is not only a part of our heritage to hack out our own solutions but it's in our blood as well.
Also, companies of the pay-to-use solutions are trying to make money. While a good business model will include helping the customer achieve their goals, making money is their first priority and has a good chance of getting in the way of development progress. The free to use community on the other hand, from what I understand, is purely altruistic and has only the utility of the software thing in mind. The community of free-to-use, copyleft, open-source is very strong.
Ideas/concepts were meant to be shared (freely) to advance us as a people.
Sometimes you need free tools if you are not sure will the result bring you enough money. For example you established startup that works on creating app (or site). They don't want to spend money on third-party tools because they can't be sure will it bring money or not.
Another case, i once worked for big company and their budget approval process took too long, i have to find free stuff at least on initial stage.
Have you noticed that most free tools come without warranty (see GNU Public License, v.2) or support? I use tons of 'free' software every day, because as a hobby, I like to develop too. And a good application always gets bought, but back to the why's.
The FOSS community is a large one, most applications are free. Hence, it wouldn't be a strange question to ask for a free or an open source alternative, because well, there are a lot.
A free ride is always better than a paid one. Depends on the attraction, though. Some paid ones are better or far worse. (Babes, Photoshop, Dreamweaver, Vim) comment: "Babes" is not a program.
Some commercial applications require you to pay by creditcard payment. I hate online payments, and I double hate creditcards. I triple hate how companies store my personal information.
Not everyone is a software engineer. Some of us, do this just for fun :D (Linus Torvalds, Matz, Guido, Larry...go on, go on....)
Another line of thought here is how well are those superior pay ones known to everyone? For example, how am I supposed to know every kind of add-in that Visual Studio has? While some may say, "Well, you aren't," then this is another reason for some to not find those great tools out there. Some may be easy to discover and others may require one to know some jargon phrase in order to use some Google Fu to find it.
Another point is what some companies may or may not realize about how they are spending their money. For example, some developers may have some pretty sizeable hoops to go through to get the company to buy licenses for some tools, especially if every developer would have to have a license and some aren't that cheap to get. How well the managers know what their developers are actually doing and what kinds of changes could be made for the better with a little money could shock some people while in other cases the learning curve on using the tool may also be seen as a barrier in some ways as well as another thing to keep track since some tools are available on a subscription-like model rather than an outright buy it once model.
Seemingly since that time when programming and development came into existence there has been an ebb and flow between the commercial and the non-commercial -- these days more accurately described as 'corporate America' and the 'open source community', respectively. I personally chalk all of that up the existence of middle men and profiteers.
On the subject of freeware, I feel as '01' above -- a free tool allows evaluation at my own pace, potentially preventing the waste of valuable funding, which is an important consideration in this current economy.
Shareware is a fine balance, but I personally find most software doesn't provide adequate time for evaluation. Most tools I download are 'once-a-month' endeavors at their highest frequency so plunking down $30-$60 (U.S.) seems unjustified until I know the tool lives up to my desires.
And regarding professional tools, we all know the goals of business. I find the terms and conditions of Scooter Software to be most logical and accommodating. I've used their Beyond Compare tool for years and years -- as a developer invaluable I've found it both valuable and unequaled.
As to your personal dilemma, make your tools good enough, offer good shareware evaluation terms, and charge a reasonable price for it. Choosing popular (and multiple) platforms also doesn't hurt... consider the number of folks who've made a mint selling iPhone applications, regardless of those applications actual utility.
I'm talking about situations where a deadline is bearing down on a developer/company and development time is diverted away from the goal in pursuit of a "Free" tool to accomplish what a pay one is available to do.
This is exactly the situation when you can't use a paid for tool because petty cash/expenses won't cover the cost and getting budgetary approval takes weeks to come through.
Number three from 9 Ways Marketing Weasels Will Try to Manipulate You. It's "Free"! People make irrational decisions about free stuff.
I think that it makes a lot of sence for companies to try to use free/open source products for the following reasons:
Reduce the price of the deliverable product. Why would you expect a customer to buy something that works with a proprietary database when the company can bundle MySQL for example for free? So the company can lower the price and be more competitive.
Usually when buying software/tools, there are proprietary issues.
Usually when buying software/tools, there are dependencies to other also non-free modules.
There are other reasons also, like that IMHO it is considered "trendy", but the most improntant is that the use of free software can cut down the final prices, helping the company gain customers.
It is also important to support the free tools by adding to the momentum of it, sometimes by the simple fact of starting to use it. By finding/reporting bugs, or more importantly, fixing them and giving patches back, you improve them in a symbiotic relationship that benefits both your company and the tools you decide to use (and hence everybody else who also use them).
One good reason to look for free tools is to get a complete overview of the available options. I'd say that's a reasonable thing to do before you buy a product. Commercial software vendors have advertisements, so you'll probably find those, but there might be a great free alternative that you never heard of. It makes perfect sense to check that, even if you are willing to spend money on software tools.
Plain and simple some companies like IQPC.com will not spend even $10 on software and it's even hard in places like this to find a pen or pad to take notes.
I shed a tear for those who have to live like this, it's not easy.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Let's say you work for a huge company which suddenly decides to do custom in-house software development. Additionally, they want to be able to offer successful developments to their customers as well (if any).
Now you are in charge of it.
What would you see as most important to build a successful software development infrastructure?
flexible to future growth
flexible on used technologies (projects with c, java, .net, web, mobile, ...)
What kind of tools (source control, forge, ...), hardware (virtual, seperate dev & production, ..), processes (guidelines, code reviews, ...), etc.
UPDATE: Please don't answer that you need the right people and the right tools. This is exactly what i am looking for.. What are the right tools and what people of what type would you hire first to join your team? Think of it as you will be the lead of that development.
Set yourself up to pass the Joel Test with at least a score of 10.
I think having the right people is going to be the most important. Nothing else will matter if your programmers stink.
Someone in charge who knows what they're doing.
Obviously, there are lots of factors, but here are the ones I'd say are crucial:
Hire smart people (and pay them what they're worth)
Select good tools appropriate for the kind of development (don't go for cheap tools)
Establish version control system and policies
Establish testing mechanisms and policies
Don't be afraid to outsource the stuff you don't know how to do
Get the best people for the job. If they aren't willing to pay for the best available, or give you a hard time over your personnel budget, you're off to a bad start.
Get the right tools for the job... software, hardware, support contracts from your vendors, etc.
Establish procedure early on for your development life cycle, and make sure that you have the people in place to make use of it. This is everything from how you evaluate Opportunity Assessments to Development, Testing, and post-production support. Make sure you have the people and the tools for each part of the life cycle.
Dont try to be flexible in technologies. First start by focusing on one technology (Java, .NET, whatever...) and then move to other if you need to. You will be able to solve problems using any technologies, but it is very hard to find people good in many technologies.
At the infrastructure level, Source Control is a must. Continuous integration is a plus. Take time to put in place a standard project layout that you will be able to evolve. It make it easier for developers to switch projects. Take time to put in place a good build process (Ant, Maven, in the Java world). Integrate your build process with your IDE so that developers dont have to wait 5 minutes to deploy their project every time they want to test a code change.
I agree with Guillaume: If you want to build a department from scratch, you need to focus. You need to build your team, have everybody grow into their new responsibilities, get to know each other etc. Trying to go into too many directions at once is the direction towards failure.
So, identify the technology you want to develop in. Since the primary goal in your example is in-house development, the in-house requirements will determine your decision. Build your team with that primary goal in mind.
For in-house development, you need at least two people who already know the company and its processes. (Two because one will definitely be ill or on holidays when the first major crisis hits you). On the other hand you need some outsiders, who are not entrenched by the "we have always done it like this" mindset, who can think out of the box. Those should also be at least two people, for the reason stated above. Your job as the team leader is to balance those two groups and integrate them into a team.
For future growth, always think in terms of organic growth.
Do not increase the team size by 200 %, hire one new guy here and another guy (or gal) there. Slowly build your team.
When you take on a new project, always think of expanding your teams expertise. Try something new with every project. That can be a new source repository, an automated daily build process, a new system to write specifications or documentation, or even a different technology (for example Java when you usually develop in .Net, Delphi or C++). Just make certain you never try to make a big leap in an important project. (I once worked for a company who decided to switch from VB 6.0 to .Net for the biggest project they had ever attempted before. They survived. Barely.)
That way your department will slowly but constantly expand its capabilities. Then when the opportunity presents itself to do development for an external customer, you will already have accumulated most of the knowledge you need in order to pull it off.
Oh yes, and smacl is right, too: You need solid QA/QM if you want your department to survive long term.
Start laying out (and follwing) your QA rules from day one. Keep them as short and flexible as possible. Add what you discover to be missing, and throw out what proves to be unnecessary or impractical.
Not sure this is what you wanted to know, but I felt the need to say it ;-)
Develop a strong QA strategy, including acceptance criteria and change control. Preferably keeping it lightweight to suit internal clients. In addition understand how to carry out requirements analysis, expectation management, and resource management.
Put another way, don't just wing it to create crappy solutions that waste more time than they save and are impossible to maintain. Take time to think about what you want and need, how you can achieve it, and what it is going to cost.
I will offer an answer more focused specifically on coding and the developers / architects role in addition to the previous answers on teams, version control, qa etc. which are of course all important.
Many of your decision is very dependant on your specific business and software structure (a single product code base, SOA, many projects etc.) But in general you should always spend significant time up front developing Core Software Infrastrcuture that will pay huge dividends during the SDLC.
Software infrastruture
Coding Naming Conventions Exception
Handling strategies Logging
Strategies Settings and Configuration
Base classes and Helper Classes
General Architecture and Layers
(Presentation, Facade, Domain
Entities, Data Stores etc.)
Design Tools such as UML 2.0
Requirements
Management / End user interaction
There are tons more, but these are certainly some basics to think about. All of the successful projects I have been involved with incorporated decent software infrastructure. I will also note that many of the project that fail have a common theme... lack of a common infrastructure in place. In most cases these failed projects are lead by a non-technical person that think they can simply throw a bunch of ideas at a few programmers and expect them to deliver in a few weeks.
Bottom line, you need to invest some up front planning and prototyping to ensure success in the long term!
Good luck.
Raiford
www.blacksaber.com
The first persons you should hire should be experienced senior level professionals. Then build up from them / with their input. Add the junior people later.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 14 years ago.
Improve this question
I've seen a lot of questions and discussions about build vs. buy, but most stick with the simplistic approach that you can simply do one or the other. Most of the time you have to either buy and integrate or build yourself. Either way you're in for some work.
In the next 30-60 days I NEED to implement a couple managerial projects to keep everyone from ripping their hair out and killing each other. The largest of which is a ticketing system (emails, support requests, self service, etc.).
There is no shortage of options but at the end of the day we'll have to buy whatever we decide to use, add all our clients and their users and make sure we keep things in sync over time. We'll also have to provide a single sign-on and do some design work to make it all look like we built it from scratch.
If we build we get to skip the integration pain points, albeit with a limited (but focused) feature set.
What do you typically analyze while making a decision like this? If it better to have 4-5 systems that do a very specific job well, or one monolithic system that does everything?
You've identified a key issue - when you buy you still have work to do, and potentially lots of it. Having said that my overall leaning every time is towards buy. Writing code is hard, debugging code is much harder - when you buy, you're not just buying the code/application you're buying the fact that it works - the latter is 90% of the benefit.
However, as your needs are pretty common, why not go with open source. This has two stand out benefits.
1) As you have access to the source, you can bend it to your will - ie no need to lash single sign on over the top of an existing system. Tailor the login modules to use your already existing infrastructure, therefore no need to keep things in sync, time savings, clean approach etc etc. Much open source acknowledges the real world by componentising (?) those aspects which are environement specific anyway. They're often DB/Identity agnostic.
2) If you choose wisely you will have a ready band of top tech staff who already understand the system ready to help - the only problem is they don't work for you (yet!).
My advice would be pick one of your easy targets - the ticketing system seems like the one, analyse whats out there that in the open source world that meets most/all of your needs. Evaluate and put out a request on Rent A Coder for any changes that are required. Sit back and await the results, which are hopefully excellent. You've lost a little time, and gained a lot of experience.
Open source does not equal Linux/Unix - lots of good stuff for .Net out there too.
One system is better for the following:
One data repository(i.e. the Database)
Easy way to link each system together, do cross referencing. No need to build intermediate importer/exporters/sync-ers
Allows for single log in. This is very useful in businesses to make sure everyone know where to find the right information. So more "what was the site for the bug tracking again..." Not everyone will use all the tools the majority of the time, and they will forget how to access and even use.
Everything has the same look and feel
Saves on training
Maintenance is cheaper. Everything is the same to update. Admins dont have to specialize in hear separate system.
But... obviously you're stuck with what you buy. Make sure to get a system if you can that you can build your own addins for, to match it to your busienss' model.
Obviously "it depends." My general rule is that if it's internal we buy it and integrate if required. Our corporate sys admin has a support line to someone external to our organization if she has issues and it isn't a huge project burdening our developers.
If it's part of a product I'm shipping, I build it or take bits of source as needed from open source libraries. There's nothing worse than someone else's black box code breaking your product. The fewer the dependencies in a shipping product the better, IMHO.
I'd lean toward buy for a support product like you mention. The good ones offer great integration points to shared authentication systems, user facing theming, and probably a boatload of features your customer service team hasn't realized they want/need yet.
But, what to analyze. The biggest thing for me when it comes to 'managerial' projects like this is opportunity cost. What else could my team be working on that will make our company significantly more money, get us more customers, etc? Of course these projects have some positive impact on the bottom line, but nothing compared to new products, improved products, etc. How long over time, including maintenance, will developers/pm's/testers spend on this managerial project? If you buy, integration points don't change often, but if you build, your customers (in house people) will be asking for new features constantly and you'll be in the position to maintain this project for the rest of your tenure.
Buy? What is this buy of which you speak, stranger?
Seriously, I haven't had to buy a piece of software for my own projects for a long long time. All my development tools are free, all my third-party libraries are free (not GPL). Even my OS is free. I have to pay for Windows for testing purposes but the majority of work uses tools that are cross-platform.
Anything that requires code not immediately available from free tools or libraries, I either write from scratch (all the algorithms are available for free on the web) or use my (huge since I'm so old) snippet library which I've been adding source code to for many years.
It's almost always quicker to buy ("obtain") than build unless the bought stuff is so crappy that integration is a nightmare. This can be mitigated by avoiding the latest whizz-bang stuff from suppliers that have little track record.
The more 'standard' your requirements, the better buying fits (Or to put it another way, don't reinvent the wheel). Conversely, the more unique your requirements the more you might consider building.
You quite rightly point out that even when buying there tends to be some customisation. Bear in mind that any customisation will cost you at each upgrade/patching time. I suggest that if your requirements are close to the business model supported by one of the tools you might buy that you serious consider realigning the business process to the vendors standard. If this is not possible ask if you are buying the correct tool.
I would suggest that if someone suggests building it for cost reasons run screaming. In my experience the cost of buying is well known and the cost of build is well hidden. Remember that you will be making a decision to keep coding for the life of the App (average of 7 years for a business app) but may be considering only the initial development cost when deciding between buy and build.
I have a strong preference for a single monolithic database but sometimes this is not workable. More important is to have a 'single source of the truth'; if you have multiple databases holding like data, pick one as the authoritative source of a given piece of data and have a process to maintain all others in agreement with that source. Preferable this will be automatic.
The monolithic system that does everything is the the Raison d'être for so many Enterprise applications. What I've found, however, is that if you're not willing to pay a buttload of money, you're going to have integration issues.
The 'best' solution is quite subjective, and any answer is as right as it is wrong, but if I were king, I'd probably go with the entrenched open source solution where it fit, and wrap web services around the items that needed to talk to each other. If I were king.
As a tangential point, there are free ticketing systems like RT (et. al.) that you need not worry about buying.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
What prompts my question is this post from Jeff Atwood, and this post from Dare Obasanjo. It seems to me that there might be at least a few areas where third-party functionality is a better idea than custom code.
For example, should logging always be third-party? How about encryption? Or search?
I'm looking forward to everyone's feedback on this.
Edit: This question assumes that logging, encryption, and/or search isn't your core business.
Encryption should be third party most of the times, ...unless you're in the business of selling encryption systems.
Which is pretty much Mr. Atwood his point as I understood it, your core busines shouldn't be third party, so there's probably nothing that should always be third party...
My rule of thumb is to use (or at least consider) third-party for anything that's outside the core purpose of your business.
Encryption's always been the prototypical example of this. But it extends to other areas as well.
Writing logging code for troubleshooting during development is entirely different than writing logging code used for monitoring production systems.
It's all about choosing which areas of development actually add value to your project. Using third-party stuff removes the risk that that component is incomplete/buggy/etc. but comes with the risk that it may not be as flexible as what you need.
Another example would be developing an entire web forum for a website, when you can buy a solution for much cheaper.
"What functionality should always be third-party?"
None. there is always an exception or special case to overrule the egregious use of "always" when discussing an essentially engineering decision.
Further, the decision to go third party should almost never be made on basis of a given "functionality." There is no such thing as such a perfect library that you never need go anywhere else for that type of functionality.
Going third party is a decision that should be made based on
Cost of going third party vs cost of doing it in house
Development time required placed against deadlines (ie, it might be cheaper inhouse, but your development timeline might not allow it regardless)
Ease of integration, debugging, maintenance, upgrade paths - it may be that you can develop something that will "do the job, but barely" inhouse vs not much more money for something that will take care of you for years to come
Ease/cost of testing and proving - security packages are notoriously difficult to test well
However. There are some things where it's really tough to believe that going in house is better. For instance, you can write a competitor to OpenGL and DirectX, and in certain applications (scientific computing, etc) there are good reasons for considering such a path. But in general you wouldn't dream of it. Even though it's "free" it's still a third party dependency, and you could end up on the skids because of a bug which only affects how you use these graphics languages.
In other words, some incredibly complex or hard to prove/test things exist which should almost always go to a third party. Security is another one. Don't write your own hashing algorithm unless you are 1) certifiably crazy and 2) have at least 3 excellent business reasons to do so.
But "What functionality should always be third-party?" None. There's always an exception.
-Adam
I fully agree that encryption should only be done by experts whenever possible. It should also be open source and have undergone a good deal of peer review.
It depends. Is there a 3rd party library available that suits your needs and most importantly, the language and/or API you work with. Then go for it.
If you have reasons to do your own version, make sure it's not just "not invented here". Also, if you haven't had an in depth look at the market's top five leading products for whatever you need, you haven't done your job thoroughly enough. There are good chances you will find what you are looking for, and even if you can't use it, you still learn something even from the library descriptions. At the minimum you will learn which features you would need and which you don't. If you also get the source code to one of the libraries, this should be your preferred choice over a competing library with no source code but possibly more features.
The area where I have consistently used third party controls was charting. It is a fairly common problem to have to chart some batch of data and the third party controls are mature and trustworthy.
I guess the answer depends upon the usage. If you are developing for profit, you would be likely to buy in components if the cost of using the component vs the cost of developing it results in more profit. This is particularly the case with large components when you do not have the in-house expertise to produce them.
A couple of good examples that I have used are the Infragistics controls and Dundas charts. Although we could have created these in-house, the costs in terms of time and lost opportunity would be huge compared to buying a couple of licenses.
Of course, sometimes we do this type of thing without even considering it as a component purchase. Streching the imagination a little, you could include the .NET framework, SQL Server, the Windows API, etc.
If you can buy it cheaper than you can build it, and the bought functionality meets your business requirements, then buy it.
There is not a definitive answer to this question because just like anything else in software development it depends on the situation. I would say that if the following 3 items are true than you shouldn't think about doing it yourself...
If it's not core to your business or expertise.
If someone else has written it for you and it is being used in widespread communities.
If it meets your needs and requirements or it can be extended to meet your requirements fairly easily.
This question is the inverse of the question: what software should you create?
Which is obviously silly.
For both there is no one answer, it depends on the needs of your business. Do you need to build a better search engine for the entire internet? Almost certainly not. But if you are Google in the late 90s, you do. 3rd vs. 1st party is just a matter of which office you work in, every 3rd party is a 1st party to themselves.
If all you need is good enough: use something off the shelf.
Either you'll create something lower quality or you'll waste money and effort on something that doesn't matter that much, or both.
If it's the foundation of your business: build it yourself.
If you can build something better, and you can build a business out of that better thing, then do!
Don't forget that the time is a big issue for writing all things by your hand, it is not that you cannot do that but the problem comes from your customers or company they always want to find the fastest way to build their system. But if you have a non-profit project you can try building things by yourself. For e.g you can use JQuery or Dojo as your ajax toolkit if you are writing web applications and you want to set some ajax functionality, it will take time to build those things by your hand :)
But you also must be careful when using a third-party libraries, you must trust them because they can contain malicious code, or they are very poorly written and can cause you headache.
Your own encryption function? dont even think about it but I think you probably meant some kind of wrapper for existing functions.
3rd party component advantages:
Alot of functionality
Fully tested (hopefully!)
Doesnt take time to develop so can be cheaper (but..)
Disadvantages
Is it really flexible enough for that next akward customer requirement
Distribution can be expensive
Ties you into 3rd party company which can be a pain when they make a new release to fix bugs
You dont learn to do the task yourself
Whether you use a third party component is going to depend on your application and the requirements. Something like graphing is going to take ages to get right so would be a good third party component to use.
Anything that is outside your core business is a good candidate for third party solutions. You want to spend your development time creating that core functionality that is unique(ish) and can not be purchased and used in a cost effective manor.
For example, lets look at web gridview control. Can you develop and extend a gridview yourself? Sure you can, but to develop, code, and test you grid view is going to take X amount of time and resources, which you can translate in to dollars. Now you have factor in reoccurring costs for support, maintenance, and bug fixes.
Now lets use the arbitrary amount I remember reading in some mag about the average US developer making $40 per hour including their benefits. There are whole web control suites available for around another approximated $800 per developer license. If your developer spends more than say 25 hours total on this one control, you could have purchased a whole suite and spent 5 hours integrating and testing.
Now hopefully I didn't get too confusing there, but the general gist is if you can buy it off the self it will probably save time and money, and instead focus on things you can't get off the self which are usually your money makers.
I'd say for writing boiler plate code, or redundant code which is copy and paste almost every time should be done through a library. For me, validation code almost always has me making stupid mistakes, because it's boring. Spring.NET is amazing for this. I'm so glad my boss encouraged me to try it.
seems you have all the answers you need, but i would just like to throw my opinion in here along with everyone else's. clients pay you to make applications that work specifically for them, and that's usually why they go to you; something they need isn't found in any other product on the market. thus, your focus should be on developing that specific part they need.
undoubtedly your application will need to do other things as well. maybe it will need to connect to a database, or encrypt certain lines. this is where third-party libraries come into play. you don't want to waste time writing a new driver for a database, or a new encryption scheme that might have holes you don't have time to test. you want to use the ones that already exist, and have been extensively tested and optimized.
remember, the faster you finish, the less they will have to pay. this makes them happy and want to come back to you. this also means you make more because even though they pay less, you can work on more projects, which means more money.
in conclusion, you should rely on third-party libraries in miscellaneous modules.
My dad always says "Responsibility without Authority is meaningless".
However, I find that as developers, we get stuck in situations all the time where we are:
Responsible for ensuring the software is "bug free", but don't have the authority to implement a bug tracking system
Responsible for hitting project deadlines, but can't influence requirements, quality, or team resources (the three parts of project management)
etc.
Of course there are tons of things you could say to get around this - find a new job, fight with boss, etc....
But what about a technical solution to this problem? That is, what kind of coding things can you do on your own without having to convince a team to correct some of these issues - or what kind of tools can you use to demonstrate why untracked bugs are hurting you, that deadlines are being missed because of quality problems, and how can you use these tools to gain more "authority" without having to be the boss?
***An example - the boss comes to you and says "Why are there so many bugs!!?!?" - most of us would say "We don't have a good system to track them!", but this is usually seen as an excuse in my experience. So what if you could point to some report (managers love reports) and say "See, this is why"?
All you can do is your best, don't feel as if the key to successful software is only in your hands, your part of a team and don't have to be responsible for all.
Obviously you are in a environment that affects negatively your software, but can't change all his behavior so I recommend you start with yours, start working as a team of one with your own bugs, deadlines, requirements, quality and resources don't bother for the rest of the mess, but try to be the best at your work.
Working as a self-directed team of one showing your boss your plans, and reports of your progress, asking for more resources when you need it and showing him how your plans get affected when he give them to you or not.
You can find more advise about this in the PSP and TSP articles of wikipedia
After showing your boss a good work and meeting your own deadlines, surely he will trust you more and let some of your ideas flow to the entire team.
You don't need a bug-tracking system, you need automated tests: unit tests or otherwise. You can set-up automated tests with a Makefile. You can always find paths that are blocked by management, but that doesn't mean there aren't things you can do within the constraints of your job. Of course, the answer could be "find another job". If you can't find another job now, learn some skills so that you can.
The simple answer is -- you can start using the tools yourself.
Improve your own work. If people want you to fix code, tell them to file a bug. Show them how. Make sure they can do it without installing anything. They want a status update? Tell them to check the bug. They ask abou a code change you made? show them how to make a source control history query. or just show them on your box. Start showing them this stuff works.
And when you need the same results from them, demand that they do the legwork. When you can't find the changes in your source control, ask them to start diffing their revisions manually from the backup tapes. Don't do their work, or the work of source control and bug tracking, for them.
And most importantly, when applying this peer pressure, be nice about it. Flies and honey and all.
If they don't get it, you can continue to be the only professional developer in your company or group. Or at least it will help pad your resume: 'experience setting up and instructing others in CVS and FogBugs to improve product quality' and the like.
As for specific tools for showing that untracked bugs are hurting the team's ability to produce quality code, you've got a catch-22 here since you need something to track bugs before you can show their effect. You can't measure what you can't track. So what to do?
As an analogous example, we recently had a guy join our team who felt the way we did code reviews via email was preposterous. So, he found an open source tool, installed it on his box, got a few of our open-minded team members to try it out for a while, then demoed it to our team-lead. Within a few weeks he had the opportunity to demo it to all our teams. The new guy was influencing the whole company. I've heard lots of stories of this guerrilla-style tool adoption.
The trick is identifying who has the authority to make the decision, finding out what they value, and gathering enough evidence that what you want to implement will give them what they value.
For a broader look at how to lead from the middle, or bottom, of an organization, check out John Maxwell's The 360 Degree Leader.
If you want a report about quality and it's impact on productivity - here's the best:
http://itprojectguide.blogspot.com/2008/11/caper-jones-2008-software-quality.html
Caper Jones has a few books out and is still showing up at conferences. Outside of a good IDE a developer/IT group needs source code control (VSS, SubVersion, etc ) and issue tracking
If an accountant is asked to produce a set of account without using double entry and don’t balance, no one would expect the accountant to do so.
However double entry has been in standard usage by accountants since about the 13th century.
It will take a long time before we as a profession have standard practise that are so ingrained that on-one will work without them.
So, sorry I expect we will have to face this type of problem for many year to come.
Sorry for not answering your question directly, but...
I feel strongly that the failure you refer to is one of communication, and it's incumbent on us as professionals to develop our communication skills to the point where we are respected enough and trusted enough to leverage the authority we need to improve our working environments and processes the way you suggest.
In short, I don't think there is a technical solution that can solve all the problems created through poor communication in the workplace.
If anything, technology has caused the attrition of direct face-to-face communication.
Sorry, I'm off on a tangent again - feel free to downmod.
Coding only you can only keep your own source files tidy, well commented, keep the bug count low with tests. But you are going to need external tools for tracking progress and bugs (bugzilla, yoxel, trac, gantt diagram tools, Mylyn for Eclipse, a blog, whatever). In these cases the people and the discipline and the good habits and the leadership are the overwhelming force, no software tools and no offert from the individual can win alone.