16 ms·

I was a DoD contractor (the coding type, not the shooting type) for almost 15 years, and this is a really interesting read. I've heard some software devs state

• jdeaton 4y ago
  Just out of curiosity, how does someone with in-demand, highly-transferable skills like software development find themselves working in a place they generally dislike for 15 years without leaving sooner?
  • gilbetron 4y ago
    Oh, I had an awesome time for much of it. Small business with many great friends and we got into many antics over those years through thick and thin. Also, I got to do really cool, nearly constant greenfield work, like flight simulators, robot simulators, radar simulations, robotics, haptics, and then there was some non-DoD work like a virtual gorilla VR experience, gaming stuff, and all kinds of funs times and trips to Game Dev and E3 conferences. I once got to fly on a mid-air refueling mission. Got to see one of the Mars rovers as it was being built. Went on a Naval frigate. Ran a class for some pilot trainees in a building next to the Blue Angels home base. But there was lots of boring bullshit in there too ;)
• johndhi 4y ago
  I haven't read the doc, but I worked on lawsuits (I'm a lawyer) that at their core were asserting that agile software development isn't as safe or bug proof as waterfall. Basically in the medical device (or adjacent) space the idea asserted was that 'fail fast' was illegal and didn't have enough safety checks. Agile software development is a tough pill to swallow for non-engineers. The lawyers and business people can't wrap their head around the idea that building iteratively could actually reduce bugs and improve quality - because the way they work is via process planning docs and checklists.
  • arcbyte 4y ago
    The ONLY way to get quality is through quantity. That's the key insight.
    • hamandcheese 4y ago
      Quantity of... dollars?
      • no_wizard 4y ago
        I’m betting releases and iteration cycles they’re tied to. The most agile place I ever worked shipped code most days of the week in some fashion. For control reasons we released Tuesday-Thursday not Mondays or Fridays. So was nearly every day something went out. I’m including bug fixes here but nothing got stalled. We had a working iteration loop of Test -> Develop -> Test -> Review -> QA -> Release Lots of automated checks, investment in infrastructure and good architecture made this possible. Ironically one of the smallest companies I ever worked for
      • xboxnolifes 4y ago
        Iterations.
    • __MatrixMan__ 4y ago
      "Breaks when you try to use it" is a quality that I can usually achieve on the first try. Or did you mean some quality in particular?
• kbenson 4y ago
  > The problem is that you can't take a process and put software drones on it and deliver software of any complexity. That goes against much (but not all!) of the DoD paradigm, it is interesting to see they might be changing. My (outside) impression has changed the more I've heard over the years, to the point that I assume the DoD and military are acutely aware that the drones aren't really interchangeable, and that at every level they cultivate people under them they know "get shit done" and hand the important projects to them. Those people in turn have those under them that "get shit done" they hand the important things to, and so on, all the way down to privates in the military. The important thing being that those people that get shit done are given a lot more leeway in how they accomplish things (which might later become doctrine of successful), and this is specifically how those orgs evolve over time. Again, that's my outside perspective from someone that's interested whenever I hear it and reads/listens to history sources (podcasts,etc).
  • Jtsummers 4y ago
    > to the point that I assume the DoD and military are acutely aware that the drones aren't really interchangeable, and that at every level they cultivate people under them they know "get shit done" and hand the important projects to them. Within military troops, yes. That's an active goal, especially on the officer side where the whole career path is pointed towards increasing levels of responsibility and leadership. The problem is not in the troops, but in the program offices. I was on a spectacularly failed Waterfall (big-W, they were explicit about what they were doing) where they handed the task of managing a large, multi-billion dollar software system (from the DOD side) to a 1st Lt history major. She had no preparation for the role. Software acquisition in DOD is, mostly, a clusterfuck. I felt bad for her because she legitimately did not know anything more than the basic legal and financial side of things, she had no technical comprehension and had to trust people (contractors) who were lying about the system status and quality (what was delivered, after she had moved on, was years late and had a fraction of the target capabilities). Program offices are not generally composed of people who have real-world experience with software development. Remarkably they have great engineers, good finance people, but the software person (often singular, even in programs that are almost exclusively composed of software systems) is usually not from a software background or a straight out of college EE major (more often than not, occasionally a CS major).
• kqr 4y ago
  > I've heard some software devs state that "the waterfall method was never really used". What they mean by that is that the person who invented the phrase "waterfall method" did it specifically to tell the world about something that did not work. In fact, even going back to the NATO software engineering conferences of the 1960s, they were discussing how development needs to be agile. But sure enough, few big organisations got that memo.
  • Jtsummers 4y ago
    DOD codified Royce's waterfall (which he, himself, did not name in that paper) in a set of documents on officially endorsed software acquisitions processes. There were others, but Waterfall was one of them. Its critical failing is that it's an idealized process that cannot withstand uncertainty or change, but it looks really pretty in charts so people selected it without serious thought put into it.
