How to assemble a project with software products and your own code

Question

Hello, Let's say you have a specific project on hand, it can be divided to parts, and you are not completely sure about all the difficulties that will arise. Time is of the essence.

• How do you decide whether a part should use software product or your own code? (considering, that some tools are awesome, but will require much time to learn)
• How do you choose the right software product?
• How much time (as a percentage) should this stage of choosing the right product, if any, take, and how much time to evaluate a single product?
• Is there a way-back, is it o.k to change your mind, after putting efforts in a product, and finding it not suitable?

I would love to hear any rules of thumb about those.

Answer 1

Changing your decisions is like changing your blueprint for a house while it's already being built.

It will entirely depend on what you have spent in time and money to that point.

Some considerations:

0) Understand the problem in clear and simple terms before beginning. Know what's critical to it's success and then use that list to see if any software, language, or tool will aid it, and at what cost, and if the cost outweighs the benefit.

1) Use a crammer's schedule. Build it in the order of what you would build if you only had 1 day or 1 week and no more to work on it. It's amazing how much doesn't matter anymore when you have to do 50% of the features at 100% of the quality. Focus on value, value, value. Read something like 37 Signal's book Getting Real for more on this.

2) Do not re-invent the wheel. It's always easier it seems to build something from scratch. Unless you are doing a fraction of the implementation and it's truly simpler, meaning you can avoid abstraction until you forget what you were building, consider it. If you can build it faster, better, cheaper and in the same amount of time, do it.

3) Know the features of your tools, and the benefits any tools need to give your solution. You should be familiar with or at least aware of many of the tools out there that you may or may not integrate.

4) Pick a language that is used to solve a lot of problems. Chances are you will find many great libraries and tools to build your software that will save your time. If you need something that delivers, can run, and you can lean on the smarts of others, use something established, or a language that can access .NET or Java easily if need be.

Answer 2

As in any art the difficulty is composing a good solution based on a very large possible solutions space. There as many ways to go about this as there are developers.

I’d normally spend some time understanding the problem and stating it clearly and succinctly as possible, preferably in a written form. The problem description should be completely abstracted away from any possible solutions. Next I’d normally list available constraints that will need to be applied to the solution (time, budget, legal, political, performance, usability, skill availability within team and so on).

Then the theory goes that you need to look on the market for something that solves the problem and meets the constraints at the same time. In practise, the process is not that straight-forward: you try to identify market categories that are likely to be useful, then research them, see what is available and continuously try to reduce the gap between the constraints and capabilities as much as possible, often by going back and revisiting and re-negotiating the constraints.

A few generic tips:

1. During the research keep coming back to the original problem.

2. There is always more than one solution, try to extend breadth (concentrating on very different ways of solving the problem) of the search space before going deeper.

3. Be clear on a number of options it’s worth researching, and amount of time worth spending on each of them before making a decision whether to investigate further.

4. It’s seldom worth finding an optimal solution, especially then technological landscape keeps changing very rapidly. Look for a solution that is good enough: “The Paradox of Choice - Why More is Less”.

5. It’s rarely worth turning to users for help (unless they are software experts) on choosing between several options. If you’ve got a number of options all looking equally attractive that means you need to go back and understand the original problem better, it’s likely you’ve missed a requirement or two.

6. Some further notes on using third-party components (refers to GUI components, but easy to apply to other software areas as well).

7. And even more notes on scoping, composing and researching for a project.

Answer 3

• How do you decide whether a part should use software product or your own code? (considering, that some tools are awesome, but will require much time to learn)

Ask your self two questions.
1) Is it a mature product. If yes, then
2) How long it would take to create the functionality it provides on your own. If that value times your hourly rate is greater than the cost of the product, then use that product.

• How do you choose the right software product?

Consult your network of other developers. Have they used it, did they run into problems. Consult the interweb. Create a prototype using the product. Does it work well? Any major bugs?

• How much time (as a percentage) should this stage of choosing the right product, if any, take, and how much time to evaluate a single product?

It depends on the size of the project, and the criticality of the product to the success. Most of the time, you are going to be able to get a high level view of the product in a very short amount of time.

It may be just a few minutes using it before you say, nope - not ready for prime time. If it makes past that, a day or two of experimentation may tell you that it passes muster for your project.

If it's a huge project with many developers, then you probably want to spend more time doing a prototype application with it to be sure it's worth investing all that time in.

• Is there a way-back, is it o.k to change your mind, after putting efforts in a product, and finding it not suitable?

If you find it's not working out, there's nothing wrong with going back. In fact you probably have to. Ideally you will find this out early. Not at the 11th hour. Again, this is the purpose of prototyping.

Answer 4

For each part of your software you recognize as a software component/package:

1. How do you decide whether a part should use software product or your own code? (considering, that some tools are awesome, but will require much time to learn)

   • Ask yourself whether the component you are considering is a part of your product's main business core.

     • If not then it is usually better to use an existing solution and not send too much time on it.

     • If it is then make sure there is no existing product that is better than what you are planning. - It there is, consider purchasing licenses to it instead of developing your product.

   • Search online for similar components (commercial, open source and even articles/demo-source-code).

     • Do any of them implement all of your requirements from the components?
     • How much do they cost, would it cost you more to develop and maintain a similar component?
     • What are the license conditions? - Are they OK for your product?

     • If component includes a user-interface, is it plesent to look at and easy to use?

     • If you answered yes to all the above then do not develop the component yourself.

     • If not:

     • Is the component open source or published in an article / demo-code? - If so, it robust, could you take the code an improve it or use it as an example to help you write code that is more suitable for your requirements? - If so write your own code, use code as part of your own component that is not developed from scratch.

     • If your answer to the above is no, then you'll have to develop your own (or you're searching in the wrong places).

2. How do you choose the right software product?

   • See answers to 1.

3. How much time (as a percentage) should this stage of choosing the right product, if any, take, and how much time to evaluate a single product?

   • Clear an entire day, search for existing components, read about them (features, prices, reviews) and download + install up to 5 of them.
   • Clear another day evaluate 2-3 products, compare demos/examples, look at code, write 2 small examples of using each (same example different product).
   • If you choose more than 3, clear another day and test the others.

4. Is there a way-back, is it o.k to change your mind, after putting efforts in a product, and finding it not suitable?

   • Always design your software so that every component is replaceable.

     • This guarantees that there is always "a way back". (Use interfaces & adapter design pattern, divide to many assemblies, connect all components as loosely as possible (using events, binding, as etc.) - loose coupling.

   • Even if you implement something yourself make sure there is a way back - sometime you may use the wrong technology/design and have to replace a component with a new one you develop/purchase.

5. Other rules of thumb:

   Consider which application-wide technologies to use before considering each component.

   • Writing in assembly would take the longest, in C less, in C++ even less, in more modern languages such as C#, Java, Delphi even less.

   • Which has more of the self components that are relevant to you? What does your team have experience in.

   • If you are using .NET (C#), then WPF could help you lower the coupling between GUI and business logic and make a better looking GUI, however it take time to learn how to use it (a 5 day minimum course is very much recommended).

Answer 5

There are already some really good answers here, so I won't repeat it, however there is one point you should definitely consider, and though I would have thought its obvious I havent seen it mentioned here yet:
The personnel you have available to implement the solution, their core competency, and their general level of competence.
Who you have to implement this (assuming it's a team, and not just yourself - but relevant even if its just you, too...) can have a HUGE effect on the outcome. If you don't have experienced programmers to help you develop this, you're better off looking for some OTS product to do the work for you... Or, even if you have programmers who are not likely to succeed, you still might want to find a solution with lower overall project risk.