Reality Check with Virtual Decision

Remember real first engineers, Physicists. Physicists prove their formulas with indirect measurable factors. Temperature, weight, chemical reactions, reflections, light…

But how can virtual engineers observe the quality of their virtual work? How can software developers compare 2 different competing solutions? How can you map your code to reality?

Some measureable indirect indicators for decision quality:

 
• Number of “important” lines of code.
 
• Number of defects that happened from existing code.
 
• Number of classes, less classes make system simpler.
 
• Number of relationships, again less relationships make system simpler.
 
• Duplicated functionality, big nono.
 
• Performance.
 
• Other reports that can get generated by third party analyzers.
 
• Any other ideas?

Do you see that these criteria items can give some reality checks to software design decisions?

I would also add “maintainability of solution”.
How easy is it to maintain/support/understand the solution/code in the future.
Of course several of your mentioned items indirectly cover maintainability, however I think it deserves a separate point your list.

Davit, I think that the maintainability and understandability is indirectly covered in the list.  Few number of classes and relationships make the system decoupled which leads to easy support and testing.

I’d split the performance into 3 subcategories:
a) CURRENT software runtime performance,
b) Potential performance boost which can be achieved with minimal effort without changing the design,
c) Implementation performance. Some designs may have an awesome runtime performance but would require a long period of time to implement. In many cases it is unacceptable for top management.

ClutterFreeCoding, could you please elaborate more on the candy picture? I’m not completely clear how does it relate to software design decisions.

Ruben, you are raising points that there are more to Performance considerations. I have similar opinion. I saw complications happen when priority of performance is raised prematurely. That’s a good subject to cover sometime.

Davit, yes, maintainability is not covered as a separate factor. It can be a package of several factors. I’ve started on Simplicity goal. Maybe Simplicity is all that is needed for Maintainability. Maybe Simplicity combines all the points presented here.

Thank you for reading and for your comments.

Ruben,
Instead of performance I would suggest to focus on security
Performance (and security) is just another feature of software (though of course it’s an important one) and I don’t think there is a need to focus only on it.

However your post lead me to the idea that maybe in order to understand software metrics we need to focus on individual software properties (such as performance, security, largeness, etc)?

ClutterFreeCoding,
The term Simplicity is too abstract to be a metric for software. It’s obvious that simplicity will have a huge impact on overall maintainability. And I would even say that maybe these two terms are synonyms in case of software development.
However if you want to understand what means simplicity of software, you need to narrow down the term “simplicity” to basic metrics, which I think you are already doing in your blog.

I have few more metrics for you:

1. Program Length: the number of operators and operands in a program.
2. Cyclomatic Complexity: the number of predicates in a program.
3. Nesting Complexity: the nesting level of conditionals in a program
4. Data Flow Complexity: the number of inter-basic block variable references in a program.
5. Fan-in/out Complexity: the number of formal parameters to functions, and with the number of global data structures read or updated by functions.
6. Data Structure Complexity: the complexity of static data structures declared in a program
7. Object-Oriented Complexity: the number of methods, the depth of the inheritance tree, the coupling between classes, the number of methods that can be executed in response to a message sent to an object.

Davit,

The security for sure is an important path of any project. I consider that there is nothing to secure if you don’t perform well. In most of the cases, the security is a “post factum” phase, after making it work. Of source, unless you’re working a project where the security is the major goal.

Concerning the metrics I think you just blew up the simple term “simplicity” into more complicated metrics. Why do I consider them complicated? Because currently there is no well defined function to map these 7 metrics into “simplicity”. Another thing about “simplicity”. The human factor is hidden somewhere inside there, which is not present in metrics.

I guess this is going to be a long discussion

I wouldn’t agree with you that security is a “post factum” phase. I would say even more - the state of software quality will remain so poor until people stop thinking about security as a post factum phase.
But this is another story and I would prefer to discuss it in another thread (maybe when I open a blog about security? ).

Regarding the metrics. I think you misunderstood me. The metrics that I listed are not meant to explain the term “simplicity”. And they are not invented by me.
I wouldn’t agree with you that the term “simplicity” is a simple one for software development. If you still think it is - please define what means simplicity in the context of software development. (maybe after you define we will come up with few more metrics? )

And btw, if you review more carefully the metrics I have listed you will find out that they are not as complex as they sound from the first view.
I really find them very useful and simple.

It depends on your role. If you are a Security Engineer then yes - so start designing the project based on security reason. Contrary if you are developing controllers for semiconductor tools, db based products and most of commonly used application then the security is far-far-far away not the first thing you are worried about
Let’s ask the owner to open a thread for us .

Their definition is pretty much straightforward. What I was trying to say is what is the next step with those metrics? Do you know a way how to make the code simpler based on the metrics? If no then what is the reason of introducing them? - actually these questions are not asked to you personally. We’re just discussing it here.