• xxEightyxx 4y ago
  I'm a current DoD contractor (the coding type) and the agile/waterfall mentality still holds up. Different departments and different projects within each department will have different methodologies for planning and delivering products. However, where I am, there is a huge emphasis on "getting shit done" well ahead of schedule. I'm lucky to work with smart and motivated folks who together, work well and we are wildly successful. My biggest gripe, shared among many of my coworkers, is the level of micromanagement. Multiple business analysts, product owners, stakeholders, SCRUM masters, managers, etc. who all share essentially the same job - delegating and scheduling work. It makes every project 10x more difficult and complex than it otherwise should be. An example just from this past week: Project A: we are delivering a single product. Three managers, two SCRUM masters, multiple business analysts. We engineers have four different JIRA/task-boards to keep up with. All of them overlap, three of them are essentially the same board in different spaces. Each day we have 2-4 hours worth of meetings spread across stakeholders amongst those three boards where we regurgitate the exact same information. It's repetitive, backward, and a time-waste. Some engineers are currently "revolting" by saying what I'm saying now - in the meetings themselves. We've had multiple blowups with management. Having meetings and discussions spread so wide leads to a lot of confusion because us engineers appear to be the only conduit with which the analysts and managers are communicating. Often times, the different stakeholders will ask for the same features in different meetings, other times they ask for different or conflicting features which leads to confusion and the need to schedule more meetings to clarify as they are not communicating amongst each other.
  • sirsinsalot 4y ago
    The issue I found in defence, when your software integrates in to a very large engineering project with a mix of hardware and software is that often times waterfall is appropriate because everything has to be decided upfront where possible. For tight hardware integration, iteration on design isn't appropriate because the hardware design was locked in to begin manufacturing. Quite often software life cycles miss the hardware rapid prototyping phase and so there's a desynchronisation of iterative design. Within the framework of the hardware, yes you can iterate on the specific implementation but the contract with the external hardware and the timeliness to deliver was fixed. Agile struggles without agile being applied end-to-end, and so you get agile/waterfall mixes. In my experience, they can still work. In my case we have annually field deployed (and difficult to update) firmware. Firmware feature additions and changes are an up-front known quantity (even if they turn out to be insufficient for the in theater usage). We can't change them. That's the root where any agile approach reaches an external impact limit. Our little bubble is agile in a waterfall world.
• lifeisstillgood 4y ago
  I keep banging on about "software is a new form of literacy". Imagine you have a group of illiterate managers who have just hired a group of writers to write some company policy documents. You could have the managers (carve / draw / modern dance) their requirements in a waterfall manner. Of course you could get one of the managers to sit down with the developers and tell them how the policy's work each day, embed with them Agile style. However in the end you can't be everywhere, sometimes there aren't enough people in the company who understand what is needed, or even be sure that the embedded people agree on what is needed. These are business problems - but they are also literacy problems. We have a literate society and so there are enough literate people to write policy documents to cover a whole compmay. We need to make enough people who can code, so they can write the policy documents of the future.
  • kqr 4y ago
    This is an interesting take. I've always rolled my eyes at the people who say "everyone needs to know programming" but when you put it like this, yeah, why not? The only thing I'm not convinced about is whether programming is something of a functional specialisation or if it will (GAS already?) become a literacy-like thing. I mean, we generally think of numeracy as something widespread in the West for the past few decades, but the average person really does not do even basic arithmetic very well. Are we really going to do a better job of teaching people programming, or will we have to resign to the reality that most people won't learn it well?
    • lifeisstillgood 4y ago
      My take on this is the basics of astronomy. The history of how astronomy slowly worked out the earth goes round the sun, distances etc is fascinating (#) The bit that's gets me is how fast does earth spin (without which sun rise is a bit hard to explain). Until it was accepted that air was just a thin atmospheric layer, it becomes insane to imagine we spin at a 1,000 miles an hour though a air medium that extends to Jupiter. How do you keep your newspaper still. Kids today have Mickey Mouse cartoons explaining space rockets, moon to mars, earth spinning etc. We just accept it as true without trying to be clever about it The same is true for literacy and numeracy - just having a society where you absorb character arcs, sub clauses, chapters, publishing, versions etc makes so much difference. Mathematical symbols were the names of Ed Sheeran albums. Look at something simple like version control - the idea is fairly simple and hot is almost perfect for it, but oh god have you tried to use Sharepoint. Once you are in the WYSIWYG mind set, version control breaks horribly and most most business users should have this all the time but it's not in their world view. Explain it to them and they say "but how does your nreasoaper not flap around in thousand mile hour winds" (#) Look for episode on the podcast "Subject to chnage"
• cpeterso 4y ago
  Related to agile on DoD projects, here’s a presentation from Lockheed Martin about their adoption of SAFe (Scaled Agile Framework) for their F-16 software projects. While agilists consider SAFe to be “waterfall in agile clothing” sold by consultants, Lockheed Martin successfully reduced their cycle time from 3-4 years per program increment (delivered to Flight Test team) to 9 months. They’re delivering smaller increments to QA and iterating on feedback more frequently. https://youtu.be/nvfYLZ52zX0 https://youtu.be/nvfYLZ52zX0
• ChrisMarshallNY 4y ago
  > The problem is that you can't take a process and put software drones on it and deliver software of any complexity. That would be news to most tech companies, these days, that seem to be obsessed with hiring huge armies of inexperienced engineers, relying on the process to make them magically deliver code like they were masters. I worked for a couple of major corporations, and got lots of waterfall. A the Japanese company, I quickly learned never to utter the dark majik phrase "A G I L E," as it conjured demons from managers. Also, looking at that PDF, I realize that it is a slide deck. That presentation must have been a soporific.
  • zozbot234 4y ago
    The Agile manifesto has nothing to do with huge armies of inexperienced code monkeys. On the contrary, it's focused on empowering small, highly competent groups to deliver the most value through quicker feedback loops.
  • ThePowerOfDirge 4y ago
    Agile had the scrummaster role. The authors of the Agile manifesto said that this role was supposed to rotate in the group of coders and eventually be phased out once the group got used to the process. The agile process in its final form has no managers.
    • ThePowerOfDirge 4y ago
      https://m.youtube.com/watch?v=hG4LH6P8Syk https://m.youtube.com/watch?v=hG4LH6P8Syk at 21:10
    • Jtsummers 4y ago
      That's Scrum, not Agile. Scrum is a way to, theoretically, get to or introduce Agile concepts but it is not the entirety of Agile (either the theoretical or practical forms). Also, you can edit your comments which is better than tacking on additional self-replies just a minute or two after.