Software Eng. coding myth

[CodeGuy]

Yet again I have just heard the statement from an academic that the coding phase of the software lifecycle takes only 10-15% of the total project time. Even Steve McConnell in "Rapid Development" breaks down the standard project lifecycle this way. My question is, does anyone think this 10-15% estimate is true? My reason that I think the estimate is a myth is that I have never stayed with one toolset for any length of time. I have done three consecutive software projects with my company: the first one was in VB using DAO; the second was using VC++/MFC/DAO + an unfamiliar graphics and browser packages; and the third is now using ATL/WTL/COM/ADO. With the constant adaptation that is required on the leading edge of technology, I don't see how anyone can not be learning and coding at the same time. (For instance, by the time I'm done with my current project, I fully expect to have to learn C#, ADO+, COM+, etc for my next app) In my experience, this combined learning while coding takes more like 50-75% of my time. Further anecdotal evidence suggests this too: the many statements by COM gurus that the COM "light bulb" came on only after they had used it for six months. My guess (and I don't think this is very much of a stretch) is that they learned COM while applying it to their own projects, not just writing little test programs. I guess the cases where the 10-15% estimate could be true are 1) very large software projects, where more time is spent in managing and design to avoid screwups and miscommunication, and 2) relatively static toolsets and libraries, where changes occur infrequently (e.g. ANSI C++, FORTRAN 90). Hmm, does that option 2 make you think of most academic environments? :-D What do you guys think? Regards, Brandon

[ColinDavies]

>> the 10-15% estimate is an estimate and the figure has to vary wildly from project to project.Actually in this world of COM+ etc 10-15% seems a bit high. For Me as an independant developer on a project in the development stage I could break my time down easily into, a) 15-20% admin b) 30-35% Research on Project, c) 40-45% Learning Skill set for Project, d) 5-10% Coding a) has to be done the longer the project the more totsl time a) takes. The more b) and c) that I do the less of d) that is required. Note, I will not sit down and write working code, Unless I already know exactly what the code already is ! So d) entails 1) writing in Rough ,PseudoCode 2) than Tidy ,PseudoCode 3) Filtering it through structured Programming Model. 4) Now Entering it in via digital Input advice. But In the last two years I have never had a logic error or real necessity to use a debugger! I believe most corporate environments like to see Programmers hard at work over a keyboard, rather than reading books in a cumffy chair or surfing the web. But I believe the more up to speed a developer is, the better exponetially they will produce code. Regardz Colin Davies "A Santa pets G-Norts ! Mr Alien De'Kramer", remarked Neil Armstrong step at Nasa.

[Christian Skovdal Andersen]

Hi, It is always nice to have lots of time for project management, research and administration. Being an independent developer in a small company, we have to meet very tight schedules, and deliver software fast. "Doing it right" is just not something that can be afforded in a competitive market. That's propably why our distribution of time is more like this: a) 5% admin b) 10-15% Research on Project, c) 10-15% Learning Skill set for Project, d) 40-50% Coding e) 25% Debugging I know thats not exactly what you learn in "Project Management 101" - but it delivers the stuff that customers want (mostly) on time. I have worked in bigger companies, where countless hours was spent in meetings and project planning - lots of timetables and gant-charts, just to end up on a shelf in some managers office. I think the only reason that smaller companies, like my own, is able to survive, is because we focus on software development instead of document-development. Christian Skovdal Andersen

[ColinDavies]

I'm at It in my little Seaside development house, I make the Coffee through to Writing Code to golfing with the Venture Capitalists and Merchant Bankers, :-) To put it in perspective Christian - With rough Approximations, If my project has 30k of free implemented Code on top of the MFC, WinApi, Com, This takes me approx 6 weeks to type, and my coding takes 6 weeks + syntax errors. The project takes about a year all up, I won't see the VC IDE for the first 3 months, of the project. Admin is a pain but it must be done to stop the baliffs etc visiting, Also in Admin I'm counting having to sell my skills for future projects. .. For your 25% Debugging, I would consider why ? Why do you have so much Debugging to do ? 1. Bad or inappropriate initial Design, 2. Poor Organization between developers. 3. Project not researched well enough. -> I ask you this question without Malice ...... Also Christian I come from a programming environment of punchcards and gator clips. Debugging punch or marker cards is horrid. Debugging gator clips, Means its better to start again from scratch than to Debug it. So I guess I learnt to do it right the first time. The biggest advantage of this is having confidence in your work. Knowing that the customers won't be complaining. Also doing a high level of Research on the Project means you will be doing what the customer wants, Rather than what you considered appropriate to code. -> Anyhow Regardz Colin Davies

[Christian Skovdal Andersen]

