Imagine a Development Project

I had my imagination stumble into a scenario recently based on Jeremy Miller’s blog entry “My Game Plan for Starting a Project from Scratch“.  Imagine a development project where you get to start everything from scratch.  Imagine you can setup everything properly from the test servers to the virtual environment to the development platform to the continuous integration server to the methodology process.  What would you do?  What would you use?

These are the questions that come to mind for each “part” of the development effort.

For Process;

  • What development process would you use?  Waterfall or Agile?  PMMI or Six Sigma?  A Newly Advanced Magic Wand Approach?
  • How long would you want your iterations? 
  • How many people would be ideal for your team?

For Tools;

  • What would your continuous integration server be?
  • What would your source control be?
  • What would the task management software package be?
  • What would the bug tracking software package be?
  • What unit testing framework or frameworks be?
  • What other code smithing, generation, refactoring, or other software tool needs be?

Standards;

  • What code coverage would one aim for?  For the database?  For the UI?
  • What UI standards would one use?  Microsoft?  Custom?  Big Bird UI?
  • Would extensive Design Patterns be brought to the forefront of design?
  • Would you do design 80% up front and 20% during development or approach in a more agile manner and save most of the decisions until the problem is approached?

What other ideas, thoughts, or notions would you come up with to make sure the effort runs smoothly?  Throw me your thoughts, I’m curious what other ideas there are out there.

Published by Adron

See: http://compositecode.blog/about

