Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

After reading http://stackoverflow.com/questions/2326609/how-to-organize-matlab-cod, I had a follow up question.

If you work in a group of MATLAB programmers, who enforces the organization of the shared MATLAB code and project matfiles? For example do you have a dedicated MATLAB IT person, or does the most senior programmer issue guidelines that everyone must follow, or does everyone agree to follow a system? In my small group, each person has their own 'system'. MATLAB code and project matfiles are either piled into a shared drive or tucked away on people's own computers. Hard to recreate work done by another person, or even to locate their code. There were lots of good suggestions on how to get organized. But it seems like someone has to make the trains run on time. Who does it in your group?

share

migration rejected from stackoverflow.com Dec 21 '12 at 12:03

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as not constructive by Dynamic, Robert Harvey, Glenn Nelson, gnat, StuperUser Dec 21 '12 at 12:03

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

comments disabled on deleted / locked posts

4 Answers

I have found myself responsible for software development best practice amongst groups of MATLAB users on more than one occasion.

As Zellus correctly points out, MATLAB users are not normally software engineers, but rather technical specialists from some other discipline, be it finance, mathematics, science or engineering. These technical specialists are often extremely valuable to the organisation, and bring significant skill and experience within their own domain of expertise.

Since their focus is on solving problems in their own particular domain, they quite rightly neither have the time nor the natural inclination to concern themselves with software development best practices. Many may well consider "software engineer" to be a derogatory term. :-)

(In fact, even thinking of MATLAB as a programming language can be somewhat unhelpful; I consider it to be primarily a data analysis & prototyping environment, competing more against Excel+VBA rather than C and C++).

I believe that tact, diplomacy and stamina are required when introducing software engineering best practices to MATLAB users; I feel that you have to entice people into a more organised way of working rather than forcing them into it. Deploying plenty of enthusiasm and evangelism also helps, but I do not think that one can expect the level of buy-in that you would get from a professional programming team. Conflict within the team is definitely counterproductive, and can lead to people digging their heels in. I do not believe it advisable to create a "code quality police" enforcer unless the vast majority of the team buys-in to the idea. In a team of typical MATLAB users, this is unlikely.

Perhaps the most important factor in promoting cultural change is to keep the level of engagement high over an extended time period: If you give up, people will quickly revert to follow the path of least resistance.

Here are some practical ideas:

Repository: If it does not already exist, set up the source file repository and organise it so that the intent to re-use software is manifest in it's structure. Try to keep folders for cross-cutting concerns at a shallower level in the source tree than folders for specific "products". Have a top-level libraries folder, and try to discourage per-user folders. The structure of the repository needs to have a rationale, and to be documented.

I have also found it helpful to keep the use of the repository as simple as possible and to discourage the use of branching and merging. I have generally used SVN+TortoiseSVN in the past, which most people get used to fairly quickly after a little bit of hand-holding.

I have found that sufficiently useful & easy-to-understand libraries can be very effective at enticing your colleagues into using the repository on a regular basis. In particular, data-file-reading libraries can be particularly effective at this, especially if there is no other easy way to import a dataset of interest into MATLAB. Visualisation libraries can also be effective, as the presence of pretty graphics can add a "buzz" that most APIs lack.

Coding Standards On more than one occasion I have worked with (otherwise highly intelligent and capable) engineers and mathematicians who appear to have inherited their programming style from studying "Numerical Recipes in C", and therefore believe that single-letter variables are de rigueur, and that comments and vertical whitespace are strictly optional. It can be hard to change old habits, but it can be done.

If people are modifying existing functions or classes, they will tend to copy the style that they find there. It is therefore important to make sure that source files that you commit to the repository are shining examples of neatness, full of helpful documentation, comments and meaningful variable names. This is particularly important if your colleagues will be extending or modifying your source files. Your colleagues will have a higher chance of picking up good habits from your source files if your make demo applications to illustrate how to use your libraries.

Development Methodologies It is harder to encourage people to follow a particular development methodology than it is to get them to use a repository and to improve their coding style; Methodologies like Scrum presuppose a highly social, highly interactive way of working. Teams of MATLAB users are often teams of experts, who are used to (and expect to continue) working alone for extended periods of time on difficult problems.

Apart from daily stand-up meetings, I have had little success in encouraging the use of "Agile" methodologies in teams of MATLAB users; most people just do not "get" the ideas behind test-driven development, development automation & continuous integration. In particular, the highly structured interaction with the "business" that Scrum espouses is a difficult concept to generate interest in, even though some of the more serious problems that I have experienced in various organisations could have been mitigated with a little bit of organisation in the lines of communcation.

