Software Circus

Posted on 2015-12-19

Free conferences don't come along very often, and when Software Circus was announced, the 200 spots filled up in less than a day. I had never been to a conference before. Yes, a Google Cloud Platform event, and an AWS event, but those felt more like showcases than conferences. On the day of Software Circus it finally dawned on me that, in addition to the chance to expand your professional network and to learn new things, conferences can just be a fun experience. Fun was a nice side-effect, while two speakers gave presentations that really resonated with me.

Simon Brown gave a presentation on software architecture and emphasized the visualization of it. Later on Marta Marszal talked about similarities between visuals used by traditional brick-and-mortar architects and software engineers. After the second talk something clicked. I realized the importance of the sketches we developers tend to make. The ones to help ourselves understand something. If they're useful to us, they're useful to others. Visual communication is very strong medium and it's been sorely underused in software. At least in projects I've worked on. Developers gladly consume visuals when available. Just like documetation, a software project's chances of success are greatly increased when it has strong visuals. Including, but not limited to: a mascot, a pretty website, and a nice logo. However, just like writing documentation, drawing diagrams is an afterthought (if anything) and often skipped or done poorly. Well, we can generate diagrams, but aren't auto-generated diagrams ugly? Doesn't a human need to decide what level of detail is required, what layout and color coding to use? Can all those things be covered by tooling? Personally, I'm not convinced.

What if we wanted to make diagrams and other visuals the driver of our software development. Putting it first. Front and center. Diagram Driven Development. There, I coined something. I'm sure a lot of people already operate this way. Sketching out some vague concepts of components before writing code seems like a natural thing to do. There is added value to having diagrams that accurately describe the code and looking at them frequently. They can give you insights into illogical dependencies, bottlenecks, etc. They can help new team members understand and better remember the concepts you're working with. So, we realize they're important, we use them, but it's time to take it up a notch.

In my heart of hearts I think a computer's creativity will never match a human's. Or at least not while this blog is online and someone can hold me accountable for that statement. Some of the strongest images used to communicate something work because of something deeper than the obvious images. They work because of context. Historical, cultural and personal context. They communicate indirectly through abstractions. Something I'm convinced requires a chaotic and irrational brain to create. Having tools to show us our code in another form is great, but I'd prefer to have the resident creative type be involved with visualizing the software system I'm working on. Just a team member, able to listen to and bounce ideas back about architecture, structure, and beauty. Yes, because code can be beautiful. I've experienced it, I've felt it. Now I want to see it.