[TUHS] Maintainability, Guilds, RMS, etc. all lumped into one

Well, here I go trying to be the voice of reason. Not my natural state :-) Can't see any good coming out of RMS bashing. I'm one of those who thinks that GNU/Linux is absurd; RMS had nothing to do with Linux. I can imagine that, like many of our peers, he has ego issues may feel slighted that Linus gets more media attention than he does. Maybe he would be happy if anything built with GNU tools would append a tag line equivalent to the bandwidth- wasting "sent from my iPhone" stuff on emails. All that aside, he has had a huge and positive influence with the GPL and by making many of the tools that we all depend on available for free. I remember that when I switched from SunOS to Solaris that Sun started charging for the C compiler and I was very happy to have gcc available. I would claim that the issues of maintainability, guilds or other standards for programmers, etc. is really a management issue. And it's exacerbated by what I have observed about management which is that it's not about managing any more. Since managers are theoretically responsible for programmers sensible things don't happen when the managers are not competent. Nothing says it more than the Chief Security Officer at Equifax being a music major with no relevant skills. What could possibly go wrong? Managers don't care about maintainability today, and I'm not sure that it would matter if they did. When I started working there was an expectation that one would look after one's employer's interests and the employer would look after yours. That's pretty much gone for a number of reasons. Few programmers are going to worry about maintainability when they expect to change jobs frequently. As an aside, one of the reasons why I chose to work for myself is that I got spoiled by having awesome management on my first job. I remember Hank Macdonald who I think was co-director of whatever branch of area 10 in which I was working at BTL pulling up a chair next to me at 3AM one late night/early morning and asking me how it was going. I told him great except for some problems with display flicker at which I was staring. He thought about it for about 30 seconds and said "I'll bet your delay constants are too big." He was right. I realized that he was a director because he had mastered everything that everyone under him was doing, not because he couldn't. All other managers that I've had since were Peter Principled. Oh, and under Hank I had Joe Condon as a supervisor which was another amazing experience. When I went to work at Tektronix I had an expectation that I'd spend my entire career there. Of course, shortly after I started the technical founder was replaced by an uneducated bean counter who looted the company. But, I remember a day when someone who sat near me celebrated ER (engineering release), which meant that his product went to manufacturing. A day or two later someone from manufacturing was sitting in the chair by his desk asking questions. This happened for a week or so and then that engineer's desk got moved down into manufacturing. I observed this and told myself that I would never let that happen to me. Another thing from Tek was that we supported products for ten years after ship. That made maintainability and reliability important. When someone makes a web page component that's going to be around for a few months at best it's hard to justify spending dollars on maintainability. Final thing on this thread: get used to it. As with any field, programming is a commodity item now. It's not a field populated primarily by people with PhDs. Think about the number of baristas who were hired as programmers during the .com boom. And the "everybody must learn to code in high school" movement is not about making more programmers like the ones on this list. It's about calling people programmers who don't even have the prerequisite skill of knowing how to coffee drinks. It's still a management problem because these people are being hired to do jobs for which they really don't have the skill. It's part of the hollowing out of America; we still have great sounding names for a lot of things that no longer really exist. Fortunately for people like me, companies often get in serious trouble and need someone who knows about bits and cycles and interrupts and propagation delay and so on. Good for the toy budget. I'll illustrate this with an emergency job that I did a few years ago. I was hired to get something working with a hard 3 week deadline where the person who had done the original work claimed that everything worked but it only worked for him; nobody else could get it to work. One of the things that I noticed was that the absolute maximum electrical values on one of the parts was being exceeded. Mentioned it to the CTO who looked at it and told me that she had looked at the circuit diagrams of the chips and wasn't worried. I responded with "I guess you've never worked at a company where you were responsible for warranty repairs." Turns out that she hadn't. On the software side, I replaced around 8,000 lines of undocumented code with about 300 lines including comments and whitespace that did the job. Probably less than 100 lines of actual code. I see this over and over with the "we'll just import packages and make library calls and call it programming" mentality. BTW, it's not just software. On this same project there was a problem internal to the Atmel SOC. Turns out that Atmel had just purchased a bunch of IP and glued it together on the chip and even they didn't know the particular detail that I needed. Took several months of escalation to finally get it resolved. Jon