Ruben,
Security is important not only for products which are security-focused. Nowadays all qualified developers must pay very careful attention to security while they are producing software code… independent on the product - be it a GUI application, Web site, word processing tool or a Firewall solution. Security is tightly connected to quality and vise versa. Noe that by saying security I don’t mean pure cryptography. It’s a much wider term.

Regarding metrics. The next step is to increase the quality of software development process by taking into account these metrics. For example, use automatic tools to run through software code and evaluate its simplicity. Such evaluation will help to find people who are not writing simple code and work with them to increase their professional level and finally help to improve the quality that the company produces.

I’m just saying that if the product is lacking performance, usability, etc then nobody would care about it’s security. No one would use it, cause its useless and inconvenient, even though is secure.

Security is surely important. But everything comes from the context of the project itself. If its a media website then it would be usability. In case of a library to perform video encoding it should be performance. When developing a project which correlates with fingerprint devices the winner would be the security.

ClutterFreeCoding,
If you don’t open a page for us we will continue flooding here

Ruben,
If you review my posts carefully you will see that I never told that security is the most important feature for any software. If what you are saying is really just “that if the product is lacking performance, usability, etc then nobody would care about it’s security” then I don’t see any reason to continue this debate cause I completely agree with this statement. However I think you were also saying other things in this thread (such as that security metrics are “post factum” and are important only for security-focused products). So let’s either not change the original subject or just stop debating.

As I mentioned in my previous post security is not just about securing the programs, protecting data and creating secure communications. This term is more generic and it applies to any software. Things are getting changed in this new world and I would recommend all developers to follow that change.

Take a look at the following citation from Wikipedia:

...
History has proven that software defects, bugs and logic flaws are consistently the primary cause of commonly exploited software vulnerabilities. Through the analysis of thousands of reported vulnerabilities, security professionals have discovered that most vulnerabilities stem from a relatively small number of common software programming errors. By identifying the insecure coding practices that lead to these errors and educating developers on secure alternatives, organizations can take proactive steps to help significantly reduce or eliminate vulnerabilities in software before deployment.
...

What I’m saying in this thread is that insecure coding can lead to bad software quality and secure coding practices (which is an essential part of security today) that have been evolved significantly recently give lot of new perspectives for identifying software metrics for further improving the software quality.

And I don’t understand why we continue debate on this. Don’t you agree with the statement above?

Davit,
You never told that security is the “most important” feature, but every time I say that “its NOT most important, and it comes from the project definition” you keep telling that its “important”(without the term “most”). That’s the reason we got in a deadlock.

The citation talks about code quality from vulnerability point of view. It says nothing about about code design quality, complexity, etc… I’m more than sure that there a tons of nice to have practices which make your code secure (like checking buffer size to avoid overflow, etc..) but don’t see how is it related to software quality(non security related) and simplicity.

Concerning my agrees and disagrees. I agree with the wiki citation. I would need to disagree with “insecure coding can lead to bad software quality…” as the vulnerable code does not mean bad design, and a non-vulnerable code does not mean perfect design and awesome implementation.

Ruben,
I think we got in deadlock because you are saying that security is completely not important for products which are not security-focused. And I really disagree with such statement.

Did I ever said that secure coding affects the design or simplicity? I don’t think so.
Did I ever said that secure coding affects the complexity of software? I don’t think so.
I just said that there are useful metrics that can be obtained from secure coding principles. Note that this topic is related to “quality of virtual work” and not only “awesome design of virtual work”. And for maintainability you don’t only need to care about design but also for qualitative code.

Look, let be bring an example.
Suppose you are designing a Windows service application which, for example, receives input data and returns some output. This data is not related to security anyhow.
From requirements point of view it doesn’t have anything to do with security.
However, when you install this software, it becomes an essential part of the Operating System. Now, any vulnerability that is present in your software will be a target for attackers, which when exploit it, will have access to many resources in the operating system that your service will have access to. If your service is developed for “Local System” account by not taking security recommendations into account, then everything will be even worse…

This simple example shows that security is a very important feature of any software application.

Davit,
For importancy I said - “for non security-focused apps security is far-far-far away not the first thing you are worried about”.

Your example is good. Lets say your service has lots of IP inside(non security related). So you start developing your product. What do you start with? Security and dealing with permission? I would start with achieving the goal first (which is the service itself). Once it is done (or mostly done) I would star making it stable to various kinds of attacks. Unless you have the service, there is nothing to protect.

Doesn’t it mean that in this case the security is a post factum activity?

It’s not clear for me what you mean by saying post factum activity but it’s clear that security also has high priority for any windows service application. This is a fact that we need to take into account always. from business perspective of course the underlying IP is the most important thing. However if you want to have a qualitative software you need to give high priority also to secure coding activities.

If by saying post factum activity you mean “not the first thing to do” then I would agree with you though when it comes to coding then I think there should not be post or pre activities - there should just be “coding with quality from scratch”. This will eliminate all the problems from the beginning of development.

I think we came to consensus. At least regarding secure coding. Don’t you think so?

ok