I took a development job once, where I learned on the first day:

1. No backups. Emergency plan = several older copies of the product's source spread among hard drives of various former employees' systems.

2. No source/revision control. Current version of the product's source code was literally whatever was on the lead developer's hard drive at the moment.

3. No deployment process. When a release had to happen, above mentioned developer would build an EXE out of whatever he had (if it built) and directly deploy it to customers.

4. No dependency management. What versions of vendor-provided libraries do we use? Whatever is on the guy's hard drive. Oh, and they're all binaries because we either lost or can't build the source anymore.

5. No bug tracker. The list of stuff that needed to get worked on was whatever the CEO complained about last. There was no concept of a backlog of existing bugs or technical debt.

6. No documentation. But are you surprised at this point?

7. Setting up an environment to build the code was a manual process that relied on searching through past E-mails for lost tribal knowledge, which basically amounted to: Try different include and library paths until there are no errors. Once built I was greeted with 2500+ compiler warnings... (out of 200 or so C++ files).

Oh, and this software ran in airplanes.

>took a development job once, where I learned on the first day: No backups, No source/revision control, No deployment process, No dependency management, No bug tracker.

And that is why one should always ask about these important things before the first day, i.e. during the interviews, before you decide if you want the job or not. Fortunately I'm in a position that the above would be a near-automatic "no" from me.

edit "Near" automatic as there might be a way out if the company knows that they need to improve drastically and has the will to do it. The other response "what were you able to do to improve the situation?" is key.

Unfortunately, often the answers you get when you ask in an interview bear very little relation to the reality you find when you start a job.

Sounds like a small company making a niche product.

What were you able to do to improve the situation?

Which issue did you tackle first (documentation of processes backwards or source control forwards)?

I'd like to think I left the situation far better than I found it.

Tackled source control and issue tracking first since they were low hanging fruit. Next came basic (manual) backups. My background is not in putting together general office-wide IT solutions, so I did not feel qualified to recommend any specific package. After that, it was on to a sane build and deployment process that involved a dedicated build machine and included QA. After a long time I could start safely making code changes to clean the actual codebase up.

I think you'll see this a lot in manufacturing companies who sell physical hardware. The embedded software is a critical part of the product, yet it's not treated with much more care or seriousness than anything else on the BOM. Night and day difference between working at a company where software _is the product_ vs where software is just one of the many components that goes inside the product.

Thanks for reply. Software for manufactured systems is an area that can only grow so I hope more get involved in the way you did.

Definitely not safety critical software passing any level of DO-178 certification...

Nope, thank goodness.

Are you a consultant? It would make sense that companies that need to hire a consultant for these types of things are the companies that aren't currently doing them.

My favorite right now is pom.xml files declaring dependencies that don't exist in the corporate Maven repository, nor in any public one. Kinda defeats the whole purpose of using Maven if I have to go download jars manually.

It can go too far the other way :)

"What's your revision control?" "Git." fine "And Mercurial." Okay "And SVN. And CVS. Some are hosted locally, some are accounts on Bitbucket and GitHub".

"Build system?" "Cmake. And Scons. Depending on which version of the software you're building. And Make. And some bash scripts."

> First question: "Backups?" followed by "When was the last time you did a restore?"

KDE almost lost hundreds of their git repositories in 2013 because they were not doing backups ( https://news.ycombinator.com/item?id=5432760 ).

>"git" or "mercurial" tells me I have an team that has some level of clue.

If you're judging a team being clued in by the SCM, you're doing it wrong. There are great teams that use SVN, and know-nothing teams that use git.

The measure of clued-in should be how well does a technology match the organization's needs?

A few years ago we introduced svn in our company, to replace PVCS. After 4 years, we managed to hunt most of our source code down and get it commited somewhere. Now, we have loads of contractors, some good, some bad, most cheap, and almost nobody longer than a few months. After seeing what insane things some of these guys managed to do in subversion, I simply don't dare introducing git: The history rewriting features like rebase in their hands scare the hell out of me. At least with subversion, i know that what's in there stays in there. git is great if you can trust your people, but svn is a better choice in a large political company that does not care about what happens to its code.

And dont get me started on the abuse of backups or build systems.

You need to look harder then, we tick all three and even use Gitflow. With back ups used all the time for testing live state locally and a CI 1-click (well 5 or 6 actually...) deploy to Test/Stage/Prod.

Congratulations. You're the 1%, you don't need my services. :)

I came from an awful IT environment and even my team met your criteria. I think you might be primarily exposed, due to the nature of your work, to the worst of the worst. We had/have a lot of technical debt, but the architectural ones are the hardest to fix (because they cost real capital). You wouldn't believe how hard it is to get sign off on new servers (at some companies). My team nearly made an executive decision to switch to GCP or AWS just to escape our own internal infrastructure group.

Believe me, there are 10.000 million dollar non-software companies that barely use version control, and with extremely awful IT departments. And there are companies making a killing selling software to said companies.

I'm very glad I don't and all power to you spreading the good word :)

where are you working or interviewing?

I think, at least in sfbay, it's safe to assume git. And probably some CI tool. This is true across my personal sample of perhaps 15 companies that I know well enough.

You would be surprised. Even in the Bay Area.

The Bay Area is better than most places, but the moment you aren't dealing with a purely software shop, the probability they don't have this stuff goes through the roof.

The PCB design tool Altium only has provision for using Subversion (which is fine, thanks), but the number of people who actually USE it is miniscule.

Sorry about the downvote! accidental keypress!