The Designer Developer Divide
It's conference season here in the UK and over the past weekend, there have been two great ones; The Digital Barn 3 in Barnsley and DevDevDev North in Sunderland.
I have been to DevDevDev before, but it was the first time I could get to the Digital Barn. It was a fantastic day with lots of ideas to think about and take away. I was keeping track of tweets coming out of both conferences and one thing occurred to me was about the divide between designer (Digital Barn) and developer (DevDevDev).
The tweets were:-
Digital Barn
‘Most incredible thing at #digitalbarn is that I’ve seen a Windows Surface tablet.’
DevDevDev North
‘Seeing a lot of Window Phone and Windows 8 devices at #dddnorth today.’
Digital Barn has a slant towards web development with an emphasis around design, SEO, responsive sites and analytics So it was pretty much a Mac centric universe whereas DevDevDev is more of a general development conference, so there was bound to be more Windows, .Net, Rails, PHP and hardware programming. This is fine in itself as we all should choose the tools that help us to get to the end goal.
But it is also important that the designers and developers aren’t siloed off in enterprise organisations with no contact between them; much the same way operations teams have become separate to development teams in the past.
With DevOps becoming more prevalent in organisations, perhaps it would also be important to include the designers in the whole picture; heck why not the UX guys and the SEO guys. In fact I came across an article in a recent .Net magazine regarding menu structures for web sites. Without breaking copyright laws the idea is this:-
The Hierarchy Model
The Hierarchy Model
This model will be very familiar so I won’t wast any screen estate on it.
The Faceted Model
The Faceted Model
In this model there is a central idea, in this case its the project. All other teams work in an interlaced fashion with better communication between teams with perhaps a person specializing in such interactions heading up the communications This whole concept can be broken down and re-created for each project with a fast turnaround. Every body in this model is working to get the project done, not to serve their line managers needs. Perhaps the person acting as liaison could act as an interim line manager for the particular project.
In the real world though a SQL Bloke would be working on multiple projects at the same time, so some form of time-boxing would be needed to properly manage workload. The more development oriented people will already be familiar to Scrum practices, so this concept would not be completely alien to them. Other teams would need some basic training into Scrums and Scrum masters and other Agile methodology to get the full benefit.
Perhaps DevOps is the first step down this road to get all teams working in a better fashion.
It's just an idea, does anybody have any thoughts?
Happy coding.
The post The Designer Developer Divide appeared first on Don't Believe The Type.
