E
Eric Hansen
Guest
Long gone are the days of needing to purchase $15,000 applications to perform a task worth only $1,000. A lot of companies are looking to develop solutions in house now instead of going to others to make them. However, there are still quite a few people who use third party developers for products as well (i.e.: HootSuite for social media management, Log Rhythm for log management, etc…). The question becomes what is the best route to take? Lets outline some factors that should go into making this decision.
Manpower
One of the first criteria to consider should be man power. Do you have the resources to make it happen with the current staff, would you have to hire people to develop and/or manage, etc… Sometimes the cost of developing it yourself doesn’t outweigh what it would be to go to a third party. But, its also up to the budget and staff.
Lets take HootSuite for example. If you were to develop a similar application in-house, you would need at least 1 developer, 1 designer (could combine with developer), 1 tester and 1 maintainer. This is the bare minimum. Of course you could tie all of them into one, but that’s another “does the cost make it worth it” moment.
There’s also the suggested idea of writing good documentation and making it legible to other users.
Skill Level
Even if you have the manpower, do the people involved have the necessary skills to make the application possible or a success? There very well might be a need for some training, but if there’s going to be a lot more training than work, should you even consider it?
This is a tougher one to consider, as the development in project 1 might mean 20% improvement for project 2, but that doesn’t mean you’re going to even want another project done.
Time
From experience, projects never get done on time. There’s always small bugs that escape testing, new features wanting to be added, etc… that prolong development. If this is something needs to be put out in 6 weeks, when it would realistically take 6 months, you need to factor that into everything as well. The golden rule is that programming is 20% actual coding, 80% debugging.
Reusability
Even if you don’t plan on making another in-house application, you should think about reusability.
A good example of what I mean is within my SIEM. From the start I knew I wanted to make it modular, so I wrote a simple plugin class that let me load all my plugins in at once. This left out all of the guessing if something exists, and let me get to coding the actual application faster and better.
Later on, I decided I wanted to make remote programs modular as well for similar reasons. This was easy enough as I had to just edit a few lines in my plugins class, and voila, it was reusable in the remote programs. Simple and easy, right? It is, and you can see it outlined in a small blog post I wrote about it here: http://www.cryptd.org/posts/2014/07/serverclient-for-nexus/
Conclusion
There’s other aspects involved too, but they tend to be either specific to the application, company, or both. I.e.: what language should you use, should it be hosted on its own box, support multiple database types, etc…
This wasn’t intended to be a de-facto standard listing, but enough to get the wheels turning on this to figure out if its even worth it.
Manpower
One of the first criteria to consider should be man power. Do you have the resources to make it happen with the current staff, would you have to hire people to develop and/or manage, etc… Sometimes the cost of developing it yourself doesn’t outweigh what it would be to go to a third party. But, its also up to the budget and staff.
Lets take HootSuite for example. If you were to develop a similar application in-house, you would need at least 1 developer, 1 designer (could combine with developer), 1 tester and 1 maintainer. This is the bare minimum. Of course you could tie all of them into one, but that’s another “does the cost make it worth it” moment.
There’s also the suggested idea of writing good documentation and making it legible to other users.
Skill Level
Even if you have the manpower, do the people involved have the necessary skills to make the application possible or a success? There very well might be a need for some training, but if there’s going to be a lot more training than work, should you even consider it?
This is a tougher one to consider, as the development in project 1 might mean 20% improvement for project 2, but that doesn’t mean you’re going to even want another project done.
Time
From experience, projects never get done on time. There’s always small bugs that escape testing, new features wanting to be added, etc… that prolong development. If this is something needs to be put out in 6 weeks, when it would realistically take 6 months, you need to factor that into everything as well. The golden rule is that programming is 20% actual coding, 80% debugging.
Reusability
Even if you don’t plan on making another in-house application, you should think about reusability.
A good example of what I mean is within my SIEM. From the start I knew I wanted to make it modular, so I wrote a simple plugin class that let me load all my plugins in at once. This left out all of the guessing if something exists, and let me get to coding the actual application faster and better.
Later on, I decided I wanted to make remote programs modular as well for similar reasons. This was easy enough as I had to just edit a few lines in my plugins class, and voila, it was reusable in the remote programs. Simple and easy, right? It is, and you can see it outlined in a small blog post I wrote about it here: http://www.cryptd.org/posts/2014/07/serverclient-for-nexus/
Conclusion
There’s other aspects involved too, but they tend to be either specific to the application, company, or both. I.e.: what language should you use, should it be hosted on its own box, support multiple database types, etc…
This wasn’t intended to be a de-facto standard listing, but enough to get the wheels turning on this to figure out if its even worth it.
