Freigeben über

New Job Title: Senior Simplicity Engineer

  • Artikel

I am running into some bumps with a couple of different software project I am involved with…. After mulling those over the break it occurs to me that they have the same root cause: complexity. As I think through the projects we have Program Managers, Development Managers, Development Lead, Software Architects, Software Designer in Test Tech Leads.. but who's job is simplicity? In many ways we reward complexity… of course we don't call it that. We say things like: architectural purity, broad vision, feature rich, long term thinking, and inclusive designs. Now none of those are bad things, and in fact I'd argue all of them, when done right, create simplicity rather than complexity.

So, my brainstorm is to create a role dedicated to simplicity. I invite you ordain yourself or nominate a co-worker as a Senior Simplicity Engineer

The job responsibilities would be:

  • Reduce complex problems to their root causes
  • Suggest and implement simple solutions
  • Root out unneeded abstractions and over engineering
  • Trim unwarranted dependencies
  • Focus on usage scenarios rather than design principles
  • Favor known, proven designs over novel experiments
  • Future-proof designs by minimizing current exposure

Other suggestions for job responsibilities?

Is anyone ahead of me on this? Do you already have this role in your organization?

Comments

  • Anonymous
    November 25, 2006
    It has been said so well in the past, I won't try to summarize: http://www.csd.uwo.ca/staff/magi/personal/humour/Computer_Audience/The%20Parable%20of%20the%20Two%20Programmers.html

  • Anonymous
    November 25, 2006
    Excellent idea.  Maybe Simplicity Assurance?   Or maybe a specialization of Quality Assurance?  Engineers are notorious for makings things more complicated then they need to be.

  • Anonymous
    November 25, 2006
    In light of Joel Spolsky's recent comments, maybe a Simplicity Manager is needed along with a Simplicity Engineer (or is that too complex?) http://www.joelonsoftware.com/items/2006/11/24.html

  • Anonymous
    November 25, 2006
    Doesn't it seem odd that you want to add someone to create something simpler? Very corporate though.

  • Anonymous
    November 25, 2006
    Brad: While I applaud your efforts to avoid complexity and simplify things (I really do; MS products are getting out of hand), I can't help but point out the irony in simplifying things by adding complexity through yet another role title in your already convoluted organizational structure :)

  • Anonymous
    November 25, 2006
    It would have to be someone both persuasive and influential who can stand up and say no to people's pet features.  It's not easy to tell someone that their use case is not mainstream enough to deserve cluttering up the interface. BTW, what exactly is "exposure"?  Surface area of the API?

  • Anonymous
    November 25, 2006
    I felt this exact thing (about 3 years ago) and that's why I feel so strongly about my title.

  • Anonymous
    November 26, 2006
    The comment has been removed

  • Anonymous
    November 26, 2006
    The comment has been removed

  • Anonymous
    November 27, 2006
    Hi Brad, I'm the software architect and programmer of Karvonite. An agile persistente framework. I applied many of principles of your Framework Design Guidelines book.

  • 80/20 rule
  • Usage scenarios
  • Addition through substraction
  • Low entry point Check the API documentation. I think this is the simplest persistence frameworks available. Of course it has some limitations. Regards

  • Anonymous
    November 27, 2006
    Очень интересную идею подсмотрел я у Brad Abrams . Он предлагает придумать новую должность - Senior Simplicity

  • Anonymous
    November 27, 2006
    Things get too complex when you have the wrong people working on something or you set priorities the wrong way. Adding more people will only make things more complex.

  1. Cut back in scope so people have more time to think about what they are doing.
  2. Define early on what it is you are building and for whom and why.
  3. Fire the people you are currenly promoting for "getting things done quickly".
  4. Give more decision power to the people that get less done but can't sleep well until it's "perfect". Simplicity is not a job role - it is an aspect of EVERY ROLE. Instead of having another role you should think about unifying some of the roles you have so the person making design/implementation decisions actually understands the different aspects of what is being built.

  • Anonymous
    November 27, 2006
    The title you're thinking of is "Architect."  Open your copy of "The Mythical Man-Month" and reference "conceptual integrity" in the index. Simplicity and features always compete. One person must have responsibility for both.  A pair, one responsible for features and the other for simplicity will never achieve consensus.

  • Anonymous
    November 27, 2006
    You don't need another role, nor do you need even need to list additional responsibilities for your existing people. Instead, simply make simplicity a measure of success.

  • Anonymous
    November 28, 2006
    I'm the technical lead for a subdivision of a company who's small engineering team is in Shanghai, which is to say that it's mostly a junior team.  One of my responsibilities is to help maintain a level of quality within our code.  I didn't realize it when I started the job, but much of that responisibility boils down to exactly what you describe.  On one occasion, after an ineffectual email thread on the subject w.r.t. a given class, I decided to simply rewrite most of it as a demonstration to the team.  When I was done (it only took about four hours), I counted lines of code to compare.  The rewrite was 70% smaller.  They incorporated the changes, which will probably save us way more than four hours in bug fixing and maintenance down the road. To answer your question, I don't think a new job title is needed.  I agree with a previous comment about Architect filling the role already.  That said, the Architect has to be watching implementation as it happens because the best laid plans can be implemented poorly.

  • Anonymous
    November 28, 2006
    I tried.  I told management they were wasting money, creating huge delays in the schedule, and creating a maintenance nightmare.  They threw up their hands and told the techs (3 of us) to work it out.  I was voted down 2 to 1 by the lovers of complexity.

  • Anonymous
    November 28, 2006
    tomasr, see Law 5 http://lawsofsimplicity.com/category/laws?order=ASC

  • Anonymous
    November 29, 2006
    I'll nominate one of your own... Shawn Burke is the engineer you are looking for...