Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Slashdot.org

Journal FortKnox's Journal: Slashdot and Professional Web Development 29

Journal by FortKnox
Ever since I read my book, I promised I would try hard not to criticize....

But, as it appears, I'm only human....

I work in the web development industry (as most of you know). I write J2EE web applications. I've done so for a while now.
How we work is this: We all work individually on the project, using source control (mostly clearcase, which is a blessing, but sometimes we have to settle with CVS). Anyway, once we get to a milestone, or fix our critical bugs, we send the entire code to the 'integration' step. In this step we compile everything, and do you 'basic run-through' of the app to ensure that the basic functionality still works. If everything is ok, it gets sent to 'QA' where it is hit with regression testing (mostly scripts) and human testing of the new functionality (or fixed functionality). When it clears QA, the user base is notified that a change in the production server will be made (given plenty of notice), then the change is made when the app is used least (middle-of-the-night).

Is that so odd? Why doesn't slashdot use this basic software lifecycle (most coding houses use this, it isn't a rarity)? Bugs, like making all users post without +1 would be caught in the integration step (if not, it would DEFINATELY be caught in the QA step). And, if it was a more complex of a change and makes it through QA without the bug being caught (yeah, it does happen often), when the users know, they will be on the lookout for it.

Is this just how open source projects work? Since there isn't much rhyme and reason, just developers itching a scratch, does QA and testing just blow out the door, and all changes go through without notification and the assumption is that it won't hurt anything? It that's the case, there is a serious problem here... Or is slashdot simply the testing ground for slashcode?

Addendum: For clarification, we do use RUP for our projects (not waterfall).
This discussion has been archived. No new comments can be posted.

Slashdot and Professional Web Development More

Slashdot and Professional Web Development

