What should I focus on first?
I'm struggling with this one, I have a big scope of where I need to start in my head, but I don't know if it is the right approach. I think once I get this part figured out, the rest should flow smoothly for me. I really want to get noticed with this, and really want people to look back and say that I handled it well.
Any suggestions?
-- Yes, I am a criminal. My crime is that of defyance.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Starting a Large Project
by Ryszard (Priest) on Feb 12, 2002 at 02:08 UTC | |
There are of course lots of detail missing such as documenting your unit tests, usability testing, requirement gathering etc, however depending on the your definition of 'large' they may or may not be important. You may have noticed lots of 'sign off' comments. this is important for a few reasons: In reality however, things never seem to go to plan. You may not be able to communicate with the stakeholders effectively, they may impose a 'vital' bit of functionality at the end, you may not have peers willing/available to comment on your design. If you follow some basic guidelines, communicate with the stakeholders, be honest about the status, you should be cool. Remember doco, its the most boring part of a project, but one of the most important parts. When you leave your job, someone else will need to know how/what you've done. Goodluck! | [reply] |
by defyance (Curate) on Feb 12, 2002 at 02:16 UTC | |
-- Yes, I am a criminal. My crime is that of defyance. | [reply] |
Re: Starting a Large Project
by dorko (Prior) on Feb 12, 2002 at 01:00 UTC | |
Plan. Then plan some more. Don't just plan in your head. Write it down. Draw pictures. Develop flow charts. Think about the data structures you'll need. Work out rough dataflow diagrams. Think it through. (Given that it's just you working on this project alone, I wouldn't bother with a PERT/CPM analysis.) Set it aside for a day or two. Read it again. Plan some more. Time spent planning is never wasted. Good luck. Cheers! Brent | [reply] |
by defyance (Curate) on Feb 12, 2002 at 01:23 UTC | |
-- Yes, I am a criminal. My crime is that of defyance. | [reply] |
Re: Starting a Large Project
by impossiblerobot (Deacon) on Feb 12, 2002 at 01:48 UTC | |
The specifications will still almost certainly change, but at least you and the client can have some measure of agreement that the requirements have changed, and it gives you some ammunition when changes in scope make a project take longer or cost more. Also, if you document every aspect of the design, including data structures, input/output, response time, etc., then writing the program is much easier, since all you're doing is translating the description into your language of choice (Perl, of course). Otherwise, you can end up writing a lot of code that doesn't do what the client thought it was going to do. Update: I forgot to mention that if you're ever coding and you find yourself trying to decide which way the client would like the program to work, your requirements document is not detailed enough, and you should probably stop coding immediately and go finish it. :-) Impossible Robot | [reply] |
by mattriff (Chaplain) on Feb 12, 2002 at 02:45 UTC | |
For me, the most important step in any large project is putting together a good 'specifications' or 'requirements' document. If you can do this in enough detail, and have the client sign off on it, you can save yourself a lot of work.I'd like to second, third, and fourth that. :) I've worked on several projects that skimped early on in the requirements gathering phase, and we suffered for it later. All I can say is, I'll never let that happen to me again. Designing a beautiful architecture only to find that it can't be made to meet the end-user's needs is no fun. Making up the requirements as you go along is fun for a few months, but then it starts to get old. As much as you can, it's good to know where you need to end up before you get started. -Matt | [reply] |
Re: Starting a Large Project
by belg4mit (Prior) on Feb 12, 2002 at 00:59 UTC | |
-- | [reply] |
by petral (Curate) on Feb 12, 2002 at 02:10 UTC | |
update:   Oh, and get something visible running soon (for some definition of "works"), then you have the confidence/support to take the time to get it right.   Otherwise, no one can be sure anything's going to come of it.   p | [reply] |
by count0 (Friar) on Feb 12, 2002 at 15:55 UTC | |
On large projects, I first write the meat of main man pages - consisting mostly of overall functionality, command line switches, etc. Then, assuming an OO project (in Perl or C++ -- and most large projects should be OO, imo), sketch out each object, and all of their public methods! For me this usually entails writing the document for the use of the class/module. I can't stress enough how critical this is on large projects, especially if you are, or will be working with others. On countless occations I've seen classes/objects gradually morph as the project progresses... eventually into hideous monstrosities. This is always a direct result of bad planning, or a lack thereof. ClassA, for instance, doesn't quite click with a part of ClassB.. so each add another method to fit together more cleanly. Then ClassC comes along and requires a bit different output from each of those, so A and B get new member functions that wrap existing ones, to return a bit different.... and so on and so on. If all components of the project are first mapped out, and their external interfaces designed in detail, all that is left is sticking the code in - and when these components are first mapped out, the coding usually is about 10% of the project. | [reply] |
Re: Starting a Large Project
by trs80 (Priest) on Feb 12, 2002 at 03:18 UTC | |
I then take the recurring items and group them into modules and then do the same with the related items. The areas that I think are going to be difficult to program are mapped out in great detail on paper to determine possible approaches and weak points before I am looking at code and confusing code with process. If an area still doesn't make sense then the requirements are bad and the person who created them needs to be consulted. If you created the requirements then good luck :^) Lifespan takes on different forms. One is how long the code will be in use, the other is will the program run and end or will it operate in a server mode that effects caching and memory usage. Each of these will effect how you will approach your coding. Target audience is involved because this may determine how elaborate the user interface needs to be and/or where possible shortcuts can be taken. The container for your products data can really haunt you. Lifespan comes into this as well since again if it is only a temporary storage system that will be disposed of you don't have to as concerned. If the product and its data will have a long life you will want to take into account how the data will be interacted with in the future. Does it need to log things? How long do I think the storage method I am using will be available? Is it easy to interact with from other languages? There are many more questions and vary from project to project. Are parts of what I am doing on CPAN? This is more then important in my opinion, use CPAN code vs. reinventing the wheel. This can also be one of the tricky parts as well, since often times module names seem to fall under three categories. So I guess planning is what you should do first. Hopefully somewhere is that brain dump someone fines something useful. If someone thinks it is useful enough to refine and make a meditation out of let me know, but I am following my rule and thinking the lifespan isn't long enough for me to refine it any further. :^) | [reply] |
Re: Starting a Large Project
by MAXOMENOS (Scribe) on Feb 12, 2002 at 02:29 UTC | |
After you know what a piece of code should do, and before you implement that piece of code, you should write a unit test for that piece of code. This is just so you can be sure that your component works properly, before you go on to build bigger and badder things. The more crap your unit test does to your component, the better off you will be. Test basic functionality, test weird cases, do stress-tests, throw bad data at it, etc. Learn how your components behave, improve them, and get your component as good as you can possibly get it. It might not hurt to throw in a couple of performance tests, either. I've gotten bitten by not doing proper unit testing. On the other hand, I once managed to turn my reputation around from 'incompitent' to 'damn, he just saved the contract' by doing proper unit testing. Just two cents, and sorry I don't got more. | [reply] |
by ignatz (Vicar) on Feb 12, 2002 at 16:20 UTC | |
I used to just scoff testing off till the end but now I'm a total test junky. It saves SO MUCH TIME. ADDED: Chromatic's article on Perl.com is a great introduction. ()-() \"/ ` | [reply] |
Re: Starting a Large Project
by toma (Vicar) on Feb 12, 2002 at 07:58 UTC | |
You should be able to draw the 'big picture' of your approach on one page. This picture might be complex, but you should be able to point to it and explain what each part of the picture is supposed to do. This is the thing to focus on first. The best way to draw this big picture is to use a whiteboard and iterate versions of it until you think it is perfect. Be sure to put your name and the date on the picture. Now for the tricky part. You need to get the picture onto some paper. The best case is that you have a whiteboard with a printer attached to it. If you don't have that tricky bit of technology, transcribe the board by hand on to a sheet of paper in ink. When people see your architecture written in ink, they will be intimidated. This is good. You don't want some idiot rearranging your work for no good reason. Then code like hell and make as quick and dirty a prototype as you can. Use real test data provided by your customers as a demo. Show it to your customers and have them tell you what they *really* wanted. When they ask, 'can it do this or that?' don't worry about how much effort different approaches will take. Just say "Sure, it can do that! The important thing is that's what you really need." Think through the implications with the customer as best you can, throwing caution to the wind. Keep a list of every single request for change. These conversations with users will tax your ability to back off and see from the customer's point of view. Don't worry that minor changes may have major impact on your code. Don't try to defend your design decisions at this point, just try and see how the system could truly be improved. Next you have to decide if you can salvage your proto or if it is best to start over. Since it is your first big project, you'll probably need to start over. No big deal. Look at the big picture you drew. Is it still right? If it's wrong, don't fix it, file it under 'prototype' and redo the whole thing. You did it in ink anyway! Now, go through your list of changes and see if every single one of them is all fixed up in the new system. You might find that a few of the requests really don't make sense in the new system. Go back to your customers and see if these items can be worked out another way. Emphasize to the customers that you aren't looking for compromise, you're looking for the best solution possible. Not necessarily easy for you to implement, but at least possible for you to implement within your constraints. This time you code it carefully. Use the advice given in the other responses to your question, especially using revision control and building test code. Use revision control from the start. Continually improve your coding practices throughout the development of the prototype. In the second version, back off and simplify your coding style a bit, using only things that worked well in the prototype. Don't get grandiose and try to solve a larger problem or use new untested techniques in the second system, instead solve the problem in a simple yet comprehensive way. You'll notice that the code gets larger and more complex as you add all the necessary error checking and handling of special cases, so start simple to keep the code from becoming too big of a mess. Show it to the customer again. Find out if this system is better than the prototype. It might not be! You might want to iterate again, this time keeping true to your original vision. This isn't so much trouble; since you've coded the thing twice now, you're getting good at it! To summarize, my advice is to draw nice system diagrams by hand. Build a proto, get feedback, start over. Understand the system from top to bottom and be able to sketch how it works at every level. Work hard and keep the design of the whole system fresh in your mind. Imagine that your bosses' bosses' bosses' boss is coming to review your work one day. You have a wad of slideware about the system to show to the Big Cheese. The slides have been reviewed and sanitized for political correctness. But when you get to the meeting, the big boss says, "I've been looking at slides all day and I'm tired. Just draw me a picture of the system and explain to me how it works." You'll be able to think and draw on your feet while speaking clearly. That's looking good!
It should work perfectly the first time! - toma | [reply] |
by Theseus (Pilgrim) on Nov 01, 2002 at 21:25 UTC | |
| [reply] |
Re: Starting a Large Project
by dreadpiratepeter (Priest) on Feb 12, 2002 at 03:42 UTC | |
Leaving aside the excellent project lifecycle comments already posted, I would make a couple of suggestions on the design and coding part. First, there are 2 books that you should read before tackling a large project. They both by Microsoft Press (stop laughing! No, really I mean it!) Code Complete and Writing Solid Code, both are excellent studies of how to code effectively, and how to test effectively and how to debug effectively. Conclusions as to why Microsoft doesn't produce better software aside, these are indispensible resources. Second, if you are looking for a place to begin- think data and data structures. As James Brooks says, paraphrased from The Mythical Man-Month, (which I don't have in front of me) "Show me you code and you've shown me nothing, show me your data and you've shown me everything". (Actually, make that 3 indispensable books. Read Brooks as well, especially his "plan to build two, you will" essay). Anyway, think about you data. How it will be store, retrieved, manipulated, past around, verified and tested. Build tables, normalize, set boundry conditions, determine dependancies and relationships. Once you know everything about your data the code will write iself. Third, plan and built test cases from the very beginning. As you add features add test case to test them. It will be much more effective than going back later and trying shoehorn tests in. Look at the testing tools that come with perl, or search PM. Keep a todo list and a changelog. Each day update the changelog with bullet items of what you added or fixed. It will motivate you and give you a sense of accomplishment. Everytime you have an idea for a feature add it to the todo list and periodically scan it. (Neither of these are substitutes for a good MR systema nd a good source code control system). Without knowing more etails about the project I can't give more advice. Good Luck and Think Big, -pete Entropy is not what is used to be. | [reply] |
Re: Starting a Large Project
by screamingeagle (Curate) on Feb 12, 2002 at 02:03 UTC | |
as you debug and test each step, the next milestone in your project will be less susceptible to bugs and errors caused by the steps preceding it and should, on the whole, make it more manageable to manage the entire process I would also recommend saying a small prayer to the Gods of Perl every morning before you start to code... :-) | [reply] |
by VSarkiss (Monsignor) on Feb 12, 2002 at 15:31 UTC | |
I would also recommend saying a small prayer to the Gods of Perl every morning before you start to code... <horn action="toot" type="own"> | [reply] |
Re: Starting a Large Project
by dws (Chancellor) on Feb 12, 2002 at 03:59 UTC | |
If by "scope" you mean mental picture for how the system will fall together, I suggest you take one step back, and focus first on how the system will be used, and then get real users to validate your usage model. Otherwise, you risk doing a great job of building the wrong thing. One quick way to develop a usage model is to use storyboarding, where you use pictures (e.g., prototyped screens shots) to walk users through a typical use of the system. This gives users something tangible to give feedback on. If you want to get more formal, you can capture usage scenarios in "Use Cases". (Most books on the UML or the Rational Unified Process will tell you more than you need to know about Use Cases). I've used Use Cases on big projects, and have seen a good payoff. Then, once both you and your target users are satisfied that you're building the right thing, use some of the excellent advice in the posts above.
| [reply] |
Re: Starting a Large Project
by Phaysis (Pilgrim) on Feb 12, 2002 at 03:33 UTC | |
I've been planning, dreaming, and mucking-about with this thing for over a year now and it's now time to do something about it. I've divided my code into modules, chunks, and units based on general, generic functionality (note: keep your options open: use generic functions; this will give you building-blocks for more complex functionality later). I've finally gotten the dataflow, object linkage, and program flow straightened out and down on paper and whiteboard, posted for quick reference, and this is a Good Thing. It helps immensely. Now that things are planned out and chunked into smaller bits (one module for getting the request environment, one module for templating, one module for logging, etc.), I can begin working on each part in order of most-independent to most-integrated. For each module I build, I'm using test scripts and doing unit testing to make sure the functionality, logic, and conformance to normal and strange cases is as I need (a working directory filled with test scripts is nothing out of the ordinary). So, after about a week of making steady headway on this project, I'm seeing the light at the middle of the tunnel, with overall testing, debugging and profiling on the other side. The Big Green Light at the end of the tunnel is always in my mind, but I must keep it in perspective and go towards that goal. Baby steps, man. Most of the suggestions listed here are top-notch suggestions, and worthy of getting into hard copy. Personally, I'm glad that you asked, defyance. I too needed some validation to the copious steps I was taking on my own project. I suppose a nice side-benefit to working on your own Large Personal Project is that you sign yourself off. Y'know? Best of luck, one and all.
-Shawn | [reply] |
Re: Starting a Large Project
by tune (Curate) on Feb 12, 2002 at 02:39 UTC | |
What is bothering me (The Programmer) that usually I just want to do steps 8-13, the others should be taken care by someone called Consultant, or Organizer, I don't know the exact description of the position. However if you are in a small organization, you are expected to do the whole process by yourself. --
| [reply] |
Re: Starting a Large Project
by rbc (Curate) on Feb 12, 2002 at 04:50 UTC | |
Documentation Documentation! Did I mention documentation? I good functional spec and a good detailed design document are well worth the effort. | [reply] |
Re: Starting a Large Project
by ignatz (Vicar) on Feb 12, 2002 at 11:04 UTC | |
()-() \"/ ` | [reply] |
Re: Starting a Large Project
by George_Sherston (Vicar) on Feb 12, 2002 at 17:11 UTC | |
When you switch it on you see... Then, you can press a button called "Foo", and if you do that you'll see... On this page you have some information about Blah, and several options: a link to "Bar", a button marked "Baz"... After I've done that, I usually find that I've exposed any stupid assumptions I was hiding under technical generalisations, and I have a pretty good idea of how it breaks down into subroutines (and where code re-use is likely to happen). And as a bonus I have the basis of a pretty informative set of comments to imbed into the programme. § George Sherston | [reply] |
by punch_card_bob (Initiate) on Feb 12, 2002 at 18:19 UTC | |
There's nothing I could add regarding the technical aspects of your project, beyond the excellent advice above. On the other hand, there may be a few points to draw out concerning career advancement. Wheterh you are in an organization or consulting, it can be very advatageous if the people for whom you're designing feel confident and comfortable, not just when all ends well, but throughout the whole process. You want your superiors/clients to say "He had it under control the whole time, we were never exposed to risks." That means using the user-input / planning / sign-off / validation steps mentioned in other posts as, in fact, public banners advertising your project management competence. Get user input by distributing written invitations, with copies to management. Distribute your plan, with copies to management. Confirm the sign-off in writing, with copies to management. Etc. You might even start out by publishing your intended steps so people know what to expect. | [reply] |
by defyance (Curate) on Feb 12, 2002 at 18:00 UTC | |
Seriously, I'm printing this stuff off. -- Yes, I am a criminal. My crime is that of defyance. | [reply] |
by defyance (Curate) on Feb 12, 2002 at 18:21 UTC | |
See, I know that's probably the way it sounded, but to explain myself a little, that is not my intention at all. My ultimate goal with this project is to make someone's life just a little bit easier anyway I can. Now I will mention that yes, I would like to get some recognition for this, and the money is a plus, that has been made known. I don't think I stressed the initial reason, however, for accepting this project. Even before I first entered the world of Technical Support, and Programming, My ultimate goal in life was to make things easier for someone, somewhere. Not many people have such a strange goal, but I do, and that's what led me to programming. I'm ecstatic that I'm finally getting the chance to do it! That's why I wanted as much advice about this as possible, I don't want to screw it up, and not accomplish a lifelong goal! I'm sure this sounds like a line of bull to most of you, but this is truly from the heart! -- Yes, I am a criminal. My crime is that of defyance. | [reply] |
Re: Starting a Large Project
by weini (Friar) on Feb 12, 2002 at 06:07 UTC | |
I learned a lot reading all these answers and there is only one thing I can throw in the discussion: It helps me even for small scripts and I guess it will do a great job on large projects ... and it's easy to learn - I know what I say ;^) Just my two cent ... | [reply] |
Re: Starting a Large Project
by zakzebrowski (Curate) on Feb 12, 2002 at 13:10 UTC | |
---- Zak | [reply] |
Re: Starting a Large Project
by jlongino (Parson) on Feb 12, 2002 at 22:53 UTC | |
In the few instances where I've made design mistakes, they usually stemmed from the fact that I failed to examine the required output/reports closely enough or made wrong assumptions (though usually valid) based on experience. Recently I was given an example (publication) to work from and found out later in development that they had changed their example substantially without telling me. Thus the need for constant design/programmer/customer feedback throughout the life cycle of the project. --Jim | [reply] |
Re: Starting a Large Project
by Anonymous Monk on Feb 12, 2002 at 22:02 UTC | |
Project management is alot like programming Perl. TIMTOWTDI. | [reply] |
Re: Starting a Large Project
by tjh (Curate) on Feb 13, 2002 at 02:09 UTC | |
I can only add my 2 credits worth:
1. Where do I want to end up? ----- Projects tend to change, sometimes radically, from their initial scope. Nothing new in that thought. So, I began planning in the unplanned request, the midnight revelation, or the damn business plan changes. My own projects experience the same things. I'll start out in one direction, usually get to the releasable functionality step, only to find new features, functionalities, or even different uses from what I started out to get. Forever, those seemingly inevitable changes seemed like Evil. Eventually, when I began working with these flexibilities in the initial planning stages, and throughout the actual coding/testing/release stages, things smoothed out remarkably. However, it is sometimes a tense moment to explain 'releasable functionality' to those that think they know or designed a foolproof plan and scope. And none of this precludes definable milestones, deliverables schedules, signing off on scope, changes, turnovers, etc. But, realizing that "it's going to change" and working to define and quickly arrive at useful milestoned deliverables has saved me/us from many antacid-filled nights. Sometimes, releasable functionality represents a business plan change as well as a coding release schedule. So, if it's not really my place to make such a suggestion, or if the project has iron-clad scope (rare?), then I forget about that thinking (which hurts, since I tend to think it's a valuable approach, even if the first releasable isn't actually rolled out). (My favorite post-planning question has turned out to be: Ok, so we've done all this planning, accounted for every possible problem, completed and rolled out the product, and it still fails. What are the top 3 reasons why it will have failed?) </MHO> | [reply] [d/l] |
by defyance (Curate) on Feb 13, 2002 at 02:19 UTC | |
-- Yes, I am a criminal. My crime is that of defyance. | [reply] |