SEMAT, Software Engineering, and the fashion industry

Apparently there is going to be a revolution in the software development world, backed by some very illustrious names in the industry. In the words of Ivar Jacobson, one of the people behind it:

We are some people who have observed software engineering theory and practice of the past decades and have realized that it is now time to revitalize this discipline. We have been quietly planning a “revolution”.

And here is the “Call for Action” statement for this revolution (called SEMAT — Software Engineering Method and Theory):

Software engineering is gravely hampered today by immature practices. Specific problems include:

  • The prevalence of fads more typical of fashion industry than of an engineering discipline.
  • The lack of a sound, widely accepted theoretical basis.
  • The huge number of methods and method variants, with differences little understood and artificially magnified.
  • The lack of credible experimental evaluation and validation.
  • The split between industry practice and academic research.

We support a process to refound software engineering based on a solid theory, proven principles and best practices that:

  • Include a kernel of widely-agreed elements, extensible for specific uses
  • Addresses both technology and people issues
  • Are supported by industry, academia, researchers and users
  • Support extension in the face of changing requirements and technology

The list of signatories to the “revolution” is quite impressive. See for your self on their web page. Sounds good? But not everyone agrees, as you can see on this blog. The author of the blog has an issue with the very framing of the problem:

But this is an entirely misguided movement. Let’s analyze the call for action, bit by bit. It begins:

Software engineering is gravely hampered today by immature practices. […]

[…]

Never mind that people in the community (most prominently Tom DeMarco) have spoken against this paradigm, or that software development has little to do with most established engineering disciplines: the people behind SEMAT have chosen to ignore these criticisms and move on.

Fair enough. This critique reminds me of this really old paper, called “Masterpiece Engineering” that you might have heard of. Apparently, there were people doubting whether software development is really engineering even when the term was first coined circa 1968.

But what interests me is this statement by SEMAT:

The prevalence of fads more typical of fashion industry than of an engineering discipline.

So if Software Engineering is not engineering, could it be fashion? Let’s see. Here are my observations:

  • Formal study: (a) Electrical Engineer: formal degree required; (b) Software Engineer: formal degree not required; (c) Fashion Designer: formal degree not required
  • Work: Engineers: work hard; (b) Software developers: work harder; (c) Fashion Designers: while they are apprentices, work their ass off; as soon as they “become” a designer, stop calling it work and start calling it art; the amount of work/art that needs to be done everyday is inversely proportional to how good you are considered
  • Respect: (a) Electrical Engineer: gets some respect from the people who work for him, for his knowledge; gets respect from people he works for (the “business folks”) only if he can keep the cost low; (b) Software Engineer: gets no respect from anyone, including the janitor services, unless he accidentally makes some money from a dot.com IPO; (c) Fashion Designer: gets respected both by people who work for him, and people who he works for, directly proportional to how much he/she is exploiting them
  • Fame: (a) Electrical Engineer: not famous, with rare exceptions of people who have managed to make something that has the astonishing capability of being really appealing to customers and their company’s marketing department at the same time; (b) Software Engineer: not famous as long as they are doing the right thing; you need to write a worm that brings down the ‘net to be famous and maybe not even then (c) Fashion Designer: often famous, especially if the product simultaneously manages to be feckless (you don’t know whether its a skirt or a bandanna) and useless (does not cover the body)
  • Discipline: (a) Electrical Engineer: practices great discipline in work; (b) Software Engineer: is expected to work with discipline during office hours and continue to work with passion until midnight; (c) Fashion Designer: discipline is death!
  • Creativity: (a) Electrical Engineer: as his experience grows, tries his hand at more creative things; (b) Software Engineer: to start with, because he does not know much yet, everyone around is too busy to teach, there is no training budget, and anyway the product has to ship by month end with no time to learn anything, has to be creative by using the only tool he know to do everything; only after gaining much experience can he stop being creative and actually do thing properly; (c) Fashion Designer: your creativity is defined to be inversely proportional to how many people can afford your clothes

So, from the above, it is clear, fad or no fad, a Software Engineer’s life is nothing like a Fashion Designer’s. It is also not like an Electrical Engineer’s.

P.S.: while I have a Bachelors and Master degree in Electrical Engineering, and I have been developing software professionally for some time now, my profound knowledge of the fashion industry is gained entirely from the movie The Devil Wears Prada.

Advertisements
Post a comment or leave a trackback: Trackback URL.

Comments

  • Romil  On January 25, 2010 at 3:06 pm

    Great thoughts Parijat.
    I do agree Software industry and specially the organisations into “IT services” have turned it into a fashion with fancy names

  • Jay Buente  On February 27, 2010 at 2:26 am

    Like the design, template, post is OK, writing is good. I’ll probably drop by again….

  • Bob  On February 28, 2010 at 1:40 am

    I have been designing and building enterprise level software systems for a long time. I have been on projects where it was difficult to get the client to take the time to write an informative business case to frame the problem that they were trying to solve. Whether you called this a scenario, use case, story, or more formal business school style business case made no difference because the client didn’t value spending the time to do it.

    I have seen this problem often enough to believe that some fundamental shift has to happen in how the people who pay the bills value requirements gathering, analysis, and design work before any kind of “scientific” pardigm could be applied in our field.

    • parijatmishra  On February 28, 2010 at 4:04 pm

      I completely agree. From my own experience (of building non-enterprise, new-agey, startup-ish apps), the single biggest cause of project failure or dissatisfaction is because the “sponsor”, “client” or “owner” of the project:
      – does not sit with the team to define the project requirements in detail, making traditional project methods impossible
      – makes it hard enough for the development team to get quick feedback and answers to questions, that xp style methods also become impossible

  • Bob  On February 28, 2010 at 10:26 pm

    I also found this issue of the business sponsors being unwilling to put time into defining the project much worse at start ups.

    I do requirements gathering a bit differently and build business case studies and from those derive scenarios, use cases, and a requirements definition. Every start up I ever worked with did not have sufficiently detailed business case studies and vehemently resisted creating them. They viewed this work as a waste of time.

    I always wondered how they convinced people (VCs) to invest in their idea when they could not properly articulate how they were going to turn the idea into a viable business.

  • Mohan Radhakrishnan  On April 17, 2010 at 1:39 pm

    ven though I have come across the same types of problems you
    write about there are two aspects that stand out always.

    1. Lack of respect. This situation is created by the client business
    types and the service provider’s managers. Business is alway respected
    by the senior management because they make money. So business decides
    when to release the software. Obviously it fails because the opinion
    of the senior programmer or Tech. Lead is relegated to the background.
    The tech. lead searches for a new job.

    2. Lack of testing. Business does not see value in testing. I have banged my head against the wall so many
    times because I am not able to convince the business that it requires
    extensive testing.

Trackbacks

  • By What is Scope of Software Engineering? « SEMAT blog on January 26, 2010 at 8:22 am

    […] The importance of the wording is also illustrated by the other discussions that touch on topics such as ”what is the relationship between software engineering and the management of software engineering projects?”, and “what is the relationship between software engineering and systems engineering?” There have even been other people publishing blogs on the suitability of the term software engineering as the banner for an initiative of this sort, one of our favourites being https://parijatmishra.wordpress.com/2010/01/08/188/. […]

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

%d bloggers like this: