185

It is absolutely not normal for a group that size to be working without source control—the size of the largest group of programmers that can work effectively without source control is less than or equal to one. It’s absolutely inexcusable to work without version control for a professional team of any size, and perhaps I’m not feeling creative, but I can’t ...


147

Stop doing the 80 hour weeks. This is positive reinforcement. Because they are getting the product on time with expected costs, they are going to continue doing it, regardless of what it does to you. If they cannot budget time properly, then that's management's fault. Not yours. Let them miss a few deadlines.


108

It may not be normal, but as Treb says, it's probably not that unusual As others have said, there are no valid reasons for not having source control in a company your size. So you need to identify and attack the invalid reasons: a) the main one is the status quo: "if it ain't broke, don't fix it". This is difficult: you could start pointing out all the ...


96

In general, is there a way to push back on this? If not for this release, what about in future? Of course, there is: Let them fail badly with this approach. Nothing teaches as well as failing. Make an estimation yourself before you start and show it to them. Then do your best, write good code, stop compensating for their stupidity with your free time, ...


52

This generally occurs because of a perverse incentive - the salespeople are being paid on commission, while the production staff is paid on salary. The salespeople have several levers to work with: features, cost, and delivery date. They have a strong disincentive to lower the cost, because this generally lowers their commission, so they tend to ratchet UP ...


34

Is it normal for a group of this size not to have source control? In my experience, it is not the norm, but not as completely unusual as other answers here suggest. The majority of small companies does use source control, but a significant number doesn't, unfortunately. I have so far been given only vague reasons for not having source control - what ...


29

You hesitate because you don't want to make semantic versioning, you want to make "advertisement supporting versioning". You expect a version number "2.0" to tell the world that you have a bunch of new cool features in your library now, not that you changed the API. That's ok (many software companies and/or developers do that). IMHO you have the following ...


27

Source-control is good for even a single developer team. Any source control system is basically a version control system that keeps the track of changes. Imagine of a single developer, who might have removed some code and feels that the code is now required. Can he get the old code back? Just go for a tool that helps you. The size does not matter everywhere....


27

Most places I have worked the QA people do have some sort of sign-off step, but do not have final authority on if the release proceeds or not. Their sign-off represents that they completed the testing expected by the release plan, not that the release is flawless. Ultimately QA != the business and the business needs to decide if they are OK with deploying ...


27

Personally, I choose option 3: keep versioning information in VCS metadata, specifically, tags. Git makes it very easy to do so, because there is a command git describe, which can uniquely describe a commit based on a tag. Here's how it works: If the current commit is tagged, output the name of the tag. Otherwise, walk the history backwards until you find ...


26

The development team must be consulted on these decisions or you will never get out of that cycle. If you aren't managing the team, then one of your line managers needs to advocate for the development team. If they are part of the problem, then you may want to consider other employment options. Generally speaking, Sales shouldn't be committing to anything ...


21

This is almost a universal thing in smaller companies as they have a greater need to close a deal. Until I was brought into sales meetings at my company I was bitter about this but I can at least understand how and why it happens a little more. Clients want it fast and many will play hard to get. This encourages sales to bend on time commitments just to ...


21

Two options: a) Don't. Just make sure you have reproducable deterministic builds, that is, building the same source control revision with the same configuration always produces the exact same binary. b) Designate a directory somewhere as the authoritative source for published builds. Make uploading the binaries part of the deployment / shipping procedure,...


21

In my experience, it's easiest if you can have a development and release cadence that doesn't get in the way of what you want to get done. Here's how I've done it: Write the features down, and give them a rating that reflects how much you want to work on it and how much you think it will benefit the user (it may be possible to engage actual users for this). ...


20

Semantic Versioning seems to be at conflict with most desktop application numbering. We solved this by handing over "product versioning" to the marketing department, and we maintain completely separate (but logical to us) versions for all the components. A specific product version then becomes a defined collection of compatible components. Maintaining ...


