Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Software

Open Source Project Management Lessons 296

Posted by timothy from the herding-cats dept.
cpfeifer writes "Paul Baranowski takes a moment to reflect on Open Source Project Management in his blog. His reflections are based on the first two years of the Peek-a-booty project." Interesting comments on media coverage, choice of programming language, when to release a project, and more.
This discussion has been archived. No new comments can be posted.

Open Source Project Management Lessons More

Open Source Project Management Lessons

Comments Filter:

  • Article text (Score:2, Informative)

    by frieked ( 187664 ) *
    Story was just released to subscribers and already it's loading slow so here's the article text for when the inevitable /. effect comes:

    Peekabooty - Lessons Learned

    By Paul Baranowski (paul@paulbaranowski.org)

    July 1st 2003

    Here is a review of the first two years of the Peekabooty Project. Over that time I have had to re-evaluate many of the things I learned in university and in the working world - many of the engineering lessons that I had been taught turned out not to work so well. The project managem

    • Re:Article text (Score:5, Interesting)

      by quasi_steller ( 539538 ) <Benjamin,Cutler&gmail,com> on Wednesday July 02, 2003 @03:08PM (#6352600)
      There are no standard libraries for C++, so there's a lot of reinventing the wheel. (Yeah, there's the STL and others, but each one has a huge learning curve associated with it).

      Well, there is the STL and the Standard C++ library. These are not really hard to learn; it is just that they are both fairly new. The Standard C++ library and STL didn't become standard until around 1998 when the ISO C++ standard was formed. Because that is only 5 years ago, and C++ is much older than 5 years, there are still a lot of books and courses floating around that don't teach Standard C++. When you learn "Visual C++," or whatever, from an older book (or bad book) then it seems that the STL is hard because you are not use to templates and all that stuff (mostly because many older compilers are broken, ie VC++ 6.0, and don't support the standard).

      If you learned STL and the Standard library when you first learned C++ then maybe they wouldn't seem so difficult. Also, many people who first learn programming in a language such as Pascal, like me! :), have difficulties learning generic programming because they are so used to thinking about what types your variables are. Templates and generic programming are very powerful, if you are willing to spend the time learning how to use them.

      • Re:Article text (Score:3, Interesting)

        by pVoid ( 607584 )
        I agree.

        Who among us is soooo old that STL is new??

        I hate these self-prophets roaming around the IT world. They are part of the fucking reason we had the dot-com crash. And they will continue to hamper the industry.

        Fucking let everyone code in whatever they want man... Just stop trying to convince everyone that your own point of view is the best point of view.

        I use C++ most of the time, but I don't cower at using fast throwaway stuff like the odd perl CGI script, or some ASP. Everything has its pla

    • Re: Documentation! (Score:3, Insightful)

      by alexjc ( 684852 )
      So, after two years he still hasn't realized the importance of documentation?

      "Document it and they will come."

      A good project is nothing without it...

  • Great, I would love to read all about it (Score:4, Insightful)

    by mao che minh ( 611166 ) * on Wednesday July 02, 2003 @02:39PM (#6352348) Journal
    I would love to read the article, but my employer uses a proxy filter program that filters out sites with the term "proxy avoidance" in it's META tags (or otherwise prominently displayed within the header). If you are going to run a site dedicated to the development of software that allows one to avoid detection systems and firewalls, then how about making the distribution source (the website) not so obvious and vocal about it's intentions.

    Just a suggestion.

  • I bet... (Score:5, Funny)

    by macshune ( 628296 ) on Wednesday July 02, 2003 @02:39PM (#6352351) Journal
    The peek-a-booty project is a lot less interesting than I would imagine...

  • Project management Lessons (Score:5, Interesting)

    by stanmann ( 602645 ) on Wednesday July 02, 2003 @02:42PM (#6352374) Journal
    Is Open source project management really that much different from any other project management?

    don't release before it does something useful

    This is a rule in "traditional" project management too.

    and the other lessons read just like Project Management 101 too. I would have loved to have seen something insightful or interesting about how open source changes the development environment or the management environment from single location to distributed, but no such luck.

    • Re:Project management Lessons (Score:4, Informative)

      by mmcshane ( 155414 ) on Wednesday July 02, 2003 @03:13PM (#6352641)
      . . . and the other lessons read just like Project Management 101 too.
      Good point. Not surprising, I suppose.

      If you're interested in Open Source project management you might find some of these Mozilla lessons learned [www.iol.ie] interesting.
    • The reason he brings it up is that it goes against the other Open Source mantra of 'Release early, release often'.

      I guess the combined mantra would become

      "Realease as soon as it does something useful, release again as soon as it does somthing better/more than it did before". But that just dosn't have the same ring to it.
    • Is Open source project management really that much different from any other project management?

      I think the answer is "yes", because you have a much different set of motivations (paycheck vs. fun and fame) and resources available (volunteers vs. "professional" sales/marketing). There are some things which are similar, of course. Maybe there's something to be learned by studying project management at other volunteer organizations.
    • and the other lessons read just like Project Management 101 too. I would have loved to have seen something insightful or interesting about how open source changes the development environment or the management environment from single location to distributed, but no such luck.

      I was in the same boat. It was a decent read, but it had the feeling of "Doctor it hurts when I do this" all over it.

      Still makes me wonder how many people will be influenced by it. If so, then great. Maybe Freshmeat will stop getti
  • I got an A writing about this in my political science foreign policy class. Basically delt with social uprising against government blanket censorship (so it was mainly talking about Russia and China). And of course the economic impact of the fall of communism and the introduction of western capitalism.

    Anyways, this project has made me think that there's still hope for everyone to be able to have freedom one way or another.

    I think the only thing about peek-a-booty was that people were afraid it would o

    • I think the only thing about peek-a-booty was that people were afraid it would open a pedophilia flood gate. This really pissed me off as obviously the juornalists behind these stories hadn't actually taken the time to investigate the actual software.

      I don't understand why this would "piss you off." Any sort of p2p anonymizing software is bound to be exploited not only by political dissidents but by pedophiles and anyone else with an agenda that is reviled in the mainstream. Is there any specific mention

  • OK, fine. But what is? It does no good to make a statement like that unless you back it up with an alternative.

    Personally, I dig Common Lisp [alu.org].

    • Actually, I'd like to know what other projects are using. I think that some of the fustration with C/C++/Java also springs from the fact that this is a Windows development effort. I used C++ on Windows for a few projects and it -- is -- a -- bear. Doing any of this type of development for Unix/Linux or cross platform support I think changes the rules.

      Not mentioned is the final langauge they used. Is the code in C/C++?

      I do agree with the binary protocols vs. text protocols, but I'm not sure that is a r

    • Well, I rather disagree with him on this point... particularly regarding C++.

      There is, indeed, a standard library for C++, one which is widely supported - STL. Is there a learning curve? Sure. And you're going to tell me that there isn't a learning curve for any other language, library, or whatever? Please.

      I started at my current job a bit over 15 months ago. I knew only the basics of C++, and nothing at all about the STL (or even templates). It took me about a week to be comfortable using the STL, and I

      • Re:"C/C++ is no longer a viable development langua (Score:5, Interesting)

        by Cereal Box ( 4286 ) on Wednesday July 02, 2003 @03:29PM (#6352757)
        There is, indeed, a standard library for C++, one which is widely supported - STL.

        I don't think that's what he meant by a "standard library". He's thinking along the lines of Java's standard library -- a standard library that gives you graphics classes, networking classes, XML parser classes, GUI classes, etc. You know, the kind of stuff that would be convenient to have bundled with a language. STL is a standard library full of basic data types like linked lists and hash tables. Big whoop.

        • convienient (Score:3, Insightful)

          by pyrrho ( 167252 )
          no, I don't think bundling that is particularly convienient... indeed, I think that it's more convienient to have a choice and not have things like that tied tightly to the language.

          Right now there are well established libraries in C++ for anything you get from standard libraries that are tightly integrated... just with multiple competing established libraries. A wealth of choices.

          There is no standard GUI library that ships with all compilers. That will come, but not before it's time. Java gives such a
          • Ah the timeless "but there's no choice in a standard!" argument. I'd say Java's standard library is very advantageous. The beauty of it is that you can take Java sources and provided you are working with a compatible SDK/compiler version, it'll "just work". if the library is available for all compliant implementations/platforms. With C++'s "competing libraries" on the other hand, you don't have any guarantees with respect to the abilities of the libraries or that the libraries will be available for the

    • Re:"C/C++ is no longer a viable development langua (Score:5, Insightful)

      by Arandir ( 19206 ) on Wednesday July 02, 2003 @03:07PM (#6352594) Homepage Journal
      C and C++ are most certainly viable development languages. Let's see now: Linux, BSD, GNOME, KDE, Apache, Mozilla. Even Perl, Python and Ruby are written in C or C++. But maybe the author is saying those projects aren't viable...

      Use the right language for the job. If all you're doing is interfacing to a database, then a scripting language may be the most appropriate. But if you're writing system software, then by all means stick with C and C++ with some shell glue.

      Compiled languages are damned convenient to the user. "Here's an executable, just run it", versus, "here's a script, go download compile and install the interpreter first, making sure it's the correct version, set up your environment variables correctly, then run the script."
      • Compiled languages are damned convenient to the user. "Here's an executable, just run it", versus, "here's a script, go download compile and install the interpreter first, making sure it's the correct version, set up your environment variables correctly, then run the script."

        Amen. When I'm trying to solve a problem, I like using high-level languages like Perl or Python. But when I need to write an application that I want ordinary users to be able to download and _just use_, I don't have a choice - I hav
      • You over simplified. As he said, static bindings are both a blessing and a curse.

        For example: Oops, sorry. Mozilla on Linux is now being compiled with gcc3.2 so you'll have to get the source and recompile to run on that older (gcc2) system... Also, your old plugins will need to be recompiled before you can use them with Mozilla on the new system - if you can find the source.

        Compare and contrast:
        Java - install the compatibility VM; use the same binary on all platforms
        C - no VM; compile and distribute di

        • Re:"C/C++ is no longer a viable development langua (Score:4, Interesting)

          by Arandir ( 19206 ) on Wednesday July 02, 2003 @05:56PM (#6354138) Homepage Journal
          Java - install the compatibility VM; use the same binary on all platforms

          I'm laughing so hard Dr. Pepper is spewing out my nose! Let me wipe off my screen...

          Trying to get Java applications to work on my Solaris workstation is a nightmare. I can't understand it because the company that makes Java makes Solaris. I try to figure out what the problem is, and hidden way deep in the README is this thing that says I need to install a different version than what Sun provided with Solaris. I fix that and it still doesn't work. Looking deeper into the problem, I see that I need a couple of other components that didn't come with the application. After about two hours of searching for the "myleetclasses.jar" and "ubercoolstuff.jar" files, I put them in a directory, fiddle with the CLASSPATH variable, and finally get the program up and running. And then it crashes five seconds later.

          you either have to manage binary chaos or you have to start distributing your code as source.

          Binary chaos is a pain. A royal pain. So I distribute my code as source instead. Easy. Painless. Users that don't want to compile can grab a prebuilt package from their distro or another repository.

          Of course, I'm writing Open Source, and not cheesy shareware. Perhaps that's the true niche for Java and .NET...
    • What are your thoughts on using straight C?

      He disparages both C++ and Java as open source development languages, and I agree with his comments on those.

      But, besides the compile time issue, straight C seems to me like a good bet. It's such a basic programming language, that it'd be hard to find anyone who programs that doesn't understand the C language. The basic libraries are very standardized. Good debuggers exist. Etc. Etc. Etc.

      Any thoughts?

      • It's not hard to pick up C, or be able to read a C program.

        It IS hard to write a large slab of C code that works, is relatively bug-free, easy to maintain, easy to add features to, and easy to 'understand'.

        This is why starting a large-scale program in something like Python, and just rewriting the bits you need in C (for speed), is a GOOD idea. Thankfully, languages like Python make this easy.
      • C is a must when performance is of big importance. If the program structure and APIs within the program modules are designed properly and in a clean way, I don't think it is much more difficult to maintain and improve on the code.

        A "mixed" C/C++ approach is probably worthwhile using when the program has extensive GUI requirements and performance is still top requirement. Use C++ for the GUI (qt, wxWindows or whatever gui library you like) but for the performance critical parts and the algorithms that are i

      • He disparages both C++ and Java as open source development languages, and I agree with his comments on those.

        I don't -- at least not his comments concerning Java.

        At one time (before they were bundled) people had to download a web browser if they wanted to view a website. I don't recall any webmasters who felt that they shouldn't work in HTML because people had to go and download a browser in order to view it.

        Every software project has prerequisites. Some projects require external libraries, others re

    • OK, fine. But what is? It does no good to make a statement like that unless you back it up with an alternative.

      Well, not only this, but also he says in the FAQ for the project: [peek-a-booty.org]

      * I would like to help develop Peekabooty.

      You should be good with C++ which includes having a knowledge of pthreads, the Standard Template Library (STL), and templates. A heathly knowledge of design patterns is also helpful. To download the source code click here.

      Contradictory ? Yes. To make it even funnier, his proje


    • It does no good to make a statement like that

      Yes, it does some good.

      The first step in finding or creating a better alternative is to clearly define exactly how the current language is bad.

      Having suffered for years under C and C++, I've lately becomed enamored with Python. I believe it solves a lot of the problems he describes.

    • I work at Oracle. C++ is banned here. Apparently, Oracle software runs on more platforms than there are C++ compilers for. Therefore, C++ is a strict no-no. The internal C coding standards doc reads somewhat like this:
      1. Don't write C++.
      2. If you've already written C++, rewrite in C.
      :-)

      So it's either C, or Java (lately). Anything else is considered as scripting (Perl, Shell, SQL).

    • I very much agree with him: C/C++ are no longer viable for rapid development.

      Personally, I prefer Ruby [ruby-lang.org], but Python is almost as good of a choice. ( ;-)

      It's also quite easy to do mixed-language development with Ruby were you write the bits that need to be fast in C/C++ and you write the rest in Ruby (Swig can also help out here). This way you get the best of both worlds. The nice thing about doing this with Ruby is that classes and modules are always open, so a class originally defined in C++ can be exte
      • > Personally, I prefer Ruby

        Ditto. This [ultralog.net] is all driven by Ruby scripts.

        It's really convenient to be able to loop thru a file with something as readable as:

        File.new "data.txt" {|line|
        puts line
        }

        Great stuff, Ruby.

      • Try Common Lisp some time - it is just as open and flexible (you can define and redefine classes, functions and methods at runtime, change the class of an object etc.), only that it additionally has fast compilers (I personally prefer SBCL [sourceforge.net]), so you don't have to resort to C just for speed (of course you still can interface with C libraries - and the best thing is that you can write this interface itself completly in Lisp, with all the instant testability and redefinability).

        OK, enough language advocacy ;-

  • fascinating (Score:4, Interesting)

    by Fux the Pengiun ( 686240 ) on Wednesday July 02, 2003 @02:46PM (#6352406)
    This is a great entry, with some really good insights.

    I first heard about this project from a BBC Article [bbc.co.uk] where they describe it as a "browser free from censorship or outmoded intellectual property laws," which is something I think we can all get behind! However, they made the point that the project could have been better named.

    It seems the author has picked up on that now, too. I think most telling is this passage from the author's blog (weblog) [peek-a-booty.org]:
    Be careful when naming your project. It's difficult for IT managers to convice PHB's that this project is useful for their enterprise class systems with a name like "peakabooty." This sort of nomenclature is detrimental to the future of GPL/Linux

    Hopefully, he'll take these insights to heart!

  • I think not (Score:4, Insightful)

    by The Bungi ( 221687 ) <thebungi@gmail.com> on Wednesday July 02, 2003 @02:48PM (#6352424) Homepage
    While saying that C/C++ are not "viable" languages any more (and making the classic mistake of bunching them into a single blob), he muses that:

    It requires compilation - as your code grows larger, the wait time to see if your code works increases. This delay directly affects how fast your code is developed.
    It's really, really, really hard for people to learn it, and this directly impacts the number of developers you will have on an open-source project.
    It uses static binding (Isn't that supposed to be a good thing?)
    There are no standard libraries for C++, so there's a lot of reinventing the wheel. (Yeah, there's the STL and others, but each one has a huge learning curve associated with it).

    So, basically, it has to be compiled (duh). It's hard to learn (no, it's hard to use correctly) and it has no libraries... eh?

    I'm sorry, but this guy is not a software developer. The usual comments about "X is the One True Language" notwithstanding, I can't follow that because he thinks it's "too hard" and he thinks it's "not viable" and decides that it simply isn't a good fit for his project, then LanguageX must be dead. Perhaps he'd like to share with us which language his OS is written in. Maybe it's Forth or Scheme. Use the right language/runtime/lib/technology for the job and refrain from saying "X sucks because I don't like it".

    Other than the dubious "this is how you do open source" slant I can't see how this article is even worthy of news.

    • According to his FAQ [peek-a-booty.org] he's using Microsoft Visual C++ for the Windows port. Perhaps that's the problem. :)
    • So, basically, it has to be compiled (duh).

      And on top of this, if your are using most modern compilers, when you make a code change, you only need to recompile the changed parts. Now if you change a header file that everything touches, that could mean a lot more time, but if you are only working on one file, then it will only recompile that file.

      I think this arguement of compilation time is garbage.
      • I agree whole heartedly. And in addition to this, (at least with Java) if you use a modern IDE such as IntelliJ IDEA [intellij.com] then you'll know about compile errors without actually having to compile thanks to tools such as on-the-fly code analysis [intellij.com]. This saves a great deal of time for the developer and helps break the 'write a few lines, compile, write a few line, compile' cycle.

    • Re:I think not (Score:5, Insightful)

      by GlassHeart ( 579618 ) on Wednesday July 02, 2003 @03:46PM (#6352882) Journal
      A few other points in defense of older languages:
      • An older language has had more lines of code written for it, so its weaknesses are better known, and more likely published.
      • An older language tends to have more developers, which means any random volunteer is more likely to know it already.
      • An older language has already fought "battles" for survival, and has been squeezed out of applications for which it is ill-suited, and continues to exist for a good Darwinian reason.
      • An older language is more likely to be standardized, and more widely ported.
      Let's take C, for example. An experienced C programmer will point you towards two or three books like van der Linden's "Expert C Programming: Deep C Secrets", or Koenig's "C Traps and Pitfalls". C is rarely used for GUI application development, but still widely used in embedded systems where space and speed are important. C is an ISO Standard, which is important for portability.

      One mistake that many people make is to dismiss older languages when a new one appears with all the old features and then some. The old language does not become any less viable the day a new one comes out than the day before. That is, if a project will take you 6 months in C, it'll still take 6 months even after Java (which might cut it down to 5) comes out. The question is whether the unique costs of using Java instead justifies the 1 month saved, not whether C is still "viable".

  • Interface is Everything (Score:4, Insightful)

    by Snot Locker ( 252477 ) * on Wednesday July 02, 2003 @02:50PM (#6352443)
    Often time this principle applies to people on the project, not just the software being developed. I've learned from experience that really sharp people with a broken user interface can destroy a project!! You have to try to minimize interaction points with folks like that and find where they can excel and use their talents without creating problems for the others on the team. A difficult nut to crack at times and a far more critical factor to project success that the programming language, source management tools, etc...
  • Most of this seems pretty basic to me. I wonder what he was doing in "university and in the working world" that didn't teach him these things.

    And I really wonder what language he suggests. If not C/C++/Java, then what? VB?

    I wish he had spent a little longer on this. I realize it's just a blog, but it would be nice to see some insight into OSS management vs. the alternatives.

    • Re:He wants Visual Basic? (Score:3, Interesting)

      by cr0sh ( 43134 )
      Yeah - and?

      Think about it - an open-source project of any large size requires more than a handful of developers. There are only a finite number of developers on the planet, and only a subset of those are willing to work on open-source projects. Now, of those, how many do you think have a) free time to devote to an open source project (which also may mean that they aren't contributing to other projects), and b) can work in the language being used, or pick it up quickly?

      I can guarantee you that subset is rath

  • Compilation time bounds productivity? (Score:5, Funny)

    by BreadMan ( 178060 ) on Wednesday July 02, 2003 @02:51PM (#6352451)

    It requires compilation - as your code grows larger, the wait time to see if your code works increases.

    Everyone knows that once your code compiles, it will work!
    • "Gee, I don't know if this code I just wrote will work or not. But it takes too much time to compile it under C++. So I'll just use this interpreted weakly typed language and hope it can read my mind to find out what I want it to do."
      • You do realize that C++ is weakly typed, whereas languages like Python or Lisp are not, do you?

        Hint: "Weak" is not the same as "dynamic".

        • This C++ is a weakly typed language is bullshit. I get far more type errors in Python (which I love, btw) than in C++. Dynamic typing is both a blessing and a curse, as is static typing. Now the Java-heads like to say that C++ is a weakly typed language because it lets your do unsafe casts. Well of course it lets you do unsafe casts! How else would you write kernels in C++ if it didn't? The point is that you don't have to use unsafe casts in regular programming.

          PS> I have a feeling most of the "wealky t

  • Repeating the same old misinformation (Score:5, Insightful)

    by h_jurvanen ( 161929 ) on Wednesday July 02, 2003 @02:54PM (#6352484)
    There are no standard libraries for C++, so there?s a lot of reinventing the wheel. (Yeah, there?s the STL and others, but each one has a huge learning curve associated with it).

    This is a huge error that casts doubt on the author's credibility. What is commonly known as the STL is the C++ standard library, and it has been since C++ became an ISO standard in 1998. Doubters may consult books like the clearly-named "The C++ Standard Library" (Josuttis, 1999) to get themselves up-to-date.

    Maybe that's just another drawback of C++... a lot of people don't know what the hell they are talking about and thus repeat misinformation?
    • Well, great, go for it and write your own Peek-a-booty in the language of your choice. The author merely stated that STL C++ wasn't for him and in fact was a barrier-of-entry to new people to the project whom he wanted up and running quickly so that they could become active contributers.
    • Sounds like he hasn't programmed in C++ for quite some time that's for sure. I was away in java land for a few years and then came back, low and behold, all the STL stuff was standard now. Hurray!

      Another doubt casting problem is that he never mentions what a suitable substitution to C and C++ is... He says java is good for the server side, but you can't replace all C++ apps with server side Java. So if "C/C++" isn't viable, what is?

      And he seems to consider C and C++ almost the same language which they

    • Modern C++ is a wonderful language, at least I think so. But it is much different than the "old" C++, almost to the point of being a different language. So if you've had bad experiences with C++ in the past, perhaps you should give it another look. And C++ is not dead, there are a lot of interesting advancements in the language, and more properly how to use it. There are a whole lot of generic programming and template patterns which are comming out which show that C++ has a lot more power than people ev

    • irony (Score:2, Insightful)

      by pyrrho ( 167252 )
      So much of what is said about C++ here on slashdot looks to me to be fear, uncertainty and doubt I find it ironic.

      The complaints about C++ are the kind of complaints users make about linux when comparing it to Windows. "It's much easier to click on a big E than to learn another icon..."

      And clearly he's talking about GUI libraries... instead of multiple good C++ and C based multi-platform GUI libraries, he prefers another model, more like javas, where you get one crappy library and save yourself a lot of

  • An excerpt (Score:5, Funny)

    by Call Me Black Cloud ( 616282 ) on Wednesday July 02, 2003 @02:58PM (#6352519)
    June 14, 2003

    Dear diary,

    I have decided to record my thoughts on managing the project "peek-a-booty". The most important lesson I've learned is not to use booty in a project name!

    Sure, it was funny two years ago after a few beers, but I swear the next person that makes a "booty" joke will die. I'm serious. "Dude, is it for peeking up skirts?" "Hey, if you integrate telephony you can call it 'peek-a-booty-call'"

    In other news, I'm starting a new project to manipulate network traffic, this time using Java. I'm thinking of calling it 'jAck Off'. I like the sound of that. It will be good to get that whole 'booty' thing behind me...

  • Duh (Score:5, Interesting)

    by apankrat ( 314147 ) on Wednesday July 02, 2003 @03:16PM (#6352654) Homepage
    C/C++ is no longer a viable development language

    Sure, in the scope of this particular project and in the context of their skillset and development practices.

    Don't Use Binary Protocols for Application Development

    Bah, I'm speachless. Yeah, right. Better yet convert data to PNG images and pass those along - it will allow you to debug networking layer with a web browser ... Ever heard of protocol layering or data marshalling ?

    With all due respect, it looks like Mr.Baranowski either learnt wrong lessons or likes to summarize things beyond reasonable limits.

    • Well, seems to me that SMTP, NNTP, HTTP, etc are easier to develop for because they are textual.

      HTTP may be just about the ideal balance: use text for things which tend to be small, but capable of sending a large payload (e.g. a PNG image which the protocol just needs to wrap, not do anything with) in binary.

      The thing about protocol layering and/or marshalling is: do you have good debugging tools (at a minimum, log what is going across the wire and be able to interactively enter data and see results)?

    • Re:Duh (Score:3, Insightful)

      by crucini ( 98210 )
      It looks to me like you just haven't yet learned the lessons he learned. Which is fine - most of us can only learn through pain. HTTP, SMTP and friends were widely accepted because they're text-based. This has great implications. You can simulate a client with telnet. You can paste part of a session into email or chat when discussing a bug. When interpreting the complexities of HTTP 1.1 you don't have to perform a second level of mental indirection to translate a header to a numeric constant you're lo

  • What's this guy doing? (Score:3, Informative)

    by JohnwheeleR ( 662355 ) on Wednesday July 02, 2003 @03:18PM (#6352672)
    1. He shouldn't speak so generally by saying things like "C/C++ is no longer a viable development language."
    2. He shouldn't speak so authoritatively having only one OS project under his belt.

    It sounds like he busted his ass on a project no one appreciates because it is generally useless.

    • It sounds like he busted his ass on a project no one appreciates because it is generally useless.

      Sure, it is useless in general. But specifically useful to those living in China that can think for themselves and have a hard time abiding by their government's censorship.
  • they would just call them facts.

    "C/C++ is no longer a viable development language..."

    "not viable development languages for application level work."

    "...It's really, really, really hard for people to learn it."

    "...There are no standard libraries for C++, so there's a lot of reinventing the wheel. (Yeah, there's the STL and others, but each one has a huge learning curve associated with it)."

    So in otherwords it's shocking that the programmer has to know something about the tool, platform, domain, e
    • I agree.

      1. I am shite at coding.

      2. Given a great deal of effort, I produce neat, fast, robust C/C++ code (including UI stuff) that has no memory leaks, buffer overflows, or other problems.

      3. If I can do it, bearing in mind I'm primarily a networks guy, how is C/C++ 'really, really hard for people to learn'?

      The author seems to think that programming should be intuitive, and compile immediately.

      If I can do it, anyone can.

  • surprised (Score:3, Interesting)

    by EZmagz ( 538905 ) on Wednesday July 02, 2003 @03:37PM (#6352812) Homepage
    This quote from the article really surprised me: " C/C++ is no longer a viable development language

    I am not a very active coder, nor will I ever be. Coding is just something that does not come naturally to me. However, I thought that for the most part, C/C++/Java were still the big "players" in the application development world (scripting's a different story). So I would like to know what this fellow suggests for a good language to start projects in?

  • http://goatee.net/2003/07#_02we-a [goatee.net]

    Design By Committee: "...Yes, you understand me correctly, I'm more worried about the size and character of the community than the actual technical issue."

  • What language are (most) all OSes written in? (Score:3, Insightful)

    by jordan ( 17131 ) on Wednesday July 02, 2003 @03:52PM (#6352962) Homepage
    As much respect as I have for the project and its developers, his broad, sweeping statement to the effect of C/C++ is no longer a viable language is really telling of his ignorance and lack of perspective. Which is too bad, since there are other points he makes that are useful lessons.

    To claim the fundamental implementations of all modern OSes (Windows, almost every single UNIX, Linux, and the plethora of other OSes) to be "no longer viable" is way beyond reproach: it's just plain idiotic, and does significant damage to the credibility of his other points.

    Unfortunately, my that-was-ridiculously-stupid meter flew off the scale when I read that point, so I stopped reading right there.

  • Repeat after me: The Interface is Everything (Score:5, Insightful)

    by 2TecTom ( 311314 ) on Wednesday July 02, 2003 @03:54PM (#6352993) Homepage Journal
    As an interface designer and technical writer, this has always been my personal mantra. It's finally nice to see that at least one engineer finally actually gets it!

    You probably won't believe how many MMI designers and technical writers are feeling totally vindicated at this point.

    Really, it's not often one sees history in the making. ;~)

  • 95-5 Rule (Score:5, Insightful)

    by jmacgill ( 547996 ) on Wednesday July 02, 2003 @03:55PM (#6352999) Homepage
    Usually it's the 80-20 rule, but in open source projects it's more like the 95-5 rule. Open source projects are usually run by one or two people doing most of the work. If you decide to lead an open source project, you must be willing and ready to accept this.

    Actualy, if you are about to set out on a new project, its probably best to tell yourself that you are NOT willing and ready to accept this.

    6 years ago I started a project called GeoTools and it was, for the main part, excactly that - two people doing most of the work. This was fine for a few years but over time the user/developer ratio got out of hand.

    Eventualy it became all but impossible for the two lead developers to support 300+ users and although other developers wanted to contribute it became dificult to 'train' new developers as the knowledge of how things worked existed mainly in the heads of only two individuals who had done 95% of the work.

    Two years ago we took the descision to re-design the toolkit from the ground up with as much input from as many people as possible. Since that time we have strived to make sure that as many people as possible have an input into the design process and we keep that process as open as possible by pubishing the IRC sessions in which discussions take place.

    The project now has 9 very active developers who are members of a Project Management Committe and a number of other active contributers as well. The end result is that quiries to mailing lists get responded to far more quickly.

    Getting other people to work on your project is often - TO START WITH - more effort than just doing the work yourself, but the pay off is HUGE, as you then have someone else who can explain things to others.

    If you ever have a contributor who gets stuck or confused and you find yourself thinking 'oh, it will be quicker/easier for me to do this part myself' STOP. Spend the time, help them work out how to do the modification even if it takes a few hours when you could have done it yourself in minutes becuase after you have invested the time in them, they will be able to add things in minutes too, and they can teach others as well.

    If you work on a tight, well defined, non-evolving project then most of my ramblings are probably irelelevent if not they they may be of use. The only danger is in investing time in helping developers who then wander off - it happens, but I tend to find that the more you invest in them, the less likely they are to loose intrest.

    • Re:95-5 Rule (Score:5, Insightful)

      by JamieF ( 16832 ) on Thursday July 03, 2003 @01:09AM (#6356289) Homepage
      Or, you could write some documentation. It's not that hard but for some reason developers avoid it like the plague.

      I keep reading these open source project managers bitching about how hard it is to answer all the emails from users and potential developers. Then you look at their project and see this:
      FAQ: (under construction)
      Documentation: (under construction)
      and if you're really lucky they bothered to archive the developer mailing list, which is just about the least efficient way to document the project. (Yes, let's make every developer read all of our conversations ever, including all of the arguments we had and all of the things we decided to do differently later.)

      It's not that hard; I've done it. You take a day or two and STOP CODING (oh no!) and write some actual words, document APIs, and lo and behold, you realize that you're also white-box testing your code because you were forced to explain what some code does ("hmm, that actually doesn't make any sense" / "oh crap that won't work in this case").

      All of a sudden you can just point people at the docs and add stuff when new questions arise. Sometimes the answers are best expressed as a FAQ, sometimes as part of API docs ("oops, I didn't explain what these constants actually meant"), sometimes as end-user documetnation. But IT'S WORTH IT.

      As for the common self-delusion, "we'll write the documentation after we're done with the code", all I can say is, read any process book there is. You're doing it backwards if you start with implementation and then back into writing down what the system does and how it's designed. Those things come first, THEN you write the code that does it. Otherwise you redesign the product dozens of times as you go, each time slapping yourself on the head and saying "oh crap I forgot it has to do this too" or "argh, I need this value from here but the API doesn't allow that". If you write it all down (which first requires that you *think* about it in detail) then you won't forget your good ideas, you can jump all over the place, you can write test harnesses that make sure the code does what the docs say, and you can point newbies at the docs and say "OK cool you can get started on the email notification part, we haven't touched that yet."

    • Communication!!!!!! (Score:4, Informative)

      by hughk ( 248126 ) on Thursday July 03, 2003 @03:00AM (#6356671) Journal
      Congratulations on a successful project. However, you mentioned what worked without commenting on it:
      Two years ago we took the descision to re-design the toolkit from the ground up with as much input from as many people as possible. Since that time we have strived to make sure that as many people as possible have an input into the design process and we keep that process as open as possible by pubishing the IRC sessions in which discussions take place.
      The moment you involve other people in a project, you need to document and explain design decisions and any discussions arising. By doing this you have made it very easy for other developers to get involved. I also like the way that you publish IRC discussions.

      You are almost a text book example on how to do things right.

  • Not Project Management (Score:5, Insightful)

    by drmofe ( 523606 ) on Wednesday July 02, 2003 @04:04PM (#6353111)

    None of the lessons learned and reported here are directly related to Project Management per se. They are all by and large implementation issues.

    There is also nothing new here. This does not advance the state of the art. History does not advance by people relearning the same lessons again and again. Just because they have been reported here does not make this article special in any way. This article could have been written in any of the decades of 70s, 80s, 90s (substituting en vogue languages for C++/Java) and still make sense.

    In order to truly advance the state of the art, we have to think in far more advanced ways about project management and software development. True Software Practice and Experience requires much more planning and critical thinking than evident here.

    If Open Source is to provide a useful and stable platform on which to build, then we certainly need a better vision of how to build software. Otherwise, we will be doomed to repeat history by implementing old things in different ways and not really gaining any control over complexity.

    In summary, we still have a software crisis; Open Source will not change that; and summaries of software development experience that just say "I made the same mistakes as other people did" are not very helpful.

  • NOT just open source (Score:5, Interesting)

    by Kefaa ( 76147 ) on Wednesday July 02, 2003 @04:23PM (#6353288)
    His point that this is not unique to OSS Projects is a good one. While OSS development has unique constraints most are around people and personality. In an office we all have to get along or get fired, in OSS it can sometimes be worse.

    For example:
    The press loves infighting because it's a good story. However, the infighting story is bad for a project that is trying to get funding. This creates an air of instability. People only like to fund things they feel will have a high chance of success, and instability erodes that confidence.

    It is too bad on so many mailing lists ego/attitude/personality or just plain rudeness show up. Things you would never say to a coworker, make it onto a mailing list for eternity, or at least what looks like one. I hope people take this point to heart before posting.


    95-5 Rule
    Usually it's the 80-20 rule, but in open source projects it's more like the 95-5 rule. Open source projects are usually run by one or two people doing most of the work. If you decide to lead an open source project, you must be willing and ready to accept this.

    Looking at sourceforge I see this lesson again and again. The idea that if I create it they will come, and build. Forgotten, or unknown, is that nearly all had a real need to be built first. I needed application ZAFDE so I built it. I then released it and people thought they could build on it, and so on.

    I wanted to learn C++ or JAVA or XYZ is the reason we have 2,134,931 notepad applications, not OpenOffice.

    C/C++ is no longer a viable development language
    I knew we would see a flamewar as soon as I read it. My thoughts:
    - Both are still viable. Much like his hammer analogy, they are not good for everything.
    - What makes them "bad" for development, makes them "good" after they are developed.
    Does it matter to the user that it took 81 minutes to compile? Nope, they have the binaries or compile it once and run it for years.
    Every language has a shortage of people who know it. Or specifically a shortage of the people who know it and are willing to work on OSS project PDQ.
    Static binding is good/bad/sometimes both. Yes it is.

    All the negatives he spoke of are positives after it is developed. Which we hope is long compared to the time spent developing it.

    If there is one thing projects should take away, it is probably this:
    Interface is Everything ...The program should be fun to work with. There should be buttons and things that blink. The interface should be the first thing you do. The interface serves as inspiration and motivation and helps you to learn how the final product should look. Yes, it's going to change a lot. Yes, it's going to have to be rewritten multiple times. Yes, it will never be good enough...But when someone downloads your program they will have something to do. No one likes to look at command lines.

    I like command lines. I use them, but I understand they are power tools. Most people do not like/use them and consider them an indicator of a poor product. Even while it may not be technically true, perception is reality in this.

  • Windows and WINE only... (Score:3, Interesting)

    by Ashtead ( 654610 ) on Wednesday July 02, 2003 @04:31PM (#6353389) Journal
    I didn't have any problems with reading the site at the time of this posting, but I can see where his headaches with C++ might have come from. The MSVC versions of STL hasn't been around in a standard form for very long, although the MFC library has been. This is most likely the grounds for the complaint. And the MFC does not make for easy portability to native Linux/Unix environments.

    However, designing things in C++ and doing it properly is damn tough; many designs may seem easy to begin with, but then run into trouble with things like multiple inheritance from related parents, or simply that encapsulation is difficult because of the need for exposing the inner workings of classes... STL fixes some of this at the expense of code bloat -- it is easy to produce executables tens of megabytes in size.

    Another problem with C++ which has been bothering me, and I would presume, the developers of Peekabooty, is the tendency towards static compilation and inclusion of everything. I looked at the source files here, and the sheer number of include-files compared to source files indicate that this probably does not compile quickly.

    There is a way around this, if the application can be divided into several major and fairly independent components which then are compiled and linked as a number of dynamical libraries (.DLLs on Windows, .so on Linux and Unix). Now, with proper design, recompiling the whole lot is not necessary for smaller changes within one of the parts where no changes in this part has taken place. The trick here is encapsulation: do not let code in any one part know about any of the internal structure of code in any other part.

  • Similar thoughts as I start a project (Score:3, Informative)

    by harikiri ( 211017 ) on Wednesday July 02, 2003 @07:42PM (#6354833)
    With regards to the C/C++ point and the documentation point in the article...

    I'm working on a project for central user management on a popular network appliance. At present there's only one commercial solution (that I could find/google) available that lets you manage n+1 of these appliances at once.

    I initially looked at the problem and figured, heck I can do it easily with expect and ssh, but then I started thinking about how my employers & co-workers would use it (I contract), and realised a command-line application wouldn't suffice.

    So I started pondering how I could integrate a fairly simple backend (that could be implemented by scripting languages) with a portable interface.

    I could either:

    • a) Put the backend script onto a webserver, and allow administrators to use it via a web browser and CGI.
    • b) Use Python [python.org] and wxPython [wxpython.org] to provide a GUI application that runs on windows/unix/mac.
    • c) Use Tcl/Tk [www.tcl.tk] to provide a GUI application that runs on windows/unix/mac.

    I eventually chose the tcl/tk option, because of the following reasons:

    • 1. A webserver-based application would require ongoing maintenance of either a new server, or speaking with existing server ops to get our stuff onto their boxes. This didn't fit in with timeframe and would be difficult to maintain and distribute updates.
    • 2. wxPython lacks extensive documentation. I'm not going to force myself to join mailing lists and peruse demo code to figure out how it all works.
    • 3. Tcl/Tk is well-tested, instantly portable [www.tcl.tk], and documented up the wazoo [www.tcl.tk].

    So I ended up choosing a well-documented language for implementation, which has the benefits of being portable, interepeted (no compiling), and easily updateable (email the latest script). Sure it isn't the sexiest solution, but it works and is easy for new developers (the project will be open-sourced when ready) to pick up on where its at.

  • Static compilation time (Score:3, Insightful)

    by Per Abrahamsen ( 1397 ) on Friday July 04, 2003 @02:47AM (#6365712) Homepage
    Static compilation time does not grow linearly with project size, unless you either aren't using a dependency tool (like make) or have organized your code to that every module depends on every other module.



    With regard to the first: consider learning thee build tools part of the cost of learning a static compiled language. It is not optional.



    With regard to the second: If you have so many cross-dependicies, you will run into problems in any language as the project grow. A bug solved in one module may cause new bugs to appear in any other module.



    In general, Based on many years experience with C++ and Lisp, I'd recommend compiled and statically typed languages for large projects, because of the discpline they encourage. Interpreted and run-time typed languages are usually superior for small projects.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close