I'm very happy for you, that you've learnt to do it right the first time. I wil start with answering your questions: >1. Bad or inappropriate initial Design, Actually - as little design as possible. We work a lot with API's with very poor documentation, and can not be fixed to a particular design. >2. Poor Organization between developers. No - we work in very small groups, and is as such very well organized. >3. Project not researched well enough. Yes. We start with writing the code to see how it can be done. The research is done along. > I ask you this question without Malice Don't worry :-) However, doing it right is a matter of definition. I think the compile-test-debug cycle is just as right as you way - in the end what counts is to get the software finished as stable and wellperfoming as possible as fast as possible. I can understand that this is not the way to do it, if you're using punchcards etc, because of the problems involved in debugging. But your methods has to change with the environment and the tools, and creating Windows programs is such a complex task that doing all of the design up front would be to rigid. Many of the problems encountered in software develpment can be traced back to thirdparty libraries and quirks in the OS/API, and the only way to find out that these problems exists is to write the code and watch it crash. In the end you may end up with a radically different design, to get around these problems. At last: using a year to spin out a program is just not feasible for my company. If we told our customers that they would have to wait a year to get the product, they would laugh out loudly and contact some other company. I'm not defending putting out software with bugs, just because the market demands it. The statements above is just about the methods used in the developmentprocess. Regards, Christian Skovdal Andersen

[ColinDavies]

>>I'm very happy for you, that you've learnt to do it right >>the first time. Its a matter of planning and organisation rather than ability :-) >>At last: using a year to spin out a program is just not >>feasible for my company. If we told our customers that >>they would have to wait a year to get the product, they >>would laugh out loudly and contact some other company. Ok I was using a year as an example for breakdown reasons, But I do take a while to complete my projects, But I never work by consignment. My process is idea -> development ->sale-> packaging. I agree with you on the problems in 3rd party and OS/API However I put this into "Learning Skill set for Project" Yes I make copious tests, of principles/functions/methods/class/s and 3Libs, that I wish to use. But I don't regard this as coding. And I activly plan how to test the greatest variety of situations before they occur. Thus I build a library of dummy test apps in the Learning Skill Set phase. My problem with your methods of a development cycle, is "How can you estimate how long it is going to take for the Debugging to occur !" A worst case scenario is a project that can't be debugged and must be trashed. >>However, doing it right is a matter of definition. I >>think the compile-test-debug cycle is just as right as >>you way - in the end what counts is to get the software >>finished as stable and wellperfoming as possible as >> fast as possible. Sure if it works for you, don't be quick to change, I also realise My method today is in the minority. Best Wishes Regardz Colin

[Brian C Hart]

>Debugging punched cards is horrid You don't say. My mother is a programmer, and she learned CS on punch cards. Only while she was in the beginning stages of her CS degree compiler technology was such that she had to hand-compile her code line for line and then enter the results into the computer (someone from the University did it for her). This was in 1971 - 1977. Anyway, back to the point. Punched cards only contain one line of code per card, and so she would have to go through line by line and use a core dump to help and go through card by card to see where the problem was. I can remember her telling me that she was carrying a box of 15,000 lines of code (that's 15,000 punched cards) and she fell down the stairs, CAUSING THE ENTIRE BOX TO DUMP OUT ON THE FLOOR and the cards to become randomly mixed. Needless to say, not only did she have to debug, but that day she had to put together all 15,000 cards in the correct order line by line by line... :(

[ColinDavies]

:-) :-) :-) :-) Falling down steps and getting your punch cards mixed up was real common. Also the Prank of Switching one cards position in a pile, Or Punching out an extra hole. Most Card Systems had sequential type coding systems, Actually with most systems also each card was like one Macro Instruction ! Not even a full line of C++; It's a pitty but there were some fancy machines designed to purely sort cards, I guess your Mum would have loved one that day :-) :-) :-) :-) Regardz Colin Davies

[CodeGuy]

A few comments ... I have heard from the "desk checkers" that their method is better before, but I don't think it's really any different than what someone doing iterative development does. Consider if I had the problem of populating a binary tree with elements and searching it: In my head I'd go, well, I need to: 1) Read in the elements from a disk file and populate tree 3) Search tree and print results I'd probably work on number 1 first ... which in my head (as a knowledgeable C++ developer) would quickly translate to void CMyClass::PopulateTree() { ifstream input_file("c:\tree.dat", ios::in); int data = 0; while (!input_file.eof()) { TCHAR buffer[255]; input_file.getline(buffer, 255); data = atoi(buffer); InsertNode(data); } } Not to bore everyone here, but that's what I came up with off the top of my head. Someone writing p-code might have gone: Open input file While not end of file { Read element Insert element into tree } Uh well, OK, I just did that in my head, except I wrote some actual code. Someone looking at my C++ function might say, oh wait, you forgot to check to see whether the file was good, you didn't populate the head element of the tree, etc., but what makes that different than iterative p-code development? I can forget the same steps in p-code that I can writing code. I can figure out the same thing looking at my code on a sheet of paper or looking at it on the computer screen. I think the real point is 1) break down the problem into smaller subtasks. If a subtask isn't small enough, keep breaking it down. 2) review the subtask carefully to make sure it does what is necessary and what you require it to do. I think that the difference between "build 'n fix" and "iterative development" are the two items above. The "build 'n fixers" let their subtasks grow beyond what their brain can possibly hold at one time and don't really check to see that the functions handle all possible flows of control, errors, etc. Iterative developers know better and review their code, whether it be on the computer or on a piece of paper. In my mind, though, the coders have an advantage: the computer can help them verify that their program is working much faster ... and they have the satisfaction of watching their code run. The temptation is to skip review steps -- but this temptation extends to every review, both in code and on paper. Brandon