Also look at oursources payroll, time tracking (this is sometimes a must for R&D tax credit) and make sure you have some financing / funding lined up. You need to have a plan to cover the first 2 years of operations where revenue will be slim.
This will also allow you to avoid getting into the "anything for a buck" mentality.

Don't focus on development tools / standards. Let your programmers take care of that. You might want to look for a lead developer with experience managing junior / intermediate developers.

There is also no "bugless" mechanical system for that matter. Mechanical throttles have gotten stuck, brakes can fail, especially if they are poorly maintained. Poor maintenance usually kills mechanical systems, poor practice and poor programming create bugs. However software that is written will always behave in a definite pattern. Mechanical system will fail differently with different effects.

The systems:
- Switch to neutral or reverse
- Parking brake
- Brake override
- Push button quick presses
- Push button long press
- Speed limiter

If NONE of the system works, then I'd have to concentrate on not crashing for about 30 to 60 minutes, then the battery will run out. I'd crank the heat and open the windows to increase energy usage and drag to speed up the process.

If there is a passenger, they might be able to pull the emergency fuse plug from the rear seat floor.

Nissan supports both long press and push multiple times (3 times I think).

I've had the Nissan push button since 2009 and love it. No fuss, no issue, always started / turned on the first time.

On the Leaf it will also shift to Neutral if I press the park button while in Drive.
Worst comes to worst, it wouldn't take too long to drain the battery pack if all else fails.

Also the building companies know how much time is required to build a wall and every step of the way is time budgeted. If you wait too long to put the next brick on the mortal, it would be too dry and won't hold the brick. If you don't mix the mortar components long enough, then it might not hold up properly. Also the end product is very well known in advance (eg size, mortar color, brick colar, rows of bricks, etc). The customer agrees to the wall on paper before the work starts and can't go back saying "that is not what I meant when I said 5' high, its too high now and I don't like it " and expect it to be fixed for free. Each job is uniquely done for a specific customer to that customer's specs. Customer also tend to understand it that there is a certain way to do it.

The problem often times with software is that there is pressure to cut costs (less people, less time), cut time to delivery, cut tools, change requirements all the time, etc. The builders of software are rarely listened when it comes time to fix problems. Technical debt accumulates with every change that is done on a temporary basis just to satisfy the customer quickly.

Going back to the analogy, no one would ask a builder once the wall is built that brick at position 5,10 is not the right shade of color, change it now. Yet we expect this from software all the time. If builders would change all the bricks in a wall it would most likely fail.

My experience tends to mirror Backblaze, both with my own personnal business and as an employee at 2 different companies.

Seagates would always fail prematurely, but usually in a way that is noticeable through SMART monitoring. Interestingly it matches up with when they acquired Maxtor, which also started going bad when they bought Quantum. With my colocated servers for my side business I used to have to go at least twice a month to replace a failed drive. I eventually gave up on Seagate and replaced all but 1 drive (a spare raid member) with a mix of WD and Hitachi. I'm also really pissed at Seagate to have slipped so much in reliability, especially with their 7200.11 and early 7200.12 drives.

WD would fail sometimes, near when they were new. Where I worked previously, we had a policy of mixing new and old WD drives in a new server. It was a lenghty process but helped avoid losing a simple RAID1 setup.

Hitachi very good and usually inexpensive.

Where I'm working now we're trying out Toshiba and so far one drive failed out of 12, but that sample size is way too small and its not been long enough to truly tell how it will go.

I would call it experienced, same as me.

Where I work, someone had the bright idea that since you could stuff arbitrary data in mongo (for example multi dimensional arrays) that it should be the proper way of doing it.

So now I'm stuck untangling a website that manages millions of pieces of data in about 860 documents or so...

There are also various interesting issues that happen if you have a collection that start with _
Its only possible to edit it through the api, and not the command line mongo shell. The bug was open about 3 years ago and has yet to be addressed. Things like that make me feel that there is still a lack of maturity where it counts.

The problem is that a lot of companies think that agile is to have daily stand up meetings and keep changing the requirements or what will be delivered.

Once you have all the components (Scrum team, product backlog, sprint goals, sprints, daily meetings, retrospective, etc) things fall in very nicely as it gives the business people the answers they need (ROI mainly), what is commited to (a sprint) at a set cost (sprint length).

One of the easiest tool to estimate effort and business impact is to use relative value. Set something as x and rate the benefit/cost around that x for the other tasks. This gives a lot of leeway to business people to shift priorities to make sure that the team works on more valuable features first. The scrum team is also responsible for communicating back to the business people how much a feature will cost vs another feature.

Lastly the retrospective is one of the most cut out part of scrum, and it is actually the worst one to cut out. It is there to look at what happenend and figure out how to improve the team and get the team working efficiently. I've had quite a few of those meetings that ended up with the scrum master deciding to cut out specific members because they would fail to follow basic rules (like not overwriting someone's else work in svn). It gives a structured way to voice concerns about how things are going and the quality of the individuals that make the team.

Ford has an all electric version of the Focus and also has 2 extended ranges hybrid (C-Max Energi and Fusion Energi), and as far as I remember they are all under 40k too.

Baby Toy is a small app that just has some pictures of animals, musical instruments or robots and it makes sound / vibrates when one of them is touched. It has an option to lock into the app until some specific combination is pushed so it's very hard to get out of it.

Kid Mode is a shell that provides some apps that are age appropriate. We got a cheap white label tablet (7") and put it on it. It's pretty good and can wrap around other kid apps so that they can't get out of the kid mode / app easily.

We've mainly used both on planes and places where it gets hard to bring lots of toys. I do agree with the comments about sleep and melatonin production, whenever she used our phones / tablets near her sleep time it was harder to get her to sleep. We're now more careful about that.

Escalating is probably not going to help, and in most likeliness will hurt your career at that company.

1. This could be an opportunity for you to climb the ladder so to speak, even becoming one of the chiefs. At some point you'll need to angle things to become chiefs-of-chiefs between the other chiefs and your PM. However make sure the project can succeed with the setup, otherwise you'll get the blame.

2. You could also try to stay an indian, but that might mean you get canned with the rest of the team if the project goes wrong.

3. Transfer to another department if possible.

That's why everyone has their own...

There are some standards / practices that are very important when it comes to making secure code. They avoid basic mistakes and so on. There should also be some minimal enforcement in terms of how to indent which always help to reread the code. Peer review for anything complex is also a good practice.

As for camel case, or hungarian notation, I feel that they are mainly a waste of time in the best of case. Being pedantic about code isn't going to help anyone or any project, in fact it might make a lot of talented people leave the company.

The big ISPs all have interest in the fight as their parent companies tend to own producers of content (Quebecor and Videotron, Shaw and Global, Bell and CTV, etc). They also are distributors of media (cable, satellite and IPTV).

With some collusion it would be quite easy to have the big media target a smallish ISP (teksavvy being one of the biggest small players) to test the waters, set some legal precedants and see how the market reacts.

From what I remember reading ADS-B is also going to be used where there is no RADAR coverage, over the oceans etc.

It will also be used to communicate to other aircrafts the position of an aircraft, this could be another major source of problems with spoofing communications.