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.

I need to start the design and development of a new framework to interact with an open source ECM. This inludes a customized data model to help web site developers interacting with this ECM, so they don't need to care about the details of nodes manipulation and other low level details. That's just a bunch of classes and methods to develop.

I have some doubts about how to handle the organization and managment of that project: Are there some general rules to follow, tips, best practices or something to keep in mind for developing this kind of project?

I'm sure there are some difference between the development of a framework or library and an application.

share|improve this question
    
Are we to assume ECM means enterprise content management [system]? –  Mark Canlas Feb 3 '12 at 19:58
    
Yes, I'm working with Alfresco –  Andrea Girardi Feb 4 '12 at 0:38
add comment

7 Answers

First here are my 2 rules to avoid framework waste syndrome:

  • The absence of an existing one, covering 80% of my needs and extendable to match the last 20%
  • The near certainty that I will use it again, in another application

After you passed those, check this out:

share|improve this answer
1  
I would add that if you can't find a framework that meets your 80/20 rule either you are working in a extremely unique domain OR you don't understand your domain well enough. –  ElGringoGrande Feb 3 '12 at 19:29
add comment

1) Features should only be added to a Framework when they are extracted from working code. In other words, before adding your cool new idea to your cool new framework, make sure that it actually adds value to and reduces repetition in a working, real world application.

2) Documentation, documentation, documentation.

3) Documentation, documentation, documentation.

share|improve this answer
add comment

Painful experience and a lot of wasted effort lead to this advice: extract or refactor a framework from working software. Build that software keeping in mind that you think you will want to extract a framework in the future, but don't build the framework first.

share|improve this answer
add comment

I would suggest the book Framework Design Guidelines. It's a couple years old, but the principles remain true. It has a ton of patterns and explains the reasoning behind decisions you'll make when building a framework.

share|improve this answer
add comment

I disagree with a lot of what has been said and I feel that more has been left unmentioned so I'll start from scratch.

Agile Methodologies

Adopt agile methodologies during your framework development so that you can adapt to change, react quickly to roadblocks, and ensure a functional, quality final product. Agile methodologies are those that, according to the "Agile Manifesto", prioritize:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That's right. I said functionality is more important than documentation. Note that the "Agile Manifesto" mentions that the right-hand priorities are still important, just less so than those on the left.

Communication

Whoever is making the framework needs to know:

  1. How it will be used: the target application
  2. What problem it is intended to solve: the target problem
  3. Who will be using it: the target audience

For example, if a company were intending to develop a final application with ASP .NET it would be foolish to tell its programmers "make this framework" without telling them the above. If the programmers didn't know the target application they might not make it web-oriented. If they didn't know the problem, they might make a framework for a different purpose. If they didn't know the audience they might program the framework in C++. Any of these circumstances would render the resulting framework useless.

Style

Needless to say, establish a programming style/format and stick with it.

The E's

  1. Modularity: Reuse code programmatically, not literally.
  2. Efficiency: Your code is intended for reuse. Any detriments to speed get multiplied.
  3. Maintainability: You want to be able to edit the framework to update several programs, without having to modify said programs.
  4. Usability: Can applications actually use your framework without jumping through hoops?
  5. Practicality: Don't reinvent the wheel if you don't have to do so. Your framework can depend on other frameworks.
  6. Redundancy: Catch exceptions/errors. Everywhere. Handle them. Everywhere. Never trust any code but that in the local scope to handle errors, even if you know that it does.
share|improve this answer
    
Welcome to P.SE! I'm not I agree w/ #6 on catching exceptions in your framework. I'm a big believer in that the framework should be an absolute brat and throw exceptions and leave it up to the programmer using the framework to catch them or (better yet) reorient their code so as to avoid the exception - encouraging convention conformity. –  Jarrod Nettles Feb 4 '12 at 16:38
add comment

1) Stick to good conventions right from the start, make sure you've documented a very specific convention, the best frameworks are the ones that are internally consistent.

2) Make sure that everything is highly documented, from good code comments all the way through to explaining what the most important functions require and produce, even if it seems super simple to you you might have someone use it on the 14th straight hour and they just need that one thing right then.

3) Set out a project brief for yourself, with what you want the framework to achieve, realistic targets and overall priorities.

4) If it's going to be available for people to use, make sure you've got some form of support process/bug tracking in place. There's going to be bugs, it happens to all of us, but if you can manage them from the off it'll make your life easier.

All in all, similar approach to building any application, but developers are even fussier than users, and the best frameworks are the ones that we can pick up, make sense of, and we don't have to fight.

share|improve this answer
add comment

I'm sure there are some difference between the development of a framework or library and an application.

Development processes are essentially the same. The differences may come down to marketing and deployment issues, although I find that the biggest differences are usually in terms of project scope and definition. Remember that an Application may include or use a framework or a library, a framework may be a collection of libraries.

I have some doubts about how to handle the organization and managment of that project: Are there some general rules to follow, tips, best practices or something to keep in mind for developing this kind of project?

Project organization and management are again the same for any development project. Again it comes down to scope. When it comes to writing a framework however, it pays to have a very clear vision about what it is you are trying to achieve, and to place strict design rules on the public interface to the framework to ensure consistency in terms of the API's presentation. If you allow every developer to do their own thing, you'll end up with a complicated mess, and a very inelegant API design.

I'll second Ryan Hayes' recommendation to read Framework Design Guidelines even though the book itself is aimed at developing .NET based frameworks, because the general advice is applicable regardless of the specific implementation technologies that you might choose to use.

From experience, I would advise sticking to the classic YAGNI principle by implementing the most simplistic public interfaces first, and then expanding to offer greater control and depth later on, but be careful to use useful names to show why methods or classes are being expanded. I've never been a fan of adding "Ex" or other similar suffixes to method names, or adding numbers to expanded Interface definitions. Differentiate on functionality, and your interface/method names should become clearer, and hopefully less obfuscated and confusing.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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