New Job Title: Senior Simplicity Engineer


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 (18)

  1. Peter Ritchie says:

    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.

  2. Kip says:

    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

  3. mike says:

    Doesn’t it seem odd that you want to add someone to create something simpler? Very corporate though.

  4. tomasr says:

    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 🙂

  5. Pete S says:

    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?

  6. I felt this exact thing (about 3 years ago) and that’s why I feel so strongly about my title.

  7. I think you have to do "evangelization" of simplicity in your own team and developers at large, just as you have done with the Design Guidelines (maybe a follow-up?).

    Until people do not get the gut feeling that some part of .NET ARE over engineered, you are swimming upstream. Almost all features coming out since and including .NET 2.0 are following a dangerous trend and causing many frustrations.

    About the dependency problem (and also feature locations), you might want to look at this *excellent* post:

    <a href="http://weblogs.asp.net/ralfw/archive/2006/08/27/.NET-naked-_2D00_-See-these-hitherto-unpublished-pictures-of-the-.NET-Framework-architecture.aspx"&gt;.NET naked – See these hitherto unpublished pictures of the .NET Framework architecture</a>.

  8. diegocanepa says:

    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

  9. Items says:

    Очень интересную идею подсмотрел я у Brad Abrams . Он предлагает придумать новую должность – Senior Simplicity

  10. X says:

    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.

  11. Y says:

    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.

  12. snprbob86 says:

    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.

  13. JSS says:

    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.

  14. 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.

  15. Marc Brooks says:

    I’ll nominate one of your own… Shawn Burke is the engineer you are looking for…