Liberal vs Conservative Software Engineering… another epic rant from ☛ Steve Yegge

Steve has posted another epic rant on Google+ about the Software Engineerings own political axis. My favorite part it the characterization of the Conservative View as Fred from Scooby-Doo and the Liberal View as Shaggy. The views are highlighted below

Conservative View

  1. Software should aim to be bug free before it launches.
  2. Programmers should be protected from errors.
  3. Programmers have difficulty learning new syntax.
  4. Production code must be safety-checked by a compiler.
  5. Data stores must adhere to a well-defined, published schema.
  6. Public interfaces should be rigorously modeled.
  7. Production systems should never have dangerous or risky back-doors.
  8. If there is ANY doubt as to the safety of a component, it cannot be allowed in production
  9. Fast is better than slow.

    Liberal View:

    1.  Bugs are not a big deal. 
    2. Programmers are only newbies for a little while.
    3. Programmers figure stuff out amazingly fast when their jobs depend on it.
    4. Succinctness is power.
    5. Rigid schemas limit flexibility and slow down development.
    6. Public interfaces should above all else be simple, backward-compatible, and future-compatible.
    7. System flexibility can mean the difference between you getting the customer (or contract) vs. your competitor nabbing it instead.
    8. Companies should take risks, embrace progress, and fiercely resist ossification
    9. Premature optimization is the root of all evil.

      Excerpted from "Notes from the Mystery Machine Bus" by Steve Yegge

      Rob Pike - "...one small shortcut about 40 years ago..."

      I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake.

      How many bugs and wasted CPU cycles and instances of human frustration (not to mention bad design) have resulted from that one small shortcut about 40 years ago?

      Keep that in mind next time you want to cut a corner in your code.

      via plus.google.com

      As well considered Unix always seemed to be, the notion that hidden files were an unintended consequence of a "quick hack" is amusing...

      Michael Feathers Talks Legacy Code on .Net Rocks - great #quotes

      via .NET Rocks!

      • "My point of view is that legacy code is just code without tests."
      • "What's important is to try to imagine something that is just a bit better than what you have currently. If you can target those things, then over time you will really start to make a difference in the code base."
      • [in order to reduce fear of a legacy codebase perform a scratch refactoring...] "Check out the code with no intent of checking it back in. Refactor different sections... enough to get a feel for the code base, to get a handle on it..."
      • "Functional languages get us away from some of the issues that have become so problematic in testing... Functional programming reduces the number of side effects of code..."
      • "C# is getting too big. Every time you turn around there's been something added to the language. I'd hate to see it end up like C++."
      • [regarding the new raft of languages] It's a bit like the tower of babel. For so long we had a mono culture in the industry around java and visual basic. Now it's at the point where everyone and their brother is designing a new language."
      • [Regarding OO languages hitting a wall] "I think there is something to that, but I also think it has to do more with the type systems."
      • "There are two basic themes of type safety... Type inference and Laziness, create data structures and apply limitations after the fact. I recommend that people learn Haskell. It really throws your mind in strange directions."
      • [Regarding OO programs becoming legacy...] "It seems to be the fate of everything... Progress happens."
      • "The history of the next 30 years will be about mining the last 30 years"
      • "The thing about learning Haskel... it's great... You just need to learn to think like a martian!"
      • "When you're choosing the right tests for something you have to think about it very deeply. you have to understand exactly how it operates... as you go through that process you'll arrive at higher quality without necessarily putting the bugs in there in the first place. So TDD and unit testing in general gives us quality, not through just test failures, but by forcing us to think through our code deeper than we would otherwise."
      • [Regarding Agile] "The only thing that gets me is that there seems to be a moratorium on design in the industry over the past 10 years. There was a time when peopled talked about the intricacies of object oriented design... Once you go ahead and say 'Design is going to emerge' people say 'oh well then, we don't have to talk about that'"
      • [Regarding the question: has architecture been forgotten"] "I think to a degree... there are some not nice things that have happened with the nominal title of architect over the past 20 years. But architecture expertise is definitely necessary in many application domains but they have to have a real view into the code."
      • "Architecture knowledge has to be in the team... It's a very communicative role."
      • "The import thing is continuity of knowledge in the team... When you have that, everything works out well... When you don't, everything is a fishing expedition when you need to make changes.
      • "Documentation is important but you don't want to get into the situation where everything is exquisitely detailed and has to be changed every time you change the code. It gets crazy."
      • "If you see code that is crazy and odd and you understand Conway's law, it really says something about the team that produced it. If you need to produce code in a team effort, than that team needs to get along together in order to produce good code. Otherwise, they are just sabotaging each other... even if only subtly."
      • Emergent design can work very well, but in large organizations with a large codebase you have teams that do a little work on some code and move on, a little work on other code and move on. With agile, the original goal was to have collective code ownership. In large organizations there is no ownership so you have an odd tragedy of the commons. In large organizations, there needs to be a notion of ownership and if you don't, you shouldn't be surprised with what you get."

       

      "A test is not a unit test if..." - Michael Feathers

      A test is not a unit test if:

      • It talks to the database
      • It communicates across the network
      • It touches the file system
      • It can't run at the same time as any of your other unit tests
      • You have to do special things to your environment (such as editing config files) to run it.

      Tests that do these things aren't bad. Often they are worth writing, and they can be written in a unit test harness. However, it is important to be able to separate them from true unit tests so that we can keep a set of tests that we can run fast whenever we make our changes.