Administration Most of what constitutes "good programming practice" is simply a matter of good administration & organisation. It might be helpful to consider framing solutions as "administrative" and "managerial" in nature, rather than as "software engineering best practice".

share
1  
Wow, what a fabulous reply. Lots of information and also understanding of the Matlab user "independent" culture. Can I go out on a limb and suggest that if you had the inclination and time it would be a great video tour (YouTube) or recorded Webinar that I for one would love to watch? Would be illuminating to see an example of good project organization. Or, if you know of an existing resource for further learning, please let me know. Either way thanks for the reply. –  KE. May 17 '11 at 13:37
    
Excellent answer. –  Will Dec 29 '13 at 2:01
add comment

The first thing you need is a version control system - to make sure code is backed up, to help figuring out where a bug came from, and for people to know where to look when they don't want to re-implement something they know has been done by the group. There should be a /common folder for tools and utility that are generally useful, as well as an /extern folder for all the stuff downloaded from the internet (so you always know what part of your code is yours, and what part is someone else's). Then you can have a folder either per person or per project (if multiple people work on the same project and share code), or both.

In addition, there should be a standardized format for documentation to make it easier to quickly figure out what a function does. This can be achieved e.g. by having a user-defined script for creating new functions (see the answers to this SO question for solutions, as well as this question).

For coding style inside the function, there are plenty of guidelines out there, but this is probably the one thing that should be decided by the group rather than being mandated from above; basically you need to find something everyone is ok with.

Finally, you need someone to enforce this. This is ideally the boss but it can be a senior developer, or a dedicated IT person - basically you need someone people listen to, and they'll listen better if that person has some authority.

share
1  
Depending on how large your team is, you're going to have someone who disagrees with the coding style and throws a wrench in things by checking in code that doesn't conform. This can be solved with a version control system that enforces basic code style -- or in extreme cases, by firing them. The person who enforces the things that Jonas listed really needs to have the power to fire people to make things effective. –  Jon Bringhurst Feb 4 '11 at 15:49
add comment

MATLAB is often used by people not defining themselves as 'Software Engineers'. In consequence they neglect most recommended practices established in the field of 'Software Engineering'.

Getting everybody on the 'Software Engineering' train is a matter of soft skills and power. Without the support of the management, granting money and time for training, as well as giving power to a lead person in order to enforce compliance to the agreed practices, people will stay with their adopted procedures.

share
    
The problem is, none of us wants this power. The 'reward' would be spending time on developing, implementing, and enforcing an organization system, at the expense of our official job function which is solving engineering problems. –  KE. Feb 4 '11 at 16:04
    
Often there will be no solution to engineering problems without good software tools at hand. Or people end up solving the same issue again and again. As long as engineers don't consider 'Software Engineering' as part of their business, they are lost. –  zellus Feb 4 '11 at 16:42
    
True. One possibility is that we could hire a consultant to design and set up the organization tasks that Jonas listed. What would this person's title be in a job posting? Matlab software engineer? Sorry to ask such a basic question. –  KE. Feb 4 '11 at 18:08
    
@KE01: Whoever is responsible for the output you produce should want this power. For a short, single project, it doesn't matter whether you write reusable code or not. However, in the long run you gain a lot in efficiency if you can re-use code, and it takes less time to bring trainees up to speed if code is documented and reasonably uniform in style. Thus, it's really your boss who would want this. –  Jonas Feb 4 '11 at 18:30
1  
@KE01: MATLAB software engineers are a rare species. It might be easier to Look for somebody with good experience in enterprise software development. Usually these people know about version control, bug tracking, unit testing, continuous build and documentation. If you're lucky they already got in contact with MATLAB, otherwise with a strong background in OOP languages they might master MATLAB quickly. Additionally your consultant needs admin capabilities in order to setup the chosen tools in your IT landscape. Finally he needs communication skills in order to get everybody on track. –  zellus Feb 4 '11 at 21:30
show 2 more comments

For large MATLAB projects I've worked on, we've used a combination of source control (Subversion or Team Foundation Server), coding standards, and regular code reviews. Source control is almost mandatory to keep files coordinated between team members, and code review is great for finding bugs and deviations from coding standards.

Generally the project manager arranges the source control server and schedules the code reviews. If you don't have a formal project manager, it's best to designate one of the more managerially-minded programmers as the keeper of the code. I've found that even curmudgeonly engineering types will come to quickly appreciate at least the backup features of source control.

share
    
It sounds like a very functional setup. Good for whoever put it into place. –  KE. Dec 21 '12 at 19:51
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.