Magik Metrics

How Much Time to Implement This????

What a loaded question… This discussion is designed to provide you with several things to consider when asked this question and to come up with metrics. Please feel free to add/modify this discussion with your experience.

Background

With the interpretive coding technology of the Magik language, you can loaded and change the code during the system session. This alone is a huge advantage to implementation. Another thing that Smallworld provides is about 80% of the code they use to develop the core application. So if you see something that you want to modify or duplicate with your specific modifications, you can search for the code in the core release directory and see how it is done.

I believe the best type of person that develops Magik code should be considered a "hacker" that can find example code and modify the code to fit their needs. I've seen people with a pure software background from college struggle finding the examples because it is not as structured as Java or C++. But even those people come around and really love Magik and hate moving on to other languages.

Complexity/Engineering

I personally think the two biggest factors to metric determination are how complex the functionality is and how much system engineering is done prior to implementation.

Complexity Determination

As with anything the harder something is the more time it takes. A good way of thinking about this is coming up with a scale 1-3 or 1-5. 1 being the easiest and the higher the number the more complex. I normally think of 1s as something I have mostly done and is pretty much a "no brainer." 3s or 5s are areas that have not been done and there really isn't an example of how something like this should be done.

Systems Engineering

One thing is known the more something is planned the easier it is to implement. Of course too much of a good thing is normally bad, so moderation is the best here. If you engineer your solution down to the method level (or small group of methods) you can easily develop estimates from this engineering. I typically say I need a method that does X another one that does Y and a third that does Z. I then say I need an engine that implements XYZ and that a GUI that calls the engine. So now I can estimate each item based on its complexity.

Engineering to this level also gives you a great way of scheduling, tracking, and assigning each of these tasks!

Development Tools

There are a series of tools that help with your development. For example: Igor's Emacs extensions, MDT's Eclipse Plugin for Magik, and core development tools for debugging. All these tools provide enhance the speed of code development and should always be investigated.

Metrics Determination

Include Comments or Not?

This is an ongoing debate should comments be included or not in metrics collections. IMHO I believe comments should be included in metrics. I believe well documented code is more useful than poorly documented code. So why penalize a developer for taking the time to comment the code?

Mark's Best Guess

Assuming the comments are included and range in the 50% range of the total amount of lines here are some numbers that I see.

  • Level 1 150 lines/hour
  • Level 3 100 lines/hour
  • Level 5 40 lines/hour

Should Unit Test Development be Included in Metrics?

Probably. If Unit Test development is included in estimates. I typically see the unit testing equaling the amount of time (and up to to 50% more lines of code) it took developing the code initially. This may seem to be a lot of time, but when you think about how to test and developing the test cases and the code for those cases, you will see this is pretty accurate.

So why develop Unit Tests? It is not necessarily for the initial development. That is what testing is for. It is for future changes. If changes are made in the future, it is much quicker to run the Unit Tests than trying to develop a testing strategy that not only includes the changes but includes regression testing. If you have Unit Tests in place and changes are done your bugs/rework will decrease up to at least 75% (in my experience).

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License