Software: More Than Code?

Software: More Than Code?: Trying to Find Value of How We Code

I have always been a big supporter and advocate of making sure code is done correctly. I did a presentation at Drupal Camp Wisconsin this past summer about module building best practice which did not show any lines of code, but instead focused on testing, security, documentation, and community. I also put in a session for Paris, which did not get accepted, about similar things.

I recently went to the very informative Continuous Integration presentation in Paris. At that presentation there were a number of people that asked how long it took to setup the environment and the presenters had a number for it; but when I asked how much time it saved, there was no answer, not even the ability to estimate. And with some recent discussions I am having with some very respected people, I am unable to quantify the value of process.

I feel like its really hard to get metrics on how processes and methods really do make for better software. I feel like my heart is in the right place, but it seems so tough to be able to convince people that certain processes hold so much benefit over just having something work. So, how do we put specific value on these sort of things:

Documentation
Security
Automated Testing
Methodology (like Agile)
Open Source
Peer Review
Drupal Core Issue Queue
Coding Standards

It seems to be if people don't value these things, they don't do them. How can I convince people that these things are just as important as elegant code or the fact that it works (for now)?

Add new comment

4 comments

Drew Gorton wrote 23 weeks 6 days ago

Convince? Not Sure...

In my experience, high quality process and attention to detail pays back oodles of benefits that you can't always anticipate - which makes it very hard to quantify those benefits up front. So - I don't really have advice on how to convince others that quality is worth it - it may be that someone has either learned that lesson in life already or they haven't.

I also think that implementing a particular, specific process or methodology may not be as important as the conversations and thought that goes into making a decision and following it through to implementation. Processes are good when they make it easy for people to do their best work - and perhaps the implementation of any process that forces steps and attention to details is what makes the magic of high-quality returns.

In the end, it may amount to mindfulness and attention to the now; being aware of what you are doing at all times and continuing to push yourself to do better --- while listening/looking to the insights of others along the way.

But - as to convincing others that this is the right way to live/work/be - that's tricky. You may get further with sharing your end-results and then talking about how you got there rather than trying to convince up-front.

zzolo wrote 23 weeks 6 days ago

Where's the research?

Drew, thanks for the good thoughts. I agree, I don't think its important or wise to get caught up in the details of the methods or processes. I am very grateful for this nugget: "perhaps the implementation of any process that forces steps and attention to details is what makes the magic of high-quality returns."

I think my problem is that I don't personally have all that much experience to be able to tell my own stories and start to define my own cost-benefit analysis, because I am not able to convince my employers, partners, co-workers, even friends. Overall, I also just think it's really hard. And that's why I posed this as a question because I am not sure how to go about defining the benefit of a high-quality process (as you so nicely put it). And I am curious why I have not seen articles or research about this sort of stuff yet.

Wim Mostrey wrote 23 weeks 6 days ago

The value of open source

I think a lot of items on that list spring forth from putting your source in the open. In the case of Drupal when you contribute a module you automatically get peer review which leads to the issue queue and (the request for) documentation, security, automated testing and coding standards. The only thing that's then missing and up to the developer is a methodology.

zzolo wrote 23 weeks 6 days ago

I can't agree

Wim, thanks for the response. I agree with your point that open source helps bring about awareness of these things, but I don't think it necessarily creates a culture that values them. If you look at Drupal Core, all these processes and methods are in there, but if you look at contrib, it's really not the case. Most modules don't have documentation, tests, active response in the issue queue, coding standards implemented, and most modules only go through a security review when the security team comes by. And I bet you will find plenty of unanswered requests for these things, or just not even asked for. Peer review requires the peers to value these things as well.

I love open source so much, but I love the open part more than the source part. To me the idea of being open is much more than just offering your source code to the few people that care to look at it. I think being able to look at code opens up a huge door, but it does not re-enforce these sorts of values. In fact, I might be able to argue it actually hinders these values because it becomes so much just about code instead about producing something complete. There are plenty examples of open source projects that were not successful (though really awesome code) because of the inability to bring all these things together.