New answers tagged

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 ...


0

If by "is it normal" you ask if it is common, no, it certainly isn't. A lot of dev teams have poor test practices (I belong to one) and even quality books I've read advice to spend roughly as much time coding the functionality than the tests. If by normal you ask if it is healthy, it depends, but two times more tests than needed is better than no test. It ...


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 ...


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 ...


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. ...


0

In a situation like this I always mention that on the contract so I would say that I will give them a 30 day period to make any changes to the project and for support I would normally give them free support for two times then I would charge them the regular rate per hour/visit.


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. ...


-6

Indefinitley. There are two issues to consider: There are a limited number of possible bugs. So the bug fixing cannot go on forever, as long as you are strict about what a bug is. If something does not match the spec, you should fix it. There are an infinite number of new features, some of which your client will want, some of which they will consider to ...


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 ...


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, ...


-1

I've written and maintained a reasonably-sized commercial package in assembly language (40,000 lines of 16-bit code and 35,000 lines of 8-bit). It worked well and had zero bugs. The only inter-module communications possible were that a symbol (an address in program code or a data address in memory) could be declared public in one module and external in ...


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 ...



Top 50 recent answers are included