Comments Filter:
  • Development on large, collaboratively developed projects can be a free-for-all (although most open-source work isn't done by large collaborations, ESR notwithstanding). My favorite KDE story was the post explaining why some bugfix hadn't been committed: "I'm grounded and I can't use the computer at home."

    But that has nothing to do with how the OSDN admins deploy new code.

    In fairness, though, Slashdot runs far, far better than it did a couple of years ago when it would be unreachable or the database would be down literally every afternoon. What hasn't changed is the unwillingness to provide any information about what's going on.

  • How we work is this: We all work individually on the project, using source control (mostly clearcase, which is a blessing, but sometimes we have to settle with CVS). Anyway, once we get to a milestone, or fix our critical bugs, we send the entire code to the 'integration' step. In this step we compile everything, and do you 'basic run-through' of the app to ensure that the basic functionality still works. If everything is ok, it gets sent to 'QA' where it is hit with regression testing (mostly scripts) and human testing of the new functionality (or fixed functionality). When it clears QA, the user base is notified that a change in the production server will be made (given plenty of notice), then the change is made when the app is used least (middle-of-the-night).

    That sounds like a pretty good process. I was in a dev shop where we did that, but where I'm at now there is no QA process (in fact testing doesn't even get put in the schedule). I think that is true in most dev shops that I call "Level 1's" (per the Capability Maturity Model). They depend on the heroics of the developers. Anyway, I'm just guessing, but I imagine many open source projects work like that. The main reason is because there are no processes that are defined and since that is the case, everyone does their own thing.

    In the case of slashdot, I think the least they could do is have a regression test script that they go through for a couple of use cases. Anything that doesn't come back as "normal" should get red-flagged and looked at especially before going into production. But if there are no processes in place that probably isn't going to happen. The +1 posting thing is a little obscure, so I can understand how it was missed especially given a chaotic level 1 dev shop.
  • I wouldnt say all opensource projects are like this, I'd blame free projects. In cmdrtaco's mind slashdot is still free (since the subscription is just trying to cover hosting costs). He dosnt care if he breaks it, much as I dont care if i break some cgi script i write.

    Although after writing thing, I thought about the win32 gaim builds. I honestly do not think they even run them after they compile them. I came to this conclusion when:

    gaim alpha1: crashed whenever there was a protocal error (sucks when you have 3 or 4 accounts on at once).
    gaim alpha1+2: input buffer gets distorted if you enter multiple lines.
    gaim alpha3: adds a X button on each IM tab to close it--they dont work.
    gaim alpha4: thinks win32 paths are escaping chars, so all your configs get changed so that sounds dont work (it tries to play c:whateverPathToSoundFile)

    So maybe you are right..
    • I wouldnt say all opensource projects are like this, I'd blame free projects. In cmdrtaco's mind slashdot is still free (since the subscription is just trying to cover hosting costs). He dosnt care if he breaks it, much as I dont care if i break some cgi script i write.

      I would definitely agree. Even though CmdrTaco doesn't handle the development so much, the people that do I don't think give a shit. They know they can break it and people will still come. Seriously, we sit here and give them more page views and view more adverts with every break because the entire journal ring posts more.

      They break and benefit. Until a real alternate to slashdot comes up (Don't even bring up k5) there is nothing that is going to change.
  • It comes from being in a more mature environment. When managers and coders have worked in that situation before, they can see the payoff for the bit of pain and process.

    I look at my current employer, a very immature development shop. They don't develop a lot of applications in house. (In fact, I'm the first). I know I don't have a defined test plan or solid release cycle. I'm trying to ease them into the water and then hope that others see what kind of pain the automated testing and release cycles get them.

    My opinion of /. was it started like most things. A couple of guys screwing around with technology and trying to make things work. Until they really start offering pay-only features, I don't think we'll see mature development from /.

  • After the move to the west coast it's also a lot slower for large parts of the day, it's down/behaving very oddly several times a day etc etc. It seems Slashdot staff does the QA and general testing right on the Production boxes.

    I'm not one of the people who constantly whine about Slashdot and Slashdot staff, I think it's a great geek community and I get a lot for free. But, I'd never let a Slashdot staff member run an important project if Slashdot is any indication of how they work, they may be excellent and amazing coders, but Slashdot just isn't run in what I'd call a professional way. There are some obvious flaws that have been pointed out over and over, but yet little happens, and when it does, it's much later. Remember Klercks page widening posts for instance?

    • I hadn't even heard about the +1 stuff, but I don't really use mine very often. There's also some box in users.pl...

      handsomepete (561396)
      handsomepete
      (email removed)
      (email not shown publicly)
      http://trustydefiant.com/
      Karma: Excellent

      What's the point of that anyways? Was having your karma above your post history really that taxing? That's what bugs me about software development - absoultely unnecessary and useless 'additions' adopted in favor of things that need to be fixed. Dechecking 'no karma bonus' to test.
  • Have you ever seen a distribution of slash? It's a mess. This is why people like O'reilly have had to write entire books on installing it and managing it. Then we have the problem that the whole thing is written in messy perl code. (perl r0x0rz!!, etc...) It doesn't scale too well (you don't see eBay or Amazon using perl now do you?)

    I think they need to start from scratch and re-write Slash in a clean, commented, well-documented way in JSP or ASP.NET (that'll never happen).

    Now, I author on another Slash-based site [purdueonline.com]. We have a much smaller userbase, so slash running in mod_perl scales relatively well. But you need to consider that since the "Slashdot effect" exists, their own servers need to handle twice that predicted traffic.

    Also, we're running an older, more stable version of slash - which is part of the problem on Slashdot. Slashdot is bleeding edge slashcode -- i.e., we take upgrades to the next version of slash very carefully and seriously. Slashdot, on the other hand is more of a "hmm, let me change this and see what it does!" shop.

    I mean, if you know jsp / gsp or asp, how hard would it be to write a clean version of slash, and still have it interface with the same MySQL database. (Which I believe is another underlying problem, I'll save that for another story. "But MySQL is great at SELECT's!" they say...)

    P.S. Slashdot is super-slow for me. I usually have to hit Submit twice (it times out otherwise) -- just like I had to now.
  • Unlike the construction industry, tech is extremely immature in terms of process and procedures. My guess is that because the barriers to entry are so low (all you need is a computer, access to free dev tools, and desire), anyone can start coding. This means that even though some shops (like FortKnox's) start figuring it out, new shops crop up all the time and manage to muddle through. The latter spends a lot more for their products than the former.

    Construction projects generally run in the millions, if not billions, of dollars. As a result, there are some procedures that construction companies will absolutely not abandon. For example, x amount of concrete dries in n amount of hours, and this is what you put in your plan. You don't put n-y, just because the boss wants it up faster, unless you want to pay more when the structure collapses or when it fails inspection.

    Why is it that we do this in tech? I think it is because many people can get away with it long enough to think they can work that way forever.

  • It seems to be exactly the same release cycle that we use in our company. You seem to be doing using the Waterfall methodology wherein the developers spend all their time developing features, hit a milestone, then toss the product over the wall to QA who presumably has been writing test specs and scripts based on the product specs. For us, this has been seriously painful.

    First off, it means that QA doesn't get to see anything until Dev decides to release the code. All the scripts and specs in the world can't compete with actual hands-on testing. What generally ends up happening is that some code path is totally messed up or some setting is incorrect and it blows QA's schedule because all the automated tests along that code path must now be either re-written or manually performed.

    Second, bugs don't get fixed. Yes, I know they are supposed to, but project milestones are generally feature milestones and not bug fix milestones. QA reports a ton of bugs, but Dev has already started working on the next milestone's features and puts off fixing the bugs until later in the dev cycle. This ends up throwing the project into a death spiral which only goes to delay the project at the tail end, leading to blown Dev schedules. It is relatively easy to estimate feature implementation, but it is a lot harder to estimate bug fixes.

    Third, it leads to an Us vs. Them mindset in the dev team. QA wants the product to ship on time as much as anyone and they frequently become a little antsy when a Pri 1 Sev 1 bug pops up during a test pass. Dev, under enormous pressure (I've been there, I know) to get the milestone requirements met, can begin to look upon QA as a nuisance and enemy. All the bugs appear at once and the bug counts can be huge, possibly overwhelming, I don't think there's any dispute that someone would feel upset to see their work torn apart and shoved back in their face in this manner.

    Last, it leads to the impression that QA engineers are idle because they aren't testing right now. Managers look at that and decide to fill that free time with multiple projects which then get the same lower quality QA in the process.

    Personally, I prefer the parallel dev/QA cycle where QA gets a new build of the product every day for testing. QA gets to see the code from almost the start leading to better tests and better product suggestions (those low priority, "wouldn't it be nice if" bugs), high priority showstoppers can be found immediately and handled immediately (even if it means backing out the previous day's changes), and since bugs can be kicked out as they are introduced the bugcounts stay low leading to higher morale all around. Obviously this is an exaggeration of the benefits of the model, but in my experience projects that followed this model were generally finished sooner with less worry about uncaught bugs and by happier engineers.

    Of course you need a build and release system that can automate the nightly drops, and you also need to dedicate the QA and Dev to the project without spreading them thin across several projects at once. In general the parallel process is a bit slower for multiple projects because engineers are dedicated to one project at a time, but in the long run fewer well-done projects is better than many poorly-done projects.

    This has just been my experience and my observations, it sure isn't the gospel on software lifecycles.

  • conspiracy theory, anyone? (Score:3, Insightful)

    by rnd() ( 118781 ) on Thursday January 16, 2003 @09:10PM (#5099143) Homepage
    My guess is that the reason for the +1 error was that the code change was deployed hastily in order to plug some sort of exploit that was being exploited very successfully.


    I wouldn't be surprised if the slashcode running /. bears no similarity to any slashcode that has ever been released..

  • First of, guys. For those of you who think you have a MATURE development and deployment process, please tell me the size of your Developer and QA pools?

    Somehow, I think you woefully underestimate the amount of resources that go into coding for Slashdot.

    • If you mean people, its 4 developers, 2 testers (actually the testers are the analysts that wrote the requirements documentation).

      If you mean money, I'm a consultant, so its more than most would pay. I guess it comes down to pay in this case. I understand that you get paid to be an editor to articles. What about people that are strictly developers under VA's paychecks? They should put in a development structure. I understand that most dot-coms didn't go for structure and design (and VA/OSDN originally was a dot com), but now that we see that it (the dot-coms lack of structure and design) caused more harm than good, it should be addressed.

Slashdot Top Deals

An Ada exception is when a routine gets in trouble and says 'Beam me up, Scotty'.

Close