The concurrent development issues were well known before those programs were even started; it was a risk the government was willing to take. There have been discussions about it in the professional program/project management community for years and was a hot topic when the DoD decided to undertake DDX, CVN, and the F-35. Concurrent development increases the parallel dependancies, thus it's name is 100% self explanatory, but promises to deliver a more up to date system when acquisition takes many years. Blaming everything on waterfall is kinda ignorant. It's just a tool in the tool box, like a hammer. It's the appropriate tool for many jobs, but not all. I've seen agile programs succeed and fail. I've seen waterfall succeed and fail. I've seen hybrids and all sorts of "modern developer methods" succeed and fail. The success or failure hinges on choosing the correct program management method/tool for the appropriate tasks. Too many people learn one method, or just have a preference for it, and everything starts looking like a nail.The F-35 HMD Helmet is a f'n mess right now. Especially considering each one is custom made for each pilot's head. But the truth of it's delay is mostly because like most gov't contracts, they are Waterfall in nature. As a result there are a ton of unknowns especially with parallel systems. This is the opposite of modern developer world where systems are largely self contained, small, well defined manageable targets with interfaces and dependency injection. It's these unknowns that are discovered later that bite you in the tail.
You'd think they'd mention it if the "secret material" was just graphene.The problem with silicon based batteries is the crystals would crack (silicon has a tendency to do this as it is hard but rigid) as they release energy. Once cracked they don't hold a charge as well.
They made a discovery years ago that combining silicon with carbon nano tubes solved this problem. But getting them to bind the carbon nano tubes on a large scale was difficult.
But in general theory by decreasing the size of the crystals lattice and binding it to a flexible semi conductor compound like carbon nano tubes you can bypass these issues.
Makes me wonder if they found a way to bind it to a graphene compound?
Get 30x 18650 batteries hook these in to 3 sticks in series (12 volts) and run 10 of these sticks in parallel. You will have between 18 amp hours and 50 amp hours your current sealed lead acid battery is only 5 amp hours. With 5k mah cells your talking 15 hours vs 15 minutes (real world expect about 8 to 10) I putting together a solar panel based system sim to a battery back up and in early tests using a 12 volt supply to charge the batteries i have gotten my laptop to run off it for around 5 hours before the ac dc inverted shuts off. This was with a 12 volt 1 amp supply charging it for about 12 hours. They have some charge when shipped 40% if i recall. So 12 amps on top of around 25 amp giving me 37 amps. or about 7 times a fully charged sealed lead acid battery. On a reg unplugged backup the same laptop gets about 1 hour. So it is giving close enough to what it should in theory to be with in a standard error rate. Out side factors or my power supply used to charge it may not be putting out a full amp.
Buying 18650 cells in bulk to bulk the battery pack will cost you just under 1 dollar per cell. So it is very cheap. You could harvest them from old laptop batteries as well how ever from one battery to another you will have lower or higher mah capacities and ware and tare on them etc.
That's the downside to capitalism: Some of the best tech out their dies because no one wants to invest in the production due to the initial high costs.
The concurrent development issues were well known before those programs were even started; it was a risk the government was willing to take. There have been discussions about it in the professional program/project management community for years and was a hot topic when the DoD decided to undertake DDX, CVN, and the F-35. Concurrent development increases the parallel dependancies, thus it's name is 100% self explanatory, but promises to deliver a more up to date system when acquisition takes many years. Blaming everything on waterfall is kinda ignorant. It's just a tool in the tool box, like a hammer. It's the appropriate tool for many jobs, but not all. I've seen agile programs succeed and fail. I've seen waterfall succeed and fail. I've seen hybrids and all sorts of "modern developer methods" succeed and fail. The success or failure hinges on choosing the correct program management method/tool for the appropriate tasks. Too many people learn one method, or just have a preference for it, and everything starts looking like a nail.
The underlined portion is really Systems Engineering 101...something which most people who call themselves "SEs" really are not and far too much is given towards program/project management vs. the technical analysis side of that job. Real, classic SEs are a rare breed and don't come cheap. Specifically, making sure the right thing is being designed and built, which requires doing that underlined bit really well. Real SE is program management method agnostic. It's a way of thinking and analyzing a system, which is different than classic reductionist engineering domain specific methods, such that "systems are largely self contained, small, well defined manageable targets with interfaces and dependency injection." Some program/project management methods have attempted to weave those SE ideas into the fabric of their process, but that's not a guarantee of success. Mature software engineering shops are the closest, but that largely has to do with the need to manage complexity (what SEs are primarily focused on, that is to say interactions between components) vs. managed design complications (domain engineering).
Just some thoughts. Gotta get some stuff done today.
No not new technology! It burns the troglodytes eyes!
Honestly I wish I remember the idiots who constantly shit on emerging battery tech because it wasn't were the previous technology was.
(EVERYONE EXPECTED IT TO BE BEHIND AT THE START FFS YOU ARE NOT SMART FOR REMINDING US OF NOTHING CONSEQUENTIAL) - Rant to all those ppl.
Seriously?!? "Initial high cost" - such a breakthrough would be worth billions. Initial high costs would hardly be of any consequence if the tech was even remotely viable. Capitalism would be the ultimate driver to ensure such tech saw the light of day. Think of the long term profits!
Capitalism has pushed more advancement in the entirety of human history than any other socio-economic system. Income inequality? HA! Go back 300 years and go interview anyone in Europe.
Ugh. Instead of anti-capitalistic propaganda how about reading up on some actual history, eh?
That made me laugh. But when it comes to advanced technology the best the Chinese can do is copy what's already there.
Even their space program and aircraft carriers are built on well outdated tech. Their stealth fighter knock off they STOLE from us is vastly inferior.
They are industrious and decent at mid tech knock offs, but they are not a science based engineering power house.
Statistically speaking waterfall on average has 60% failure to deliver on time rate. The average overshoot is like 55%. It is by far the worst development methodology and should be used sparingly in large concurrent parallel development. I understand there are a lot of unknowns, but it is these unknowns that bite people in the tail. If you choose waterfall then you are knowingly creating a risk for delivery.
And your argument about System Engineers is a weak one. With domain systems so large it is IMPOSSIBLE for any one man to lead with the technical knowledge necessary to solve every task and be architect of it. It's Teams of people. Now I'm not negating the need for System Architects and Engineers. They are very much needed and NOT negated by reductionist engineering development modules. But a System Architect is like a 5 star general. And he has a team of generals he knows well and their abilities and divides out work accordingly. System architects do more research and delegation of authority. If a System Architect thinks he has all the answers, he should learn humility and learn from those he works with. A System Engineer and Architect however gets to make the final call. That is his responsibility. And if he fails to deliver, then that is on him and product owners for failing to estimate proper deadlines.
In fact, I wrote an article on this very same thing: Knowing roles and responsibilities when forming large project teams on linked in. My next article is on waterfall pitfalls, and balancing ready for development versus quick delivery.
I'm not sure what you're on about again. If it's SE, it's suppose to be implementation agnostic, and yes, the idea is to manage and mitigate the risks associated with dependancies, interfaces, and relationships (among other things). If you got confused about my software comment, that's likely because you don't understand the history or fundamentals of the various model-based approaches used for the space race (e.g. Apollo flight code; which I must add was way ahead of it's time) and RDS-1000. Or the documentation centric quagmire. Or the resurgence of MBSE, etc. I'm sorry if you misunderstood that as making any comment about your domain expertise or lack there of in software or hardware. None of it was about you or me in any way.BTW: Modern architectures should not care what your code pieces are (low coupling) if you properly implement contracts and use dependency injection. And I'm not just a software engineer. I'm a hardware engineer as well.