8 thoughts on “Imagine a Development Project”

  1. For several of these, I would say "it depends". And what I mean is it depends on the particulars of the project.

    For Process:
    -Agile
    -Two weeks
    -8 to 10

    For Tools
    -Cruise Control
    -SVN
    -TFS
    -BugTraq
    -XUnit / Rhino mocks
    -Resharper

    Standards – Really depends on the type of system we are building.

    –
    –

    Design Patterns: (depends again but here goes)
    – DI / Service Locator definately
    – Command pattern
    – Web: MVC, Winforms: MVP WPF: Model-View-ViewModel / Presentation Model
    – Factory
    – Adapter

  2. To make things run as smoothly as possibly, I would get rid of all the people, especially executive management and ego-maniac pseudo-techies and rule the remaining process with a steel fist! No more ‘team decisions’ or ‘design by committee.’ You need a really good, strong technical person running things from the top, period.

  3. Ego Maniac Pseudo-Techies and steel fists!  Now that sounds like success!  Throw in some ‘design by committee’ and one has to be guaranteed success!

    😮   I love it!  🙂

  4. Just a few thoughts:

    Some of the tools you choose might depends on the skills of your team.

    I know CC.NET, so I would use that.

    There are several good source control tools available, but I would want to make sure the one we use integrates nicely with Visual Studio. VS Team Edition might be a nice overall solution, but the initial version seemed a tad buggy.

    Team size? Depends entirely on the project size.

    Save design until problems are encountered??? You’re just BEGGING to have LOTS of problems if you don’t design up front. Pardon me a moment while I go vomit.

    I think, for an experience team, it will be evident where to use patterns. You don’t have to go crazy…just use them appropriately.

    Last, have all your team members read "The Mythical Man Month" before starting the project. 🙂

    Good luck!

  5. Hey Jay – I totally get what you’re saying about design problems.  Except I’ve miscommunicated what I mean by “problem” in the entry.

    What I mean by “problem” above is those hidden problems that come up.  Generally some projects hang so much on design and try to resolve all of the “what if” problems up front, which often unnecessarily inflates the planning and design phase (a dilemma of attempting to push Six Sigma directly onto a development process).  If that time is just saved until one knows the problem then a resolution can usually be more closely matched to the problem….and oh yeah, Mythical Man Month.  A good read to know what needs avoiding.  🙂

  6. Hey, there Adron:

    I am FORCING myself not to answer this perfectly. Very hard (as you can sympathize, with your predilection for perfection/completion).

    That said, here are some thoughts—

    TOOLS
    1. Resharper (OF COURSE!!!!!)
        * Many MANY developers write code EVERY day that would not pass the resharper test. They/WE can all learn and improve via this tool.
    2. FXCop (free from MS)
       * It is FREE from Microsoft for anyone
       * It is configurable
       * Many have used it, and have made available their comments and toolsets online
    3. Here is a link for your viewing pleaseure entitled "Scrum Tools Roundup", by Bil Simser:
    http://weblogs.asp.net/bsimser/archive/2006/10/21/Scrum-Tools-Roundup.aspx

    AGILE/XP DEVELOPMENT:
    As you said, Adron, it REALLY depends. Two things the application of Agile and/or XP depend upon is the personality of team members, AND HOW those team members FIT TOGETHER. You just can’t force the issue! You can try, and some will be malleable enough to write together, to build together, or in the case of ‘sprints’ to rise to the high-pressure occasion and knock the tasks out within the short time-frame.

    MEETINGS:
    Remember KICK-OFF MEETINGS? Holy shit! What a waste of time…..when it comes to ANY MEETING, at all, the GENERAL rule is, more than three attendees is a wasted meeting. Meetings should be no longer than an hour. Meetings should be used for making decisions or for distributing tasks, or for learning.
    Meetings are expensive, especially when you invite an ENTIRE SOFTWARE TEAM. To force people like us, who learn better from machines and books than from HUMANS, to SIT AND ZONE OUT while admin types are cheerleading about the upcoming task phase, is to waste money. Further, instead of ‘pepping us up’, it irks us, and we start our ‘sprint’ angry at the humans….ARRRRGHHHHHHHHHH!

    I am done ranting about kick-off meetings.

    FLEXIBLE UNDERSTANDING MANAGEMENT:
    A FLEXIBLE staff, especially flexible managers, is so helpful in the development realm. What I mean, is that many developers have similar people skills (none). Many developers work and learn best in certain ways. Management who take note of this and respond to it, are to be lauded. Developers who MANAGE the MANAGER by communicating their strong suits and best methods of work and learning, etc… are also a benefit to projects. My point? Stop expecting developers to be commoners who love the humans—-allow for our quirks, they CAN BE BENEFITS. If a guy works alone for eight hours, and produces more than the three days he is micro-managed and attends administrative type meetings, then isn’t that loner’s ‘quirk’ a positive? Hasn’t he just saved the company money?

    Out,
    aendenne

  7. Size matters, what size is the effort, the budget, the team, the product, the project?  

    The perfectest and most productivest and bestest and successfulest projects I have worked on have been small, very small.  And fast.  And hard.  One technically savvy Business Analyst slash project manager that gets the interface with the user/customer and knows what it takes to write software.  That guy tells the customer the bad news when it’s known.  Gets the schedule to match the work, and fixes the schedule when it’s broken.  He keeps the crap clear for the ‘real work’ to get done.  One to three coders, no more.  One uber coder that argues with the PM/BA about minutae and project impact.  But they love each other.  One DB geek that walks the line between BA and DB Dev, but can normalize his way out of a paper bag.  He owns the db server and environment and knows why he set it up the way he did, and gets called ‘The Data Bitch’ to his face.  This dynamic group of no more than five sit together most of the time, all the time.  Sure there’s the early guy that likes the quite and the data guy that takes a long lunch with the laptop but you basically are in the trench together.  Source control?  Collaboration?  Documentation management?  Bug tracking?  Promotion processes?  I don’t care, it could be on napkins for all it matters, what ever your team is used to working with.  A UML bent on OO driven design?  Rational.  C# in an all Microsoft environment?  Use their toolset, but give the db guy a break with something like Toad.  🙂  Whatever.  

    You ever been under fire from enemy positions and out of contact with air support?  In some sandy shit hole on the other side of the world?  Who do you want with you to take the hill?  Yeah, the same guys you want on this project.  Tight schedules and stress right up to delivery, work your tail off with 50 60 or 80 hour weeks.  Hit the rythmn.  Get that shit done.  Then on iteration drop, you all go drink too much, yell at the PM/BA, tell them you love them, and take a week off before the next drive.  

    That’s the kind of projects I love, and the ones that are the mostest bestest usually.  

  8. I like the mostest bestest projects.  They do rule.

    …and the trenches analogy is without refute.  🙂

Comments are closed.