explorers' club

explorations in dev, science, sci-fi, games, and other fun stuff!

Development Processes are a Changin’ so What Gives?

2 Comments

It seems that the more & more that I develop in Flex (and in particularly in the Agile process), the more & more I see the devolution of certain processes. First let me preface by saying: I came from a design-ish background though I never fully embraced my role as such. I feel much more at home developing, or rather, I am more at home in the code pane than the design pane in FB2. WARNING: if you are not interested in hearing me bitch about something, don’t read any further.

Let me tell a recent happening (broken down in cave man talk for brevity):

  • Months ago, designer/dev’r (aka Smart Boy) says, ‘here is a great idea’ (not me BTW but a pal)
  • Smart boy quickly mocks up ROUGH draft in fav grfx program (I use a napkin or MS Paint myself)
  • Smart boy’s idea is jetisoned out the airlock because ‘proper’ processes and channels were ignored (someone higher up doesn’t want to sign off on a idea visited to them upon a napkin)
  • More months pass and idea is shelved
  • Traditional design and IA processes are utilized to create several new variations on the same them, each taking many meetings and days and much of folks’ time in the process
  • in doing so, disposable content* is created (i.e. wireframes, photoshop mockups, quick AJAX prototype)
  • Smart boy’s idea is revisited, with yet more disposable content
  • Photoshop mockup lands at my desk
  • I create a similarly, fully working flex version (in as much as a prototype can work) in about 30 minutes
  • Later it is learned that the process taken before landing on my desk took nearly two weeks?!?!?
  • I could have sat with whomever makes the UI requirements and did the whole thing in a fraction of the time.

What is the issue here? Antiquated processes and job security aside, the issue seems that due to the processes themselves, much time and disposable content has been wasted. Is the argument that the time spent was to formulate a great design? Was it spent determining what kind of data was to be used? Did certain higher ups need to make sure to review the design (for 5 seconds) before signing off? If all were true, does this explain why nearly two weeks were spent on JUST THIS variation? My god, what a waste of time!

Some folks could argue that the players involved were not using the Agile process and you would be CORRECT. It so happens that the designs were subject to the Traditional Waterfall Approach instead of the Agile approach.

What I would suggest is that if you are an Information Architect or a Designer, start looking at Flex as a tool to further your processes. Rather than spending hours wireframing shit, then more time making pixel-perfect mockups in photoshop (which never fits well in Flex, bitmap vs vector!!!hello?), you can work along side a Flex developer to morph ideas into working, non-disposable content. Regarding photoshop mockups: the mockups generally don’t translate well into Flex (without alot of fudging and bloating the file size) . At least from my exp. Regarding some wireframe: Instead of making some sheet of paper to be revisited for a minor edit, then subjugated to further processes of approval, get your idea into a flex app and do the edits later in there.

Obviously I am frustrated as I encounter this issue more and more. Get off the soapbox Justin!

Advertisements

2 thoughts on “Development Processes are a Changin’ so What Gives?

  1. Totally know what you mean.

    Just one more thing to suggest. If your app has dynamic data services you need to tie into, do NOT demo those. Suits do NOT give a shit if the data is real or not; they perceive it as real, dynamic, and cool as nuts. That solidifies their expectation of the working application, and assumes the rest is just details they shouldn’t care to know.

    Furthermore, fake data always works, real data doesn’t. If you want to ensure a meeting goes without a hitch, use fake, local (non-internet connection requiring). You’ll accomplish your main goal of garnering feedback from the client (or upper management) without going “Oh… well, we haven’t tested this… the server is down.” It’s all gibberish and no one cares. Do not depend on code that is not yours (aka the back-end).

    Instead, create a branch of the code base. If you are the only developer, you do not need to create a branch, but instead use copious “// DEMO” comments, much like TODO’s. The only difference is they “nudge” the app to work with fake data.

    When you’re demo / meeting is done, and you’ve discussed the feedback and potential changes, either merge your branch with the real code base (SVN branch vs. SVN trunk) OR, if you are the only developer, just start commenting out your demo code.

    I’ve found the “conflicting 2 priorities” of if the Flex app should look like the comps vs. be a fuctional for the sake of looks usually work themselves out by themselves. Naturally this wouldn’t fly in a design agency, but then again, I’ve seen a few start selling their services as more application specific… so it could go either way.

  2. For record, yes, I know developers in the meeting demos (including potential clients that have development staff attending) will call bs very quickly on an application that doesn’t pull live data.

    Fret not. Their opinion is worth crap. They are not the ones who write the checks. In the end, your app will more closely match the client’s application because they’ve already “seen it working” and given feedback, and by then you get to focus on making the dynamic data stuff work.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s