views:

343

answers:

6

I am interested in trying to introduce a new methodology to my company. This new methodology is Correctness by Construction (CbyC). This would be using ADA SPARK. The company I work for is an Aerospace company that has used ADA on many projects. Another factor is I am pretty low on the company hierarchical structure (Software Engineer II with 4 years of work experience). I would like to hear about any experiences in trying to introduce new methodologies, specifically suggestions on preparations and presentation. I would probably start with a presentation with our Process and Standards software engineer who is a direct report to the director of Software Engineering. The Standards person is pretty accessible and approachable. I would start with the resource managers but they seem uninterested in hearing about such things.

+2  A: 

Shouldn't you get your colleagues interested first?

I also thought about this quote, but maybe it's not so suitable in an aerospace company: "It's easier to ask forgiveness than it is to get permission" (Grace Hopper)

divideandconquer.se
I have shoped this around to some Senior and principle developers. They seem to give the impression that it would be something to look at. AS far as peers,the company is a very conservative top down company were people do what comes from the top down. I have though been having some talks with them.
Paul
My peers ambivalence, if any, is rooted in their powerlessness.
Paul
+3  A: 

It sounds like you have already done the first step, which is to identify a couple of people who have the power to implement the change who may be interested in improvement.

I would approach them with the following:

  • A brief, clear description of the new methodology and its advantages
  • Concrete examples of weaknesses in the current methodology that will be addressed by the new one
  • Some sort of monetary or time savings that will be seen upon implementation
Guy Starbuck
+2  A: 

Ultimately, the decision is going to come down to whether it saves time/money.

Having only ever worked with single teams with little hierarchical structure I cannot claim to know how to persuade a boss, but having worked alongside some I know that they want tangibles. You'll need to investigate several factors, including:

  • Why this methodology should be implemented
  • How much it will cost to implement it into projects
  • Concrete and relevant examples of this methodology in action
  • Full employee backing for this new methodology

As a Software Engineer it is part of your persona to be excited about your work, so there is little harm in pointing this kind of thing out to your superiors. However, you'll want to mount a serious defence when management start to question it.

EnderMB
I agree. Some of the data (and what sparked my interest) comes from this http://stackoverflow.com/questions/243387/best-language-for-safety-critical-software
Paul
I am more interested in techniques to present the proposal.
Paul
I would start with a basic proposal to start off with, just in case the boss wants to flick through a few fact pages while you speak. If he/she wants more then find a proposal template (there are millions of proposals on Google you could take the structure from) and create a formal document.
EnderMB
+3  A: 

If you get down to making presentations, keep it short and simple. Be able to pitch inside five minutes - even if they give you half an hour. (If they give you half an hour, spend fifteen minutes pitching, and then do Q&A for the rest of the time.)

Look at some of the 'presentation' web sites:

Jonathan Leffler
This is what I was looking for. Thanks
Paul
+1  A: 

I think I would be cautious considering that it involves use of Ada SPARK and involves learning to rely on strong verification methodologies and Z Notation. Also, the Tokineer project which is being promoted as a success consists of just-under 10,000 lines of code. The identification of only a single defect in that code since release is certainly promising but one needs to determine how much the kind of specifications and code in that demonstration project are akin to what you deal with.

I think you might want to take a look at Tokineer and see exactly what is involved and how it relates to the code base and the code development that is underway now for your aerospace work.

You might want to work with the Process and Standards fellow to identify the kind of external experience with CbyC that is available, especially information from teams that did not involve the original developers of CbyC. In most cases, there will need to be a pilot effort and how that can work is also important, in terms of learning curve, ability to integrate with other efforts, and so on.

Mainly, I think you need to do more homework, especially depending on how much this is a radical injection into current development activity, existing maintenance obligations, and in-progress work.

orcmid
Those are valid points. I would probably pitch it to be limited to a small project.
Paul
Man I really thought hard about saying this was the answer. I had considered most (but not all) of what you said already( I do know about tokineer). This is really a two part question. I wish I could say both answers are the right answer.
Paul
+2  A: 

You should definitely read the book, "Fearless Change: Patterns for Introducing New Ideas" by Mary Lynn Manns and Linda Rising. They've studied several instances where organizations have (and haven't) successfully introduced significant changes to their practices. I think it would be of tremendous benefit to you in helping your organization to do the same.

tvanfosson

related questions