Friday, July 16, 2010

Left versus Right

I have recently read and heard discussion of the two sides of the brain. The left side is more factual, concrete, and good are more of the engineering tasks. The right side is more bigger picture, capable of discovering odd patterns, and is better at creative tasks. To produce new valuable and applicable ideas you generally have to switch between the two back and forth. Digging up connections between bits of knowledge from the left and finding new connections to consider with the right. Verifying with the left and digging up more and the cycle continues.

Software development certainly combines both sides of the brain, but sometimes I read or see how people are trying to make software development into software engineering.

Comparing software development to an engineering discipline is always interesting in my mind. I know there was some movements (academic and professional) on trying to develop a software engineering discipline, but I don't think that can happen. Engineering disciplines usually have many years of grounded research and field application to prove how to do things, but we are in a world that is completely built off of arbitrary ideas that are built on other arbitrary ideas that may not always be true. There is a degree of creativity and judgement needed I think in software development that isn't as needed in the engineering disciplines I have encountered. I think this is partly because of how soft what we are shaping is, the speed of technology, the youth of our field, and the wildly differing ideas we face. I will admit I do not have experience in performing or studying any engineering discipline past a basic level.

An example of what I'm getting at that is applicable to what's happening in our field currently is that all our knowledge of object-oriented software design and practice is not directly transferable to working in a functional oriented way. Also our knowledge of relational databases won't transfer over very well to document databases. I suppose being able to apply the knowledge of a particular technology is a more engineering task but knowing when and where to use a particular technology and how to combine it with others is probably a more creative task.

This is just partly my own theory I was just thinking about. You guys have any feedback or opinion on the subject?

5 comments:

  1. I also am thinking about burn out in our field. I think that a lot of us are more right brain oriented people. We like to try, combine, and come up with new ideas and technology excites us because there are always opportunities to do this. Perhaps that's why open source software is going so strongly.

    We don't want to get stuck performing only left brain activities, but that seems to happen more I think as a project grows in age and depending the environment. With out the opportunity to try ideas and improve a product I think that leads to developers being discourage to improve or experiment. Which could lead to degrading performance and quality.

    I think it's important for an environment to try and sustain creative enthusiasm for a project, but I'm not entirely sure how to best do this in a business sense. I know for a developer like myself I just want to be given a chance to experiment and learn. From the business perspective why should they care if you can produce new features with how you do things now?

    ReplyDelete
  2. One thing to be aware of is that developers not only want to experiment, but they _will_. In an enterprise environment it is in the business' best interests to foster that properly, otherwise it will completely lose control over it.

    No matter how rigid and structured the owners/managers/etc. might think their process is or how much control they think they have over it, the developers writing the code are going to try new things. By not fostering that the business pushes it underground, effectively turning a blind eye to something that is undeniably happening and shifting it from being an opportunity to being a risk.

    ReplyDelete
  3. Yeah I suppose that's true. Also if it runs underground you could have people writing code that others can't maintain because they aren't openly collaborating on the ideas.

    ReplyDelete
  4. Sean: I think the burnout is just a byproduct of the majority, especially corporate, employer's business model. Many people go to college to turn their passion into their career, but in my narrow view I’ve seen their careers destroy their passions.

    Say if I loved to cook because there are just so many variations of food and I love to experiment with different flavors and etc. You would think that a job as a cook at Outback Steakhouse or something would be great? Well, everything that you liked about cooking has been turned into this assembly line redundancy, where you cook a small subset of food and that’s all you do and you'll eventually hate cooking because everything that has kept you passionate about cooking has been taken out of it. The product is economical and guaranteed, but nobody who works at these places has fulfillment from this type of work.

    Now there are those neat restaurants that always have like 4-5 different specials of the day and always have a fluctuating menu which I imagine working at as a cook would yield a whole lot more fulfillment as a career. It's just that these places are 1 out of 20 different jobs.

    People also write cookbooks, have cooking shows, cater instead of opening a restaurant, sell sauces, etc.

    For programmers, there's a ton of different things too. Just working at places were we work at have the most stability and require the least self management at the greatest cost of our souls. :(

    ReplyDelete
  5. That is, unfortunately, the corporate machine at work. Create a repeatable process which produces money, commoditize the resources (including the people), repeat the process. (And, somewhat recently, litigate to protect the process when it no longer produces money.)

    It's worked pretty well for a lot of manufacturing industries, but is terribly unreliable as a strategy for software. The employers with the above mentality are the same ones who say things like, "Why do we need so much testing? Just write it correctly the first time."

    ReplyDelete