This topic has been much on my mind as I contemplate how we should be training future software makers (vs. future computer scientists and software engineers). Below are the questions I will be posing to the panelists: I'd love to hear your answers in the comments! I'll incorporate anything I learn in this post into the panel, so if you think of other questions I should ask, please tack them on as well.
- There are many metaphors out there for what we do (crafts person, artisan, engineer, scientist, etc). How do you think of yourself?
- What aspects of making software feel like an art form to you?
- What aspects of making software do not feel like an art form to you?
- When you are designing or writing code, what does it feel like? Is there a performance aspect to your work?
- What is the most valuable training you received that helps you as a designer or coder today?
- What is the most valuable training you've experienced on your own? What's been the best self-teaching experience you've had?
By the way, the Betascape schedule looks really awesome. You should totally plan to come to Baltimore for this, and here's how to buy a ticket!
3 comments:
Good questions. I'll be interested in hearing what they think of themselves.
Do you mean art like a product or artifact, or art like a creative practice? Defining art is not simple, using the word precisely is difficult. What do you mean when you say "art"?
"Is making software a craft and/or art form?" is a subjective question and can only be answered subjectively. People’s response to “is software design X” reflects their motivations, not a truth that can be applied to another’s experience.
I think it's craft-like in its repetitive practice and in the quality of the product strongly reflecting the skill of the creator. I think it's not art-like, even though software making can be pursued for artistic purposes.
(I posted about this on my blog)
Great question... to me as a longtime software engineer/architect, it's both. We're building stuff that, while we can't see and touch it, has tangible analogies to the real world. Bridge-building requires both art (the design and presentation of the bridge) and engineering (stress and load analyses; see Tacoma Narrows as an example).
Personally, to answer your question, I feel more like an engineer when building software, with art and creativity liberally sprinkled throughout the process. At its core, producing working, reliable software is an engineering discipline. Anyone who does not treat it as such is in for a lot of surprises.
The "art" of software, for me, lies mostly in the architecture and design, as well as in the UI/UX. There are many ways to produce the same functional result; the art of design is in doing this with the most suitability to business need (scalability, extensibility, reliability, whatever it may be). Most hacks can get SOME kind of software out the door... but can you do it so that you can replace the persistence layer, scale it up a hundredfold, or adapt it easily to changing requirements?
One of the most formative experiences for me was a very talented boss who became a mentor to me. He was fantastic at design; in one of his DOS apps he could pop out to the command line, set a language environment variable, and the UI would change -- even to Chinese! Incredible for a DOS application in the 1980's. I learned a lot about what was possible with good design.
I also blogged about my best practice for design: identifying "coherent concepts" from the real world. Too many times, I have seen developers make up their own, tangled models when plain, simple reality works just fine. Would love to hear comments, thanks!
http://softwarekeith.com/2010/12/21/conceptual-coherence-in-software-design/
Post a Comment