Hot answers tagged

7

First of all, your current approach seems perfectly valid. Working from several systems (I understand here several PCs in different places, or eventually different OS compiling the same sources) doesn't change the fact that you still work on the same piece of software. So this should not not be the major influencer of your branching strategy. However, ...


4

This is obviously up to personal preference, but here's my pick. It really depends on what your role in this project is: if you perform things such as project management or technical work yourself you can get by with hiring other people. If you do not take the lead of this project from a technical perspective, I'd advise you to take the senior on first. ...


4

IANAL but you need to spell out in the contract if there is a warranty. Typical software has no warranty. You also need to express no damages if lets say they make a bad business based a bad number from the program or loss of a client. Is is common for no warranty and then like 1 month courtesy. You also should give them a time period for acceptance testing. ...


2

A book could be written on this topic. I bet some have . . . It's hard to answer because each tool-chain has its own strengths, shortcomings and quirks. I must have structured different projects a half-dozen different ways, but I will mention the two that I've used the most. For almost all techniques, you need to partition the components adequately. The ...


2

Code that is common to A and B should be moved to the base project. If anything is left in A after doing that move it to flavor 3. When you're done B should only have flavors in it. It's really that simple unless there is something you've left out. Remember, projects exist for conceptual separation more than anything else. If having multiple projects is ...


2

I would consider defining a flavor by a configuration file rather then a collection of interfaces. I would imagine it being something like this: features: - FOOBAR - GOATS - HOUSES frobnosticator_mode: FLASHY server_address: www.example.com name: "Flavor Fantastic" length_of_music: 2012 supports_cows: True Whenever your code needs to behave ...


2

Rule of thumb: Use as few branches as possible, and as many branches as necessary. If a branch is necessary or not is something you mostly learn from experience, but when in doubt: don't branch. The reason for this is branching hell. You need branches when you need to modify the same code at the same time in 2 different ways, for example when you release ...


1

Start with the senior software developer, so you have someone else to help you come up with an overall architectural design for the project. This may influence your later hires significantly. For example, if you decided that the application was going to be heavily database-oriented, or you were going to use an enterprise-grade database such as Oracle ...


1

I share @JDT 's opinions overall, but with a few tweaks Senior software engineer My personal first pick. Why? Because he'll basically be the glue between the view and the data. Good ones will typically also be able to mock up the database and the UI. This helps to clarify the requirements and identify road blocks early on. It's also a difficult to find one ...


1

There is the law of diminishing returns. Assuming you write tests for the riskiest code first, the value generated by further tests diminishes over time. Unit tests are code, so they will contain bugs (just like all other code). Fixing those bugs takes time. In my experience unit-tests contain far more bugs than the system they are testing, and fixing ...



Only top voted, non community-wiki answers of a minimum length are eligible