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.
Related
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.
I have been working with managing agile teams for quite some time. Now I'm at a company that no matter how hard I push for the fact that face-to-face is the way to go and that excel sheets works to get us going. But the company sees the "burn-down-chart in a webpage" as the main focus. They actually see that and the ability to see and follow the backlog online as the most important thing and we basically can't get going before this is in place. The people involved are actually not that many and they are not spread across multiple offices so I really can't see the need.
But I have decided to stop driving myself crazy about this and just bite the bullet.
So I started looking around and gave Pivotal Tracker, Banana Scrum and a few other a try. A mix of them all would probably be my best fit but given the criteria bellow, which would suite me best? I have searched StackOverflow and read up on a few recommendations before posting, but none of them actually fitted all my needs. The MAIN issue is to give people an indication of the workload and future work-load of the dept, but if we are going to start using a management tool it might as well fill a few other requests.
Ability to run it on an in-house
server (since a lot of the systems it should integrate with are not public on the net)
Ability to integrate it with
Bugzilla, preferably two-way
Ability for external
applications (such as websites) to
fetch data about backlog and
bunrdown-chart
Ability to handle
cross-functional teams (ie we might
only have one person on a team with a
given ability. Before I used to
handle this manually to avoid over allocating this person in a sprint, but if others
are to be able to fiddle with the
backlog this should preferably be
automatically indicated)
Ability to print index cards
Virtual white-board
Ability to set up automatic reports to be mailed
Long term indication coarse-grained (correct name?) estimation of features done and short term fine grained estimation
UPDATE: Open-Source would be preferable. Jira is nice, but licensing is quite expensive
UPDATE 2012-01-03: I would like to tip about Backlogs for Redmine which adds Scrum facilities to Redmine in a acceptable manner.
JIRA with the GreenHopper plug-in provides most of what you want. As you say, it's not free, but the licensing costs are reasonable. Twenty dollars to get started with 10 users is a sweet deal.
I've used GreenHopper for a few years. We tried Excel spreadsheets beforehand; they sucked. The problem requires a database and better visualization.
On request, we printed off JIRA task cards for a physical taskboard for a few months. But that was silly -- DRY. A projector in the standup room is all you need. Optionally, you can filter tasks to focus on those team member in turn.
Ability to run it on an in-house server (since a lot of the systems it should integrate with are not public on the net)
Yes.
Ability to integrate it with Bugzilla, preferably two-way
Last I checked, it could import Bugzilla issues.
Ability for external applications (such as websites) to fetch data about backlog and bunrdown-chart
Jelly scripts and JQL might help here.
Ability to handle cross-functional teams (ie we might only have one person on a team with a given ability. Before I used to handle this manually to avoid over allocating this person in a sprint, but if others are to be able to fiddle with the backlog this should preferably be automaticly indicated)
Not sure what you're looking for here. You can create custom groups of users. In the basic system, the only indication of over-allocation is a user's total number of hours in a sprint.
Ability to print index cards
We did this. There's a "Print Cards" menu item.
Virtual white-board
There's a task board. No arbitrary drawing surface.
Ability to set up automatic reports to be mailed
Yes, with very fine control of who gets sent what in response to what events. There are several mechanisms, configurable by either administrators, project administrators, or users.
Long term indication coarse-grained (correct name?.. hehe) estimation of features done and short term fine grained estimation
There's an hour-based burndown chart for the short-term of the next sprint, and an issue-based burndown for the long-term.
Pivotal Tracker is a great tool. Unfortunately it's now going paid (not free anymore). Other tools that are pretty solid include: Rally, Version One, Jira (with Greenhopper), AgileZen, AgileBuddy, TinyPM, Aldon Agile Manager, Agile Bench, Scrum Desk, Scrum Ninja to name a few.
Agile tools are being built by the boat load. You may never find the "perfect tool." Period.
I do suggest that you start with a whiteboard, tape, and stickies. At the end of the day, wallboards are KING for Agile.
On my last project I used Pivotal Tracker which was very slick, though you have to accept that it's Pivotal's way or the highway :) Although its no longer free, it is cheap. I haven't tried Mingle, though I hear some good things about it if you're willing to put in the configuration effort, similar to Greenhopper, which is what we've just shifted to using internally.
#Jody - I don't find Jira to be overkill for small teams if you configure it minimally. Even so I can sympathise that Jira/Greenhopper don't 'just work' out of the box, and something like Pivotal Tracker or 37signals BaseCamp may be a better fit.
If you are interested in open source tools, I would suggest to look at the Scrum Open Source Tools Directory But if cost is a problem and you don't have many people in your project, a lot of commercial tools like TinyPM offer free version of their tools for small teams (5 persons in their case I believe)
I used 37 signals' basecamp with much success. I combined this with a 3rd party burndown chart - http://www.burndowngraph.com/.
I managed the backlog offline in a spreadsheet or as a single todo list in the project. Though you could use 2 basecamp projects. One for the current sprint, and one for the backlog. Each Story becomes a todo list, and each task is ...well, a todo item. Hour estimations for tasks go at the end of a todo item in the form "1h" or "1d" or whatever.
The sum of all todo's is your sprint backlog & taskboard in one.
For your integration concerns, they have a wonderful API that lets you do just about anything you want.
It won't print index cards, but if you really need them there's always the API.
Automatic reports, hmmm. I don't think so, but if people are genuinely interested, they should check the project page for updates.
Not sure it would help you with the cross functional team thing, but maybe I don't exactly understand the problem there.
I think that covered all your points (not that basecamp can, but it's close)
It really sounds like you are trying to use this tool to appease management, but still do things your way. Whatever tool you pick won't be completely successful until you and the team embrace it as well.
Best of luck. BTW, I find greenhopper and jira to be complete overkill for small teams.
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 3 years ago.
Improve this question
Hey all. I would like to get some insight on a question that I have been trying to find some information about. If you are the solo developer that is building a project from ground up, how do you manage the project? In the past, I have worked on a few personal projects that have grown into fairly large projects. In almost all of those projects, I have tried to wear the hats of all the roles that would normally be in place during a normal software development project (i.e. Product Owner, developer, architect, tester, etc.). It seems that when I leave the project for some time and come back, it is extremely hard to get back into the rhythm of what I was doing. So with that, I have some questions:
If I know the requirements (at this
current time), do I record them
anyways? If so, how do I go about
doing this, and how do I manage these
requirements? Product backlog,
features list, etc?
If this is the case, are full blown product backlogs or use cases a little overkill?
How does one efficiently appropriate
his/her time to each respective role?
What would be a normal flow of events
that one would follow? Start coding
immediately, write down user
stories/use cases, then go into
OOA/D?
What diagramming/modeling would be sufficient for this level? Domain model, class diagram, etc?
Basically, I was curious how everyone out there in the SO community would go about developing a project from inception to deployment when you are the lone, solo developer. What steps, documentation, and other project related activities are needed to help bring this project from an impractical, hobby project to something more professional? Any help, references, or suggestions would be greatly appreciated. Thanks in advance.
The most difficult part, I have found, about developing solo is that it's just tough to keep yourself driving forward. Even if you're doing this to make a living (AKA, running your own software business), unless you have pressing needs (AKA, you're going to starve if you don't make money) it can be difficult to sit down and just code.
From your perspective, I would recommend following good software practices where it makes sense to. For example, if I were a solo software developer, I would have no reason to create a collaborative development environment. All I really need is an SVN server, my IDE, and a place to record documentation (might setup a wiki or a website or something). I would personally create a realistic schedule to follow and would work on sticking to that.
As for level of effort of documentation, that really depends on you and the product you are developing. For example, I would definitely recommend recording your requirements. Unless your product is trivial, there is no way you'll remember them all and why you wanted certain ones over others. Managing a full backlog, however, can be a job in and of itself. In the solo programmer case this may not make sense.
Basically, the point I'm trying to get across (and should be followed with every project - not just in this case) is have just enough management that makes sense. The rest should be focused on the work and the development of the product.
Something else you may want to look into is reading this - Agile Programming Works for the Solo Developer. There are other, similar, articles out there. Might give you some good thoughts.
If I know the requirements (at this
current time), do I record them
anyways? If so, how do I go about
doing this, and how do I manage these
requirements? Product backlog,
features list, etc?
I have two lists of features:
A high-level view which states the scope of the finished product
A list of the features which I'm implementing in this iteration
Because I don't need to communicate it to other people (yet) I tend to write down the things that I don't know about the project (if I already know it there's no need to write it down): it's when it gets too complicated, or when there are details which I haven't defined but need to define, that I start to define them in writing.
I did however try to investigate/make a business-case for the project before starting coding.
How does one efficiently appropriate
his/her time to each respective role?
I did non-programmer, product-owner thinking at times when I had to be away from the computer anyway.
Apart from that, my cycle is:
Implement more functionality
Integration-test it
[repeat as above]
Every 3 to 6 months I compare the new-functionality-accomplished against my estimated schedule, and then recalibrate: i.e., make a new list of the highest-priority features to implement in the next few months.
What would be a normal flow of events
that one would follow? Start coding
immediately, write down user
stories/use cases, then go into OOA/D?
I started with working part-time or in my spare time, to make sure that I had:
Understood the required functionality
Made significant architectural decisions
Written any throw-away prototypes as necessary to learn new technology
After that I was ready to start developing full-time.
What diagramming/modeling would be sufficient for this level? Domain model, class diagram, etc?
I'm not using diagrams at all (except for sketches of the UI). By structuring the code, and refactoring, I'm able to know/remember/rediscover/decide which software components implement what functionality.
It seems that when I leave the project
for some time and come back, it is
extremely hard to get back into the
rhythm of what I was doing.
You need to comment your code more. If you leave the code, come back in two weeks, and can't remember how the code works, you need more comments.
If I know the requirements (at this
current time), do I record them
anyways?
Yes, for the same reasons stated above.
how do I manage these requirements?
A feature list is OK, provided you have enough detail in each feature to jog your memory.
How does one efficiently appropriate
his/her time to each respective role?
Break down each feature into smaller and smaller tasks, until you feel like you can do each task in a half day or less.
What would be a normal flow of events
that one would follow?
That depends on your development style. In general I would follow a clear but simple architecture, avail yourself of software patterns where practical, and provide adequate unit tests for your code as you go.
What diagramming/modeling would be
sufficient for this level?
Sufficient diagramming/modeling to make the project clear in your head.
What steps, documentation, and other
project related activities are needed
to help bring this project from an
impractical, hobby project to
something more professional?
Other than what I have already mentioned, make sure you have a good source control system and daily backups in place.
Good luck!
If you believe there is a chance that you're going to work on the project for some amount of time, leave it, and then come back to it at a later date...your best bet is to treat the documentation for the project the same as if you were working with a large team.
That means documenting requirements (even if they're from yourself), writing use cases (if functionality is going to be complex, otherwise some other form of documentation could suffice), and some level of UML diagraming (or other domain specific diagram) which could include activity diagrams/class diagrams/etc.
That way, when you leave the project for some amount of time, you can come back to a well documented idea and pick up where you left off.
As a side note, I try to do the majority of those things no matter what...that way if I ever find somebody interested in working on the project with me, I can get them up to speed quickly and get them on board with my ideas.
This is how I work, YMMV:
Keep a spreadsheet for high level of everything - list of your projects, and some top-level items/todos/reminders
Create a "project" folder for each product/project you have or work on, and create a strucuture to contain documentation and code for the project.
Keep a top-level "catch-all" document for each project, in the root of this folder. Keep you ideas, research, notes etc in this doc.
Then if you want to get organized, keep an MS project file (or similar) and plot out timelines for the various steps in each project. This is good for tracking progress on each project and make sure you arent forgetting anything. Basically keeps you honest with yourself.
And if you need to track progress on project work you are doing for clients, I understand Basecamp is a good solution for this. I am currently evaluating it for my own company. See www.basecamphq.com
Even as a solo developer, you should document at least the overall features of your project, and then the requirements for the particular feature you are working to complete, and then maybe produce a short pseudo-code for the functionality you're currently working on.
That way, if you do end up breaking away from that project, you can get back to it and see where you're up to easily enough. It's also pointless getting too far ahead of yourself with details for this same reason.
It's also a neat motivational tool for a solo developer - getting through and ticking things off is a way to show progress - something that you can start to feel you're not making when you're chewing through a couple of thousand lines of code and it seems like you're still miles away from actually having 'module x' completed.
Lastly - with regards to code comments - I at least try and fill out what actions/behaviour a new function should have in an outline, and then write the code in between the comments. Also, it is useful having plain English explanations of why you're branching in an if/else to support the logic in the condition...
I belive that better results in solo development one can achive with appropriate tools support and tasks that compensate lack of ohers people and help to organize working time. Any tool that generate metada with minimal create time cost describing your software is helpful.
VCS and tools for tracking user actity/code changes history - very important is to add good commit messages
mind-mapping tools for storing project related data (e.g. XMind), blacboard is useful too :)
time tracking tools (e.g. Toggl.com)
write a lot of acceptance test and use acceptance testing frameworks
Of course these clues also fits in non solo development :)
As a lone developer, I've found that your time is very expensive. This means that you have to balance sustainability and momentum - even though you are just one guy, you have to do things so that the you six months from now can go back and look at old stuff without wasting time, without spending so much time maintaining the systems that it compromises your flow.
Your question suggests that you are thinking in terms of fairly heavyweight tools and processes, but the 80/20 rule applies - for example, you can nail documentation well enough by TDD, using the doc tools of your platform to generate API docs, plus a Wiki for specs, lists, etc.
In that vein, I would suggest that you choose your platform carefully. The question about modelling suggests that you are using a platform that produce a lot of code and artifacts, but you may be able to get most of the functionality for much less management overhead elsewhere. Today I'm working on a .NET Web app that I wrote "the right way", but now realize that I could have delivered the same functionality much more efficiently in this case by using PHP with a PHP MVC framework to keep a clean structure.
Specific tools that I'd recommend:
A distributed version control system (much less overhead than centralized)
The most lightweight platform that you can use that has good tooling
A Wiki to easily capture and maintain small and large bits of content
Whatever testing framework that you can use, right from the start of the project
A lightweight TODO list system that you can access from anywhere
I used to work on a very small team (one dba and one C# developer). Even then I found it very useful to have written requirements, formal tests, source control and bug tracking (we used bug tracking for our features as well as bugs). It helped us to not forget anything and a year later when you were doing maintenance, you had something to research though to help you undersatnd what you did. Plus when the two of us left (as most people eventually move on) there was documentation there for the next person.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Perhaps the most obvious way of protecting a company's intellectual property from its own developers seems to be an NDA - Non Disclosure Agreement. Effectiveness of this approach may vary, depending on many factors, and sometimes or somewhere it may not work as expected.
What other approaches, apart from this purely legal one, exist for protecting software code from the people who develop it? Do they exist at all? Does it make sense in practice?
Maybe, for example, Team Edition of Visual Studio already contains some features related to this problem (for example, levels of access to parts of code, depending of role inside a development team or something like that)?
Reference on the topic:
As statistics says, on average, programmers tend to change their job every three - four years.
Try to build a team you can trust.
The first approach is to force programmers to only know interfaces of other components, so that each one can only steal a small part of the whole software. This approach can be borrowed from footwear production. One transnational corporation, to prevent stealing by employees, arranged its factories so that each factory produced only left or only right shoes. You could do the same with your code: some programmers only write lines with odd numbers, and the others--those with even numbers; provided that they can't see the work of each other! That's sometimes referred to as "pair programming".
Some organizations force employees to sign a non-compete agreement. That's the kind of agreement that prevents programmers to work for competitors. This technique is best combined with job postings like "Looking for senior programmer with 5 years of experience in the similar field".
To prevent your programmers from stealing, you can do harm to them as soon as they finish the software. The method proved itself as the most efficient, and has been used for centuries. For example, Russian Tzar Ivan The Terrible burned eyes of the architect that designed a beautiful church at the Red Square, so the one designed remains the most beautiful ever. You can do something like this to your architect. I heard, latest Visual Studio contains some features...
Nowadays, however, it's more humanistic to hire already blind and already dumb people that lost their hands, so that they can't look at your code to memorize it, can't tell anyone about your code and can't type it again. The advantage is that this will help you dealing with labor agency in your country, which watches for balance that your employees are not discriminated.
And yes, this post is a sarcastic joke, which criticizes the idea of any code-stealing-prevention measures. Sorry, couldn't help posting it.
How do you protect a power plant from sabotage by an employee? How do you prevent a boxer from throwing the fight? How do you prevent a brothel from distributing the clap?
Your concern, while valid, is one that can only be properly addressed by personal responsibility and accountability within your team. Any options you employ to secure the code against theft is likely do more harm than good. If you feel a team member is not trustworthy, get rid of them.
If really necessary you can split the application in subapplications.
Each team works in a single application and sees all others as "black boxes". Maybe SOA helps here.
It's highly unlikely that your code is the real intellectual property - that is your company's business knowledge and process.
SVN has the ability to limit different users to different folders, so you could split your code up into seperate libraries, and allow only certain people Read / Write access.
The file for this is under conf\authz
Here is a sample
[aliases]
# joe = /C=XZ/ST=Dessert/L=Snake City/O=Snake Oil, Ltd./OU=Research Institute/CN=Joe Average
[groups]
# harry_and_sally = harry,sally
# harry_sally_and_joe = harry,sally,&joe
[/
# [/foo/bar]
# harry = rw
# &joe = r
# * =
# [repository:/baz/fuz]
# #harry_and_sally = rw
# * = r
Some documentation can be found here
Under 'Per-directory access control'
Either build a team of developers that you can trust, or entirely lock their system down so they can't access the USB ports, the CD drive, or web mail clients. The only thing they could do is work on the code and possibly browse the web. Also only give them access to the code that they are in charge of.
But with all these security measures chances are your developers will hate working with you and quit their job
There's no straightforward way to do this if your code is within the same project (i.e. you want to allow access to some parts of the code and not others). However, if you have seperate projects that require different security levels, it's possible to allow developers to only have code access to certain projects, and then pull builds from a common build server.
Keep in mind that decompiling of frameworks that work against IL like .NET is relatively straightforward, so preventing access to the code files is not necessarily a silver bullet to protect IP.
I know you said aside from the purely legal one, but I'd just like to add that in addition to the legal one you mentioned, there is also the Non-Compete. Basically says that once you leave your job, you won't be able to compete in any way against your former employer. Stealing code is not as appealing if you won't be able to put it to use for a year or two.
You could make them develop a module that would be seperate from the rest of the application. If you had a plugin/module type system going this would suit well. You could release APIs for the developers to develop against and have them integrate with your DLLs and not the source code.
People seem to be very critical of this but there are legitimate reasons for doing this i.e. partnering with a potential competitor if you gave them all your source you would be shooting yourself in the foot.
It might be worthwhile to spend some brain cell activity on the business model you want to follow. If the core value is embodied in the code, the core value can be stolen by stealing the code. If, however, the core value of your business is embodied in a group of employees, some of them engineers, others sales people, yet others customer support people, and when the software is only the net that keeps these peoples business going, then there's no easy way of stealing the value of your business. And if the software does get stolen, the thieves won't be able to make much use of it.
So, in addition to what cherouvim said, build a team that you can not just trust, but a team that is the core value of your business.
Develop your software in modules.
Have one common module that contains objects that pass back and forth, and utility classes that act on those objects.
Have each group build modules on top of that, without much need to know about other modules.
Have one trusted team of developers do the planning of what goes in each module, and have that team also do the integration of all of the modules into the whole.
Also have a lot of trust in whoever runs your version control server. While it's stable, no one developer can do all that much harm; they can't delete everything, for example, and you'll know exactly what they did and when if that ever becomes an issue.
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.