Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

What efforts go into a programming project? (Somewhat OT)

by dragonchild (Archbishop)
on Aug 10, 2001 at 18:52 UTC ( [id://103890]=perlmeditation: print w/replies, xml ) Need Help??

I've been reading Code Complete lately, and thinking about what it is to be a programmer. What skills do I need to have. How does my job break down in terms of Design, Coding, Testing, and Documentation. How should any given project break down in terms of those four things. Are there other things.

And, I came to a tentative, v0.1 conclusion. They should (by hours) break down as so:

  • Design/Research/Thinking: 75%
  • Coding: 5%
  • Testing: 10%
  • Documentation: 10%
I'm thinking that I should be working on Design&Research 10-15x as long as I'm coding. This may be a skew from my current position, which requires an inordinate amount of business-specific knowledge. But, it also applies to my personal projects, too.

What do other monks think about this? Where do you, in your head, draw the line?

------
/me wants to be the brightest bulb in the chandelier!

Vote paco for President!

Replies are listed 'Best First'.
Re: What efforts go into a programming project? (Somewhat OT)
by bikeNomad (Priest) on Aug 10, 2001 at 19:35 UTC
    You might look into Extreme Programming; XP practioners would argue that the split between design and coding is rather arbitrary -- that much of the time spent in "coding" is actually spent thinking about design. And they would also say that 10% of time for actual testing would be too high, since you'd spend a lot of time up front making automated test suites (you build the test code first, and then design/code until the tests pass). Once you have all your testing automated, the actual time spent on testing is quite small. Of course, the time spent writing the test suites will be significant.
      Well, it would appear to me that the testing portion of this process has been the part that most people seem to disagree about. Not being very knowledgeable in the realm of eXtreme Programming (XP), I'd be interested to hear from someone who is what their take on testing is.

      In your post, bikeNomad, you state: you build the test code first, and then design/code until the tests pass.

      Does this imply that when doing XP, you only perform Black-Box tests? What about white-box tests? These can't really be designed until you written the code, or at least done an exhaustive job on the design and know exactly what your code will look like.

      Since you can't really ever perform black box or white box tests exhaustively, I feel that you really need to do a good job of both. Does XP provide for this? I only ask because your post seemed to imply that it did not.


      To get back to the original post, however, I think you've gone a little overboard on the time spent doing design. Don't get me wrong, I think the more time you can dedicate to doing design, the better (more maintainable, higher quality, ect.) the product you'll develop. On the other hand, it seems like you're skimping on some other areas, specifically, coding and testing (primarily testing). You can have an exquisite design, but if you're not testing against the requirements, your final product probably won't be as good as you'd hoped.

      To draw these two points (lack of testing time & black/white box testing) together, let me give you my opinion of how testing should be done.

      Black Box Testing:
      These should be set up when the requirements are created (just as bikeNomad mentioned). You should know, even before creating your project, what it should produce given various inputs, which is the entire nature of black box tests.

      White Box Testing:
      Your white box tests should be designed to ensure complete path coverage (ensuring that every line of code is executed). This can't be done until your software has been written. This is very important because you can't possibly test your program against all inputs using Black Box Testing. This technique is helpful in finding different types of errors.

      Now that I've rambled on long enough, I think your assumptions look pretty good. I'd add a little time to testing, however. I hate to take time away from design, but I don't think you can really take any more away from anywhere else. Hopefully, this will help you.

      Good luck,
      - Sherlock

      P.S.
      For anyone that is unfamiliar with the terms Black/White Box testing: http://www.scism.sbu.ac.uk/law/Section5/chap3/s5c3p23.htmlgo here. This was just the first site I found - I'm sure you could find better ones if you looked a little.

      Skepticism is the source of knowledge as much as knowledge is the source of skepticism.
        At first, you can only do black-box tests (since, as you point out, there's no code yet). There's certainly room for white-box testing in XP, but it would come later. After all, since your team designed it, coded it, and wrote the tests, tests added after some code has been written can't help but be anything but white-box!

        I think a lot of the distinction between white-box and black-box testing assumes that people writing/performing tests will be different than the people designing/coding. With XP, of course, it's the same people making and running the unit tests.

        Coverage analysis would help to find what you've missed tests for. It's hard to err by having too many tests.

        In XP, you keep adding tests for new features/behavior before you add the new features themselves. At that time, you could add more tests for boundary cases in the code you just wrote if you think it's going to be a problem.

        In XP, there are two kinds of tests - "Acceptance Tests" and "Unit Tests". The Acceptance tests ensure that the code conforms to the requirements, end-to-end. The Unit tests are written against each individual part of the code as it is being developed. You also take significant steps to isolate the code that is being tested from the rest of the program.

        Unit Tests are mostly white-box in that they are written in conjunction with the source-code. The first test proves that you can't get away with just doing nothing. After you have written the first test, you will examine your code, and write a second test that illuminates a failure condition within that code. You then work until that test ceases to fail, and continue the cycle until you can't think of anything more to test.

      you build the test code first, and then design/code until the tests pass

      I've tried that and found it didn't work out all that well. In order to write a sensible test, the feature more or less has to be completely designed. I found myself ping-ponging between the code and the test as I was refining the design. My experience is that test suites can't really be written efficiently until a significant amount of design and coding has been done.
      Otherwise I agree with you, automated test suites are the way to go.

        My take on this testing thing is that XP promotes one level of design (project design) while programmers take it to mean a different level (code design.)

        When it is mentioned "design the tests first" - these are tests on the level of "how will we determine that the code satisfies requirement X" not "this algorithm keeps pumping out numbers that are off by 1/100... I better run the debugger and find out what's going on."

        Project design tests should be written first. Users and Programmers do not view requirements in the same light, so when they try and speak requirements in the same language, projects fail. Designing project-level tests first forces the Users to properly define their requirements and then forces the Programmers to translate that effectively in terms that they understand - the Users have their requirements and the Programmers have their tests - both are looking at the exact same thing in their own language.

        This way, the Code Design will be driven by the tests - i.e. the actual requirements, rather than what the Programmers think the requirements are. At the same time, the Users know what results they can expect, and can compare this with what they want and be satisfied that all is well. This results in projects that are done right the first time.

        Code design level tests must necessarily be designed/run at design/coding time - this is also the kind of testing that first jumps into programmers heads when they read about XP, and is, IMHO, why this aspect of XP is so often taken to task.



        ---Apsyrtes
        I've tried that and found it didn't work out all that well. In order to write a sensible test, the feature more or less has to be completely designed.

        That's the point. :)

        You have a feature you want to write. Instead of asking yourself "How can I get my code to do this?", you ask yourself "How can I write a test that proves my code can't do this?" In the process of writing that test, you will discover the design of the code that will make the test succeed. This is the Zen beauty of test-first design. Then you add more tests until you can no longer think of ways to break what you've written.

        This ensures that you don't do too much work. So long as you only test those things you need, and you don't write anything that isn't contributing to making a test pass, you're not over-designing, or succumbing to bloat.

Re: What efforts go into a programming project? (Somewhat OT)
by chromatic (Archbishop) on Aug 10, 2001 at 22:38 UTC
    You left out the biggest component.
    • Design/Research/Thinking/Coding/Testing/Documentation: 10%
    • Maintenance: 90%
    With that in mind, anything that can be done in the 10% to make the 90% easier is well worth the time and trouble.

    I'm all for thinking and research and design, but 75% seems excessive. Then again, I don't make a distinction between Coding and Testing. As bikeNomad implies, my approach resembles more design-one-feature -> write-tests-for-the-feature -> code-the-feature.

    You can put a lot of time into design up front, but what if you get something wrong? You can put of the tests until later, but what if you don't remember exactly what you were thinking when you were writing the code you're now trying to test?

    Make safe bets.

      In my experience, a contract is drawn up with specifics as to what constitutes completion of a project. The only maintenance guaranteed is what's necessary to satisfy the terms of completion for up to 30 days after delivery. Anything beyond that is another contract. :)

      This works well for contract jobs, but internally developed projects are an altogether different matter. :(

Re: What efforts go into a programming project? (Somewhat OT)
by mothra (Hermit) on Aug 10, 2001 at 20:08 UTC
    Well, this is a very philosophical thread...but I like philosophical discussion, so why not? :)

    Perhaps the biggest skill you need to have is the ability to solve problems. This is a remarkably domain-agnostic skill, but critical to give you a direction in everything you do as a hacker (after all, in one way or another, all programs solve problems). Conceptual Blockbusting is a great book for helping develop this skill (which, the author points out, not everyone naturally possesses, but most anyone can easily be taught).

    Whether it be "Design", "Documentation", "Testing", "Coding", etc. the bottom line is that you have to be able to answer the question:

    What problem am I trying to solve?
    Percentage estimates of how much of each activity of design, testing, etc. should be done are relatively meaningless because it's fully dependant on what problem you're trying to solve.

    By and large, hacking is far more about automating human reasoning than it is about computing, and by extension far more about being able to come up with a solution to a problem than it is about writing Perl code, or Python code, or <insert language here> code.

      To elaborate what I meant by "Research/Design/Thinking", I meant to say that all cogitation about a project, be it on the problem domain, the answer domain, the implementation domain, and/or the testing domain ... all of that should consist of at least 3/4 of a given project's time.

      You cannot build a good set of test suites unless you've thought about how the requirements need to be tested. This includes black and white box testing, as well as other methods. (Bounds testing comes to mind...)

      You cannot build a good implementation without thinking about the ramifications of a given concept. A few things I like to think about would include:

      • Is it easily extended?
      • Is it easily maintained?
      • Is it easily documented?
      • Is it legible? (This is probably the most important, in my mind.)

      And every other domain you can think of falls into this catch-all category. I thought about possibly breaking it down further, but realized that you might have to research a lot of non-programming stuff (like I've been having to do) for one project, but have to research a lot on algorithms in another. Or, you might be spending a lot of time designing the test suite. Maybe the implementation is conceptually easy, but the testing is damnably hard. Or, it could be the other way round, or a mixture of both. Code Complete makes it very clear that what goes into the pre-coding aspect of a project is impossible to determine for all projects. That's why they pay us the big bucks. :)

      ------
      /me wants to be the brightest bulb in the chandelier!

      Vote paco for President!

Re: What efforts go into a programming project? (Somewhat OT)
by arhuman (Vicar) on Aug 10, 2001 at 20:02 UTC
    • Design/Research/Thinking: 75%
    • Coding: 5%
    • Documentation: 10%
    It's OK for me ! But, I'd just add some percents to testing ;-)
    • Testing: 20%
    Seriously, being not an 'Extreme Programmer', I've whitnessed that tests take (or worst, should have taken :-) a lot more time than initially planned.

    "Only Bad Coders Code Badly In Perl" (OBC2BIP)
Re: What efforts go into a programming project? (Somewhat OT)
by toma (Vicar) on Aug 11, 2001 at 01:28 UTC
    I think it is normal for your job to require a lot of business-specific knowledge. This is what I think of as "understanding the problem" or "modeling." Other people think of this as "going to meetings" or "talking to people" or "design".

    The nice thing about software as a hobby is that you get to choose how much of this type of overhead you want to do. At work, I'm expected to show up at meetings.

    My SWAG at a breakdown:

    Understanding the problem50%
    Coding20%
    Testing10%
    Maintainance10%
    Documentation5%
    Tools5%
    Of course, sometimes you batten the hatches and code like hell for a ten hours a day and design for six hours a night.

    Often you can dramatically change your ratios by working more hours.

    It should work perfectly the first time! - toma

Re: What efforts go into a programming project? (Somewhat OT)
by mattr (Curate) on Aug 12, 2001 at 14:36 UTC
    I can suggest some skills based on personal experience. For one thing, as recently mentioned by other people your hours required will increase if you have to share your brain over a number of projects or unrelated tasks.

    I also find (don't necessarily exploit well but hey) that time spent out of the office often provides valuable insights.

    In other words the ability to manage your development efforts to include perspective and relaxation (i.e. no hairy deadlines with manager types hanging over you) is pretty significant. The corollary is that the skill of accurately predicting how much time a task will take is critical but until you are a guru at it you need to have a buffer zone and risk management in place.

    I'd also say that regarding necessary skills, you will need to be able to critically analyze the problem statement to figure out what the problem really is, in other words you might have to spend a significant part of the 75% up front to find out what the client actually wants/needs. I usually write a document which says, "So you want this, right?" and then we are on the same page. You can try to keep that fuzzy glow of ambiguity but it can bite back ("But of course we need a secure idiot proof whiz bang administration interface", etc.)

    I would say that if you are building a system and getting paid by somebody else, then some time is going to be spent on setting up a framework (XP has some ideas about this) that lets you stay sane and avoid feature creep and other requests for the impossible.

    It depends what kind of business you are in; it is possible that people will not value the time you spend on maintenance or not want you to do it. So communications skills are pretty important.

    Right up there, documentation skills will save you not to mention people who come after you. So keep a finely detailed record of all communications you get from people about the project (helps unweave stringy masses of requests and can keep your job for you or get you a new one) and also keep a log of the work you do for your own sanity.

    You also can use engineering skills which will free you from coder hell and turn it into an engineering problem. You get a sense of equilibrium and can also decide between various strategies based on what the system is fundamentally going to have to be able to handle, instead of starting with one idea and then realizing you have to keep tweaking the whole thing into some other direction. For example it may be that thinking about it from a user interaction standpoint, or in terms of performance requirements, will be more important. Also if you break things into small tasks and set yourself up for a series of wins (punch the air, it works!) you have a tool for effectively managing your resources (you and your time). So engineering skills (as separate from from programming skills) are important to keep things on an even keel, and fun.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://103890]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (4)
As of 2024-03-29 11:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found