Compound Thinking

Ann Arbor ArbCamp Registration open again

I’ve been very, very busy trying to get TurboGears 2 beta 1 ready to go, as well as a few other interesting projects, and had neglected to blog about a ArbCamp before, then it was sold-out, and I didn’t blog about it because I didn’t want to raise people’s hopes only to have then dashed upon the rocks. But, we’ve secured a new venue, so ArbCamp registration is now Un-Sold-Out. It’s UnSold because it’s free, and it’s un-Sold-Out because we can now fit everybody in. We had over 160 people registered and on the wait-list, but could only let 100 people in. Now we have space for 200, so those on the wait-list and those who didn’t sign up in time have a second chance.

ArbCamp will be tomorrow night, in the upstairs of the downtown Cottage Inn’s, so this is kind of last minute, but I think it’ll be a very cool event. It’s an UnConference, and people will be self-organizing a variety of sessions, and the possibilities are endless.

Just say no to “software engineering”

I was reading Jacob Kaplan-Moss’s blog article on “syntactic sugar” and I realized that there’s something sitting just below the surface of what he’s saying, something important, something counter to the standard “software development is an engineering discipline” view of our work.

Jacob rails against those who say the differences between modern computer languages amount to nothing more than “syntactic sugar.” Ultimately he argues that: Syntactic sugar matters.

Sure it makes no “technical” difference but it does make a huge difference — because it changes the way we think about writing software.

I’ll loop back to that in a second, but first a quick detour through another recent blog post:

Eventually you come to realize that in order to truly succeed, you have to write programs that can be understood by both the computer and your fellow programmers.

Of all the cruel tricks in software engineering, this has to be the cruelest…. Even when you’re writing code explicitly intended for the machine, you’re still writing. For other people. Fallible, flawed, distracted human beings just like you. And that’s the truly difficult part.

–Jeff Attwod

The thread that ties both of these together is that they highlight the way that people and by people I mean software developers, tend to forget is that code is always two things:

• A series of instructions or declarations processed by a computer.
• A series of instructions or declarations processed by one or more human beings.

Code is a machine construct, but it’s also a social construct. Software engineering is a strange name for our discipline, since the hard work of programming isn’t just getting code that machines can run, but in creating abstractions that allow human beings to learn, understand, and evolve the code over time. We didn’t invent Structured Programming, or Object Oriented Programming because they help the computer understand what we mean — we created them because they provide us with tools to help us as human beings to be able to understand the code we write.

Non-software Engineers aren’t concerned primarily with the practice of communicating complex thoughts and ideas to others. This is a vast oversimplification, but I think it’s fair to say that they are interested in constructing mathematical models of how things things behave, so that they can build stuff that works.

But that’s not what we are, we are creative writers, we invent new ways of thinking about the world, and we try to communicate them to each other every day.

Software Engineers do create incredibly complex systems, and operate under constraints that other writers do not — what we write has two audiences, one human, and one non-human. Writing for the non-human audience alone will result in code that’s incomprehensible to other programmers, but the opposite is also true. Computer programming is hard — and it’s hard for a very specific reason — because it requires thinking like other people, and not thinking like people at all.

Fortunately, the problem is simplified a bit by the fact that other programmers have learned at least somewhat to think like silicon and metal, so you can lean a little bit in that direction and still be understood. But still you have a very exacting, very alien audience, and a very exacting, very human one — and programming languages must be designed to balance the needs of both.

So, perhaps we ought to stop calling ourselves software developers, software architects, or software engineers, and start calling ourselves software writers.

Consulting Experiment

Compound Thinking is a Python Web development shop, and I’ve been spending some time recently thinking about how I can help our development team grow. One thing several people have expressed is a desire to work on some projects using newer stuff, like Pinax, or tg.ext.geo, we’ve also been doing quite a bit of dojo and some flex work, and would like to do more. And I know all of us are very interested in doing more Open Source work.

Compound Thinking has been able to provide affordable development prices by using a variety of high-talent developers in the US and around the world. And, I’d like to see if we can push forward some open source projects, while making our services even more affordable for customers who help us help the world.

So, here’s my proposed experiment:коли под наем

• We will provide significant discounts for people with projects using the stuff the team wants to work on.
• We will split the costs of any development work which is released under an OSI approved license, including parts of any project we do that can be refactored out into a reusable component.

In particular we want to:

• we’ve got a lot of GIS/geo experience, and have done a lot of framework work in TurboGears to improve that story, but we need a larger TG+geo project that can showcase all this cool stuff.
• After DjangoCon, I’m very interested in Pinax, and what all those reusable components bring to the table for Django, and so several of us are surprisingly eager to work on social networking style projects to explore that in more depth.
• I’m interested in pushing TurboGears integration with javascript frameworks and dojo in particular, so heavily javascript oriented applications
• I’m also interested in improving the e-commerce story for TurboGears and would love to open source some related tools. We’ve done this stuff a few times, and I’d love to do it one more time under an open source license so we can help future generations not to have to reinvent this particular wheel.

Beyond that, feel free to pitch us a project that has some open source components that we can release, and we’ll see if we can work up a deal to split the costs on those components.

If you’re interested in any of these ideas e-mail me (mark@compoundthinking.com) let me know. And more importantly if you’ve tried any of these things and had good or bad experiences drop a comment here, because I’m very interested in figuring out how other consultancies expand their technical repertoire and push forward the free software agenda.

REST is a design for the long run

Found this quote in a recent discussion or REST.

REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency.

The one technology every developer should learn!

I recently wrote a little article for an O’reilly project, in which I argue that the single most important technology that Software Architects need to master is not at all new. And I don’t just mean that Fred Brooks already told us about it in the 70′s. It’s older than that, much older.

Software Architects and all Developers ultimately will succeed or fail based on their knowledge of one of the same technologies the architects of the pyramids used to get their jobs done — the conversation.

When something goes wrong, or when somebody just isn’t getting it, mastery of this simple technology makes a huge difference. A well placed, well handled conversation can change the course of a failing project, or transform something good enough into something great.

Sure conversation can’t solve every problem, but it’s a key enabler for every other solution, since it is the very thing that allows for exploring possible solutions as a group.

We all learned the basics of conversational technology as kids. But often that’s not enough, and we still have conversations that go horribly wrong. Fortunately conversation is not a stagnant technology, and we can learn more as adults.

I’ve read more books about “how to talk to people” than the average software guy, and I’m endlessly fascinated by the subject. I’ve recently been getting into the neuroscience side of the subject, and am endlessly fascinated by the complexities of brains.

But, if I had to recomend just one book for developers and architects to read to improve their “people skills,” it would be Crucial Conversations. It cuts through the complexity to offer a lot of really simple suggestions that actually work. There’s good science behind what’s suggested (even though it’s not always spelled out in scientific terms.

I know that I really need to write more about why this book is so good. But for now, let me say that it does a better job of outlining in a simple and easy to understand way exactly the tools that are needed to keep both parties in a conversation thinking. It’s easy to ignore the impact of fear and anger on our conversations, but to do so is to ignore the way our brains actually work.

Crucial Conversaitons outlines the steps necessary to create a safe place to think, and to actually turn that thinking into mutual decisions, and ultimately into actions that solve some of the most intractable problems in our projects. It certainly helped me.

If you’re just struggling to be understood this may not be the best book for you — because it does little to help people structure their thoughts in ways that others can understand. But if you’re struggling to break through on tough conversations, and have important issues where you or the other person are frustrated, defensive, and have been avoiding talking about emotionally charged subjects — this is the book for you.

I know it helped me to have productive conversations about difficult issues at work, and at home.