I really liked the concept for this book, but found parts of it troublesome. Meiling certainly touched upon one of the issues I had – trying to compare this philosophy with the demands of academia. We are certainly not expected to “one-down” or “under-do” our peers as far as academic writing and publishing is concerned.
My other problem with this book is that it seemed to take for granted a certain comfort level for designing and implementing software that could easily be applied to new projects. They never touched on the investments one must make to actually learn how to design a GUI, write code, plan a business model, etc. that are necessary steps BEFORE even setting out on a new project. This learning process can take considerable time and money before you even arrive at the stage they’re writing about, and may substantially affect the time and resources you have to beging working on your next-big-thing.
That being said, let me provide a few points that I thought were useful for us as academics and future tech entrepreneurs.
Firstly, their approach to creating a viable and useful product can be applied to academic writing on a smaller scale. When I have an argument to write, the task at hand can seem very daunting. I often have a rough idea of how I want my paper to progress, but it’s never really formalized until I begin writing. And editing. And editing. And editing. I see their approach as similar to the outline approach that I’ve tried to convince myself to do forever, but have only done a few times. Write an outline of your argument – a barebones, only-necessary-material outline. The times that I have done this, my writing process was much smoother and much faster, and required far fewer edits. You can strip away any unnecessary sub-arguments, can identify any extraneous evidence by seeing in advance how little it actually fits with the core of your argument, etc.
Start with your main idea, make it big and far reaching, then strip it down, and down again, until you have a solid argument that can stand on its own and doesn’t try to do too much.
Secondly, and relatedly, the idea of trying to make a piece of software that is 1) initially as simple as possible and 2) only adding complexity when repeatedly requested by users to do so is, at the core, espousing a version of Ockham’s Razor. By starting with something solid that has a definitive function, you can escape unnecessary complexities that can detract from the core functionality of the software. Only when there is a necessity to expand upon the core functionality of the software should there be any additions. I agree that this keeps the software as true to the ‘vision’ as possible, while also making the software less cumbersome to use.
Great discussion all. I want to offer some words of reassurance, and then tease out one metaphor/comparison.
Getting Real is written for an audience of experienced programmers, managers and web entrepreneurs who are already steeped in making things for the web. Pointing out that they don’t talk about how to learn how to code is similar to noticing how a text on how to write your dissertation likely don’t talk about how to use the English language to form grammatically correct sentences. If you are talking about writing a text that is many hundreds of pages long, you already know how to write. But that doesn’t mean that the lessons learned in such a book (set aside a fixed amount of time every day, sit down and write without stopping, etc) are not useful to the person who is trying to write things smaller. In your cases, you are all just getting started. You should not feel like you have to instantaneously be creating full web applications of the kind that Getting Real covers: those are made by teams of advanced programmers. What you should takeaway are the *strategies* for thinking about how to make projects like these happen. And you should start small, and keep learning. And keep learning. And keep learning.
Laura compared the model presented in Getting Real to the process of writing a paper with outlines. I think there is a lot to be gained from this metaphor. For one, it gives you all a handle to grasp onto, as papers are your game. But I want to argue that what Getting Real is talking about is less about writing papers, and more about *making projects.* I will make one distinction between the two, but I think there are more: when you finish a paper, it hopefully gets published, and maybe it gets reworked a little bit and added to a book that gets published. When you make a project on the web you make something and publish it on the web, and then you make changes to it (revising or augmenting it) and publish that to the web, and do it again, and again. You often keep revising/maintaining it until you decide to kill the project, and then it is effectively *de-published.* A paper exists as whole, a project exists as a process.
And so in this way, as Chrissy pointed out and Hadassah picked up on “the academy” could in fact be seen as a *project.*
And so given this framework, think about your dissertation, and then think about a chapter and then think about a section, and then find the smallest coherent chunk of that section and that (metaphorically) is like the starting point of your project. That chunk (and maybe a few other chunks nearby) is your first goal.
Ria – I totally understand what you mean about filling the knowledge gap – and the only thing I can really say from my own experience is that it takes a lot of time and determination. For about two years now, I have been working to become more competent with technology, especially in regards to making it do things that I envision. One thing I have tried to do in the past to help overcome the knowledge gap is figure out if there is a program out there that exists that is designed to enable someone with very little coding knowledge to create what I envision – such as Adobe Dreamweaver, which Hadassah showed us in the HTML workshop – which is a program designed to be very much like a word processing program from the graphical user interface side, but does the translating into HTML for you – so you can insert text, re-size things, add links, etc, and it will translate all of that into html, and you can see the translated code (but you dont actually have to write the code). And I think, in general, we are now in the age of application services that allow us to create digital “things” with very little knowledge – and I think there is also a huge trend to making “intuitive” graphical user interfaces (or, in other words, programs you can learn to use effectively in 5 mins). Think of Prezi, or Windows Live movie maker, or voicethread. All really easy to use, can be learned in about 5 mins., and can help you create some interesting things. They are limited in what they can do, and as a user, you are limited with what you can do with it, but if it fulfills your basic need, then that’s perfect. Personally, I am now at a point where I have very specific ideas, and there is no pre-made program out there that will allow me to create exactly what I want – so now I want to learn to build something myself – and that process is a bit daunting. I am still not sure how it will turn out! But I still use these other programs all the time – programs that allow me to create interesting things, without having to code the program itself. And I think we will see more and more and more of that in the coming years, software that acts as an intuitive service, making it easy for the user to create new, interesting, and useful things with minimal technical knowledge. If you can learn how to do the actual “building” of the software – that is pretty awesome – especially when there is no program that exists that will allow you to focus on the content side, and the software “magically” does the rest. but that might take too long, or too much time. And I think that is where Michael’s advise to assess what the EASIEST way is to create the BASIC thing that you want enters in – because some hurdles may just be too big to jump over.
Laura, Naomi — thanks for articulating the problem that I’ve had since the beginning of the term, and one that we don’t reaaally talk about all that much, that — for some of us — learning basic HTML, simple coding stuff, is like learning Greek. It’s reassuring to have people in class who know how to “do stuff” in Web 2.0, but a workshop just about begins to help fill in the huge knowledge gap that I have, and which I honestly don’t have the time to fill in. For me, this semester feels a lot like my semester with the GC’s Language Reading Institute where we took “Spanish for Academic Reading” or whatever that class is called (the one you take to pass your language requirement). I went from knowing no Spanish at all (but some French), to being able to recognise the major tenses and look up the rest in a dictionary. Have to say that I rather enjoyed the break-neck speed of that class (although I spent most of the first part of term worrying about flunking); have to also admit that I haven’t picked up a Spanish book since… :-/
Thanks Naomi for finding a way to say that we can pare down, but still have to offer *something* that is valued. The elephant in the room in Getting Real is the writers’ comprehension of and metonymic use of “code” to refer to ALL the coding languages they already understand and can use to achieve their simple, cut-back ideas. Without knowing how to write a paper, you [at least, I] can’t write a clearer, more focused paper. This logic must apply to the world of production in code as well.
I see that Laura — will my customers see that I produced this correctly/enough — and Naomi — what do I have to learn? — have questions that are on two sides of a coin: What we are going to make, in itself, needs to be useful, creative, worthwhile, and needed in order to be assessed or assessable in the first place. It’s not just the scope [what] its also the content and the capacity to build.
I definitely agree with Laura about the “comfort level” issue. For many of us, we are still climbing the steep side of the learning curve in how to actually use all the available tools to build interesting interactive technological products/projects – and that learning curve does represent an investment of time and effort that is not covered in “getting real”.
But perhaps it is because of this steep learning curve we are facing that several of the points made in the book hit home a little harder – if someone has all the skills needed ALREADY to build their “next big idea”, then it may be difficult for them see their own “scope creep” – to take a step back and strip down the project to the bare essentials, because they are actually capable of creating endless amazing features, if they had unlimited time. I know for me personally, I feel as though I am constantly faced with three questions:
1) what is the bar essential thing I am going for…
2) can I break down my essential thing into a series of components I need to create…
3) what do I have to learn how to do in order to create this?
and it is often question 3 that can yield the most daunting answer – because I am facing a steep learning curve – but, it may also force me to strip down even more, because I am forced to be realistic about how much time I actually have to learn how to use the necessary tools AND create the product.
I think in the end, it really comes down to what Michael was talking about in our very first class this semester – finding the balance between pushing yourself to learn something new and overcome the learning curve obstacle, while also being realistic about your own capabilities and time restraints – and like many people have touched on already in this discussion, many of the points in “getting real” can be applied as a kind of life lesson / strategy for approaching things beyond the technical project realm (like our academic writing and research in the academy). I LOVED how Hadassah described this at the end of her comment – “This parallel is helping me see the Getting Real piece as more like Life Advice with a dollop of systems theory and utilitarian or pragmatic philosophy, as well as a way to parse the rhetoric of larger systems.”
Janice – I think you’re right to say that there is a challenge in maintaining the essence of of something (a website, software, a paper) while trying to figure out and trim down the features that don’t seem appropriate. How can we determine what is appropriate for the project?
What we’ve encountered so far has been the minimalist approach, with that ‘get it done’ mantra that I think everyone is right to question. I think the problem lies somewhere in our understanding of the identity of something. If we’re trying to launch some software and we’re focusing only on a few key features, and these features are features that other programs have, yet our emphasis is on the simplicity of our model, how are we going to be perceived? How will consumers identify us? As innovative in our simplicity? As earnest innovators not looking to do too much too quickly to avoid mistakes? Or as developers that released the product too soon, before any of the novel features were added?
I think the balancing act is trying to figure out how to have your customers perceive you as a mix of the three, as this will probably engender the most patience from your customer base while you grow and expand.
—
Hadassah, I like that you pointed out that the academy as a whole is a ‘work in progress’, never really capable of ‘getting it done’ – and this is okay. The incremental progress that is made is more valuable than a rush to the finish line; if everyone did this with their research, or if entire departments rushed faculty to ‘get done’ new works every year without the peer-review process or without conferences, the quality of the work produced would suffer, and that would be bad for the entirety of the academy.
An amen to the notion of life lessons in getting real, Hadassah.
The challenge that seems to go unmoved- and may not be within the scope of the discussion- is in figuring out what can be pared away without losig the essence.
(Though, aren’t priority setting and time management at the basis of very endeavor…)
Thanks for this way of parsing the argument, Laura. Like Christina pointed out on Meiling’s earlier post, the entire Academy can be framed as a work in progress that is constantly taking small steps forward, assessing [peer reviewing instead of user/customer feedback], discarding ideas/research that are not usable or needed, and then building better with future research and writing.
For another class I just read Anne Lamott’s “Bird by Bird,” a text on, basically, how to write a book: take it one little, achievable, piece at a time and do so with discipline and perserverance. While creative writing and perfectionism have their own issues, the broad ideas of “getting it done” and keeping projects achievable by limiting the way you envision their scope translates from 37signals’ to Lamott’s advice. This parallel is helping me see the Getting Real piece as more like Life Advice with a dollop of systems theory and utilitarian or pragmatic philosophy, as well as a way to parse the rhetoric of larger systems.