18

The answer here is to communicate. Tell the technical/team lead about the issue Talk to QA about the potential impact Tell project management (who is right behind you) that there might be an issue that causes the release to be delayed, and you will get back with them ASAP (in a matter of minutes or hours) Evaluate whether this issue is a show stopper for ...


17

Tags and branches aren't mutual, you can (and IMO usually should) use them both. Tags are there to mark milestones in development. E.g. you open a branch for version 1.2 of your product, and you mark v1.2 Beta, RC1, RC2, Final (and then, if needed, SP1 etc.) with tags on that same branch. I personally prefer Method 2 as the default approach (although I try ...


17

It sounds like you are already using a system of version control, but not a very good one. People already seem to recognize the need version control. You just need to introduce them to the next level -- software version control. If it were me, I would introduce SCM as an improved version of what they are already doing. I would emphasize how using a good ...


16

You should not have stabilization sprints. Your software should be releasable every sprint. This means that if you need stabilization, that has to happen within each sprint and not just before a release. Once you achieve this, release planning becomes a product owner concern ("What features to I need in order to release?") and stabilisation a team concern (...


15

Option A. Just using mainline and tagging for release Pros: You avoid merge hell. Keeping to the mainline encourages some best practices like proper release planning, not introducing a lot of WIP, using branching by abstraction to deal with out-of-band long term work, and using the open closed system and configurable features for dealing with ...


14

+1 for touching upon a great subject. When we do "Release early release often" line of development, things pick up real pace and as the momentum builds many such issues arise (as you described) which we are otherwise not very prepared to cope up with. Worst fear is when people see speed as an enemy of good work. I have seen very limited literature on this ...


14

I'll try to post some helpful hints, but with all due respect, this is Release Management 101, and if you really have a huge code base and a need for parallel work streams in the organization, you would do well to either read a book on it or hire somebody with more experience in this area. Assuming this situation: The business needs new functionality that ...


12

I adapted semantic versioning for desktop or web applications, so in our work we are using: X.Y.Z Z is increasing if a release contains just a bug fix, dependencies update or some application internal changes, so no new functionality introduced to user; Y is increasing if a release contains minor changes in UI or just introduces some new feature, or some ...


12

If I were in your shoes, I would take this as a chance to improve the build scripts so they can provide more detailed information about what exactly is failing, so finding the root cause should be a much simpler process than it seems to be now. Moreover, instead of "simulating their operating environment", why don't you just walk over to the place of the ...


11

I've worked both sides of the house. Remember without sales people there would be no downstream jobs or projects. How to battle sales over-commitment: Estimate, then take at least a 130% multiple (always plan a minimum 30% contingency). Provide and document said estimate. Realize that your effort estimates will be reduced in the sales process. That's ...


10

Never during. That violates the basic premise of a "sprint". You run until you finish what you committed to finish. After you finish, it's really done and really works. You can then release it. Release can be a separate kind of sprint where things are packaged for release. Bugfix releases can be just short sprints. Not having a regular schedule of ...


10

TL;DR: Release whenever appropriate We do releases whenever there is value in doing a release. Sometimes that means doing a release after a single feature or bugfix is completed. Sometimes that means releasing a collection of features and/or bugfixes. This doesn't mean we often have "emergencies" that require fast releases. It means we've worked hard to ...


10

There are lots of strategies you can use, but you'll usually need approval or buy-in from management. Pay developers overtime at an increased rate. Working extra hours isn't so bad when you're making a lot of extra money doing it. And if it starts to affect the company's bottom line management will apply pressure to sales to do a better job estimating. Pay ...


10

Use an artifact repository for binaries, not a version control system. A specific version of a released binary is not supposed to change over time, hence version control does not make sense since the file(s) wouldn't change. See for example Maven repositories as a repository to archive/publish/offer releases and other binaries (e.g. such as documentation)


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