describe Preferences, "what I'd rather have" do  it "should be a bottle in front of me" do  end   it "should not be a frontal lobotomy" do  end end

Software engineering doesn't work! As it is typically taught. It doesn't reliably produce good software, save money, etc. However, engineering could be defined as, "the set of processes, etc, that work."

The people who define the terms understand neither software nor engineering.

Caricature of engineering. Conference in Germany in 1969 defined the term. The tone was an acknowledgement of just how little they knew. What they agreed on:
1. Test first?
2. Prototyping 3. Mocking, iteration, prototyping.

A year later, things changed. Waterfall was introduced by a paper in 1970. He is clear that waterfall doesn't work, but the paper was so bad that it appeared to say the opposite. The diagrams quickly go haywire. For every complex problem there is a solution that is simple, near, and wrong.

People had a caricature of engineering in their minds and tried to get software to fit.

There is a bias to the Defined Process Model. It's one end of a continuum, defined by so e chemical engineers. Everything is defined, known up front. David Parnas understood the impossibility of this, but was still attached to it as an ideal.

Barry Beam's study: cost of change. It had a hidden bias. All the projects were waterfall projects. He was actually measuring the cost of fixing errors as a function of the time since you made the mistake. It was a long feedback loop.

Modeling and "math envy." "In engineering people design through documents." Notations, zed, uml, omt, etc. Misconceptions today: what is real engineering? It's a creative activity full of iteration, mistakes, etc. Different engineering disciplines are different in many ways.

Empirical process control model, perfect for processes that are less predictable or stable.

Cost is always an object. Quotation: engineering is the art of doing with $1 what a bungler can do in $2.
1. Advances usually come from practitioners rather than academia.
Malliard in Switzerland. Graceful design, maligned because he couldn't prove it worked mathematically. Testing, models, experience. He had a good intuitive knowledge of statics. Only one of his bridges fell, due to an avalanche. Moissef developed mathematical model of bridges. More accurate. All models are approximations, and over engineering is required for less accurate models. Deflection theory. Tacoma Narrows bridge.
2. Software is not the only field that has it wrong about engineering.
3. Modeling is a cost saving measure, not the goal. You can do less testing. Video of 777 wing test. Tested the breaking point of the wings, and it proved their model correct.

Structural engineering, a science and an art. Designing and making (no ivory towers). Economy and elegance.

Real software engineering is similar: systems that readily adapt to the situations. Software is soft. Software engineering will be different from other engineering. This was known from the start.

Jack Reeves, in 1992, wrote about what software design really is. Too many analogies with structural engineering. We don't know what a software design should look like. Maybe the programmers are the engineers. Maybe the source code is the design. Maybe the tools, builds, etc are the laborers. Maybe the running software is the product. Where is the model? It's in the code. What's the costliest step? Everything the programmers do. Modeling and proofs aren't cost savers. We don't need math envy, we have math. Engineers design with documents.. Our code is a document. Our tests are documents. But not merely documents.. They are executable.

Vanderburg.org/Writing/xpannealed.pdf - agile processes are not ad hoc. They address all kinds of issues, and it's as empirical as it gets.

No longer true:
Code is hard to read, testing expensive.
Never true:
Programming like structural engineering, etc

Empirical processes are rational processes for software.

If we want to grow up, learn from practitioners, biasmtoward empirical processes, #hoedown2010

Specifically, "infrastructure as a service" (there are a lot of kinds of clouds)

People tend to think that cloud infrastructures come with sysadmins.
Infrastructure is hard. Control, provisioning, release, sources, monitoring, model. KaChing is crazy automated. They do 50 builds a day (continuous deployment). But this is a *lot* of work.

Cloudy Provisioning
Provisioning: ask for instances, get lamp stack (e.g.). All start off identical.
Configuration: turn those systems into their desired roles. Images, auto install. Systems integration: hook all the systems together. The last mile.

Chef: role-based config. Treat your infrastructure the same way you treat your code, eg reusable modules.

Why should we care about devops? It's an easy way to run your business better. Devops is not a tool, it's a cultural movement.

Even in agile projects, ops was waterfall. Better to treat infrastructure as code.

A tornado hits your data center, and you can deal with it.

Your prime constraint should be the time it takes to restore your applications.

Chef
A library for config management.
Chef Client runs on your systems. They talk to Servers. Each configured system is a Node. Attributes are searchable. Roles describe what a Node should be. Roles have Run Lists: what Roles or Recipes to apply in order. Roles are searchable. Chef manages Resources on Nodes. Resources (Ruby classes) have Parameters and Actions. Recipes are lists of Resources. Data Bags store arbitrary data. Separates config data from config logic. Eg user Data Bags: vimrc, ssh keys, can deploy user accounts easily. Cookbooks are collections of recipes. Infrastructure as code -> check it into VCS, refactor infrastructure code. Shef is Chef in Irb. Cookbooks are shareable (this has hit a nerve with sysadmins). Chef is idempotent. It doesn't change anything that hasn't changed. Won't reinstall stuff that's already installed. Will only change the things that have changed.

Lots of adoption. Open training, creative commons, attribution share alike. It's all geared toward adoption.

Knife
Implementation of the API. Example: add cloud credentials to knife config. Create 4 identical servers on 4 different cloud providers. Interchangeable providers! Opscode platform
Hosted, multi-tenant chef server. Free for 5 nodes. $50 for 20. #hoedown2010

It's a beautiful morning.

Why am I here? I'm interested in becoming a better rubyist. Good that people are talking about mastery.

Deliberate practice
Set a goal, specific, outside current abilities
Try it, and fail
Ask for feedback. This step is key. Professional athletes still have coaches. Need external feedback.
Keep going. Also really important.

It isn't easy. It's grueling. You have to really want to improve. Lots of failure. It isn't useful (you can't produce something useful when you practice). Coding competition isn't practice. It's a performance. How vs that: procedural knowledge vs factual knowledge. 10000 hours for mastery. (guideline) Mastery is reaching your greatest potential, which is higher than you think. 10000 hours implies focus.

What's mastery good for? Very few things require mastery.

Mediocrity is the baseline. Adequacy is better. We're adequate at most things. Win more than lose. Can be in early stages of mastery, or repeat adequacy. (java developers syndrome) improvement just from doing something over and over again.
Excellence requires intention. Requires being on the path to mastery. You can stop here. Companies
Things viget doesn't do:
Print design
CMS implementation
Email marketing
.net
Hosting
Accounting
Legal stuff

Core competencies: do what is most important for your company to make money. Viget specializes in communication between departments. Eg coders and designers. Software
Platform (don't build a computer, microcode, os, etc). Take grunt work away from us. Framework, rails, etc. Work we don't have to do. Cloud hosting, error catcher. Auth, markup, image processing.. 48 hour coding competition forces constraint, requires even more focus on core competencies.

You and me
78.2 year life expectancy in US. Can't do deliberate practice all day. Starting at 8. We only have 76k hours available. 7 domains of mastery. But mastery is not a destination. You have to maintain. So 5 domains?

What does it mean?
Batman with a green lantern. He doesn't like it. He sticks to his basics. We are defined by our choices. Live intentionally. It's better to use your time on purpose. Decide where you want to go.

Embrace adequacy. Something less than mastery. Understand that instant gratification doesn't work. #hoedown2010

Dreyfus model of skill acquisition:
1. Novice
Know nothing other than what you've been told
2. Advanced beginner
Notice differences, don't have discernment
3. Competence
Multitasking, handle info. See how actions are related to goals. Notice patterns.
4. Proficiency
Higher level view, prioritize, adapt
5. Expert
Past relying on rules. Deep tacit understanding.

Good and bad: lots of skills, and interrelated. Expertise in one area doesn't imply expertise in others. Experts may not be able to communicate what they're doing.

Mindfulness - really paying attention to more than the moment you're in. Being aware of the people who come after.

Another model:
Four stages of competence: consciousness and competence (combine). Don't know you don't know, etc. Unconscious competence - reaching expert level. It's second nature. Tacit vs explicit knowledge. Tacit knowledge is the iceberg underwater.

The expert has forgotten what it's like to be a novice. Pairing helps. The partner can ask questions as needed.

Unconscious incompetence is bad. Dunning Krueger effect. Don't appreciate what the skills are. They are too confident. Inverse is true.

If can't spot the sucker, it's you. Could be you even if you think you know. John Cleese video on creativity.

What do you do when you're consciously incompetent? Have side projects. Don't play around in your main work. Find the things you're bad at and work on them. Since we're thought workers, we need to do physical things (like learn to dance). Learn that there is a gulf between thought and deed. Just because I know something doesn't mean I can do it. Kata. Practice so you don't have to think about it. Cooperative, at the skill level of the lesser practioner (aikido). Experts also benefit from going through the basics. Pairing.

Protect: learn fundamentals, techniques, accepting, staying in the rules. It takes time.
Detach, digress: start thinking for yourself.
Transcendence: it is now second nature.

Beginner's mind. In the beginner's mind there are many possibilities. In an expert's there are few.

Next part of rant:
The new hotness (please make it stop). Just because something is old doesn't mean it's bad. Changing tools all the time. #hoedown2010