by Dan Parker

Extreme Programming, Agile Software Development, Rational Unified Process, Effective Project Management, Waterfall Model, Rapid Product Development, Super Awesome Vertical programming.  All these software development methods try to do the same thing: shorten development cycles to 2 weeks, shorten meetings, develop better code and have some brilliant way of tracking things.  They also like to say their methodology is very useful because they adapt to rapidly changing requirements.  There's also a new trend I call Agile Mixology: Combining methodologies like a science experiment. Example: Agile Super Scrum mixed with Extreme Programming.

Whenever a project falls behind schedule, management usually looks for a reason.  Most project managers are usually intelligent, hard working, have good schooling and want to make a difference in the project.  When a project is falling behind, they'll ask themselves, 'What can I do to make things better or speed up development?'.  They're powerless to speed up the actual code development, so they think they can speed up the project by implementing one of many complicated methodologies.  This also makes them think, 'It really does take skill and a college education to manage a project'.  Many times all they do is just read down an excel sheet, but wish they could contribute more.  Only problem is, when they try to do too much, they end up getting in the way.   If something takes 4 weeks of development time, there's no excel sheet gymnastics that can cut it to 2 weeks.

My main point here is use your project management software (PMS)!!!!  (Jira, TFS are examples)   Instead of reading a 200 page book on Upside down programming, read the 200 page documentation of your PMS.  The biggest mistake most project managers make is that they don't use their project management software correctly.  Many of them just think it's a place for developers to put their notes.  Then they just use it as a reference to build their own excel sheet or MS Project and plan from that.  Project management software has come a long way since mid-early 2000s.  They all have queries you can create to give you a breakdown of the exactly the tasks you're looking for.  If management wants to know the current status and items included in a release, at a click of a button you should be able to fire a saved query against your PMS showing work items remaining and how many hours.  Another click can email the link or export it to excel.  In many cases, you have the developers looking at the PMS, the project manager looking at their personal updated excel sheet, and upper managers above looking at one of the daily excel sheets emailed to them (usually from the wrong day).  How can there not be confusion?

 A developer should be able to fire a query against their own work items to see what they should be working on.  When a developer finishes an item, they should be able to easily see what is the next work item by priority number.  This is where the project manager has to do a little work.  Number the priorities, but don't make everything a 1...don't duplicate priorities, make a decision for every work item and developers will know exactly what they should be working on without waiting for a scrum meeting.

I'm not offering complete solutions here, but I'm trying to lead people down the right path and use their common sense. By keeping up with your project management software you should be able to run your project as efficiently as possible. Don't click on articles or advertisements that say, "Did you know that Agile development can decrease your time-to-market by 50% and increase productivity by 25%?" (Found this on cmcrossroads.com). Check your PMS website for updates, check blogs and messages boards everyday about your PMS if you want to be proficient in it.

I also mention a few programming practices below that delay development. Again I don't offer a complete solution. You're going to have to put a lot of trust in your lead developer.

This document is a work in progress. PMS Programming is a little mix between project management and programming advice so you don't over complicate your projects.

In recent years most software development, especially web development, has requirements that change on a weekly basis.  It's only common sense that you can't always stick to the same requirements.  How a new management methodology can take credit for fixing this puzzles me.  You just need to communicate to the group that the requirements will not be set in stone.  There are developers that refuse to go by anything but the spec sheet, are stubborn to stop what they're working on, or think they should be the ones deciding the specs.  They'll go through a big time consuming battle every time a requirement is changed in the middle of development and there might not be much you can do besides get rid of them.  A developer who isn't a team player isn't going change no matter what your methodology is.

I find way too much time can be spent in the planning phase.  I'm all for business requirements docs and technical specifications, but many times you can assume more than 1/2 of it will be deleted, edited, or added on it by the end of the release.  In many cases you won't know what can and can't be done until you start development.  Going over the technical specs in too much detail can be a big wasted of time.  Give it a good once over, make some changes, take suggestions and then start development.  I find it a bit easier to write a quick technical spec, finsih about 15% of the project and add on to or complete the specifications.

I've never met one developer that likes scrum meetings.  Most of those fancy methodologies will say these are important and will give you tips to hold 15 minute scrum meetings.  Have everyone stand up, have a circular table... Meetings usually end up going way overtime and most developers just have 5 minutes of input that could have been looked up in your PMS.

In most cases, programmers don't slack off and will ask for work if they've finished all their assignments.  If programmers are slacking off, scrum meetings are a good punishment.  Just let the team know, "Ok, since this <insert task item> is behind schedule, we're going to have daily scrum meetings until we're back on track".  This will do 2 things, put pressure on the person slacking off to deliver (or start looking for a new job) and have the rest of the team put pressure on the slacker.  It's also a form of public embarrassment.  You can go over the same assignment everyday, asking "Why is this delayed, what do you need to get this done faster, would it help if programmer B worked with you?"  There is nothing worse for a programmer than to hear that everyday and it's a great way to get them looking for another job if that's what you want.  They might not have been motivated before, but they'll usually get the work done to avoid hearing that everyday.

I find scrum meetings disrupt my work flow.  I've heard studies say it takes 30-45 minutes to get back to the work flow/mental state after a disruption from a meeting.  Add in the 15 minutes you should take to review your assignments/prepare for the meeting and your 15 minute meeting is now 1 hr 15 minutes of wasted development time.  That's if you meeting is only 15 minutes.  You can say the 30-45 minutes is a little high, but a developer needs to get familiar with the files they currently have open again and thought process.  Also when that thought process is not in your head, it's natural to check and respond to work, personal email and surf the web.  I'm not condoning it, but that's reality.

If you do need a daily status, at the end of the day tell all the developers to enter in the PMS their current status, how many hours left, or what ever is needed.  You're probably saying, 'yeah right, developers are really going to put that in consistently everyday'.  Just threaten them with scrum meetings and they will.  Say,  "We can have scrum meetings everyday or you can enter your status on PMS'

I'm all for developers interacting with each other, I just don't think they should have to wait for a meeting to do it. If there are dependencies, the project manager can see them in the PMS and schedule a meeting for that topic if needed. I even like low wall cubicals so developers can interact more.

No projects are exactly the same.  You're going to have to put a lot of trust in your lead developer. It's best to have the lead developer break up the project between team members and and give time estimates on the hours required. It's important to remember that adding developers to a project doesn't always decrease production time. 100 hours of development time for 1 programmer doesn't equal 50 hours of development hours for 2 programmers. A great quote from a book from the 70s, The Mythical Man Month, "Adding manpower to a late software project makes it later". Your lead developer needs to tell you how many people would be efficent for your project.

Many software methodologies suggest ways to improve coding.  Most of them suggest having code reviews, which is great if you have enough extra time to schedule a day long meeting before your release.  Maybe have the lead developer scan over a new developer's code and make suggestions.  Most programmers will talk to each other if they have questions with code and will look over each other's code during development.. 

Deployment process-  Having a Development, Testing and Production environment is great if have the servers or virtual machine partitions.  Code should be easily checked out from the repository into each environment (common sense).  You need to find what works best with your developers, don't follow this out of a book.

Iterations and Branching-  Again, this is something where you can't define what's the right way of doing things.  I like to make the current production version the trunk and branch off for development.  Merge the code back to the trunk once the code is ready for production.  Everyone has their own way of doing things.  If your lead developer can't figure it out, then you probably have more problems beyond this.

Unit testing can be useful if it's not abused.  If a programmer gets carried away with unit testing, development time can double while providing little use.  It's hard to give advice on this, because it's a case by case basis.  Just don't automatically think you have to have add unit testing to your code.  Unit testing can catch a lot of errors when multiple programmers are checking in code, it depends on your environment.  You need to figure out how many errors are caught vs how much time is spent writing and maintaining unit tests. (Note, sometimes unit testing can be a requirement , or necessary in medial, credit cards, government...)

Testing - Test as much as and often as you can, hope that phrase isn't copyrighted.  That's common sense again, but in most cases time is limited.  You'll never have enough time to do testing like your 200 page book wants you to.  Focus on the danger zones, things that can bring your website down, log-ins and security.  In most cases a GUI error or typo isn't going to kill you.  People usually go to websites for content, not because the sight looks pretty.  

I'm adding the following section because a non technical project manager will many times pick/hire the wrong developer to lead the project. They'll go for the guy with the Masters Degree, certifications and can hit all the new buzzwords. For most web development projects 5 guys with Masters from MIT are not going preform faster or develop a better product than anyone else. Many times a developer will try to pad their resume using the 'latest and greatest' procedures instead of getting the job done as quickly and efficiently as possible. A project can double or triple from the time estimate if the lead developer leads you down the wrong path. Below is some advice on software architecture that might be helpful to a project manager. Convincing a resume padding lead developer away from an architecture that they want to try maybe be near impossible though. To them, bragging about implementing a new architecture to their online friends is more important than the success of the company. Below are a few technical gripes that may or may not have value to you:

In most companies software developers last about 2 years, much less if they're contractors. It's very important to have the luxury of bringing in a new developer and have them contribute from day 1. If you decide on a software architecture used by only 5% of the community, you either throw away 95% of the resumes you get for a new hire, or have the new hire spend 1 month learning the new system. It's one of the reasons I moved from Java to .NET, but I not going to get into that debate here.

Most of all, keep it simple. I always find the more files, the more problems. It might sound nice to have this fancy MVC architecture, but does each web page need to have 100 different files associated to it? In most cases, it's a website that accepts requests, fetches data from the database and displays it on the page. It's not rocket science. There are some exceptions, but if the common architecture of your programming language doesn't meet the requirements for your project, change your programming language.

Also be careful not to use too many 3rd party plugins. Maintenance, deployment time, and updates can add time to your development and increase the odds of errors in your code. Just make sure you really need to use them and you're not just trying to pad your resume.

ORMs - Sometimes there are instances where using an ORM can be very useful and have major advantages. Most of the time however, it really doesn't make a difference. If the ORM is built into the programming language and IDE, it can speed up development time for some people and I'm not that opposed to that. In this case, it's usually easy to learn and doesn't cause many problems if the configuration is ok. 3rd party ORMs have always caused additional problems, bugs, and extended development time in my experience. Again ask yourself, do you really need a 3rd party ORM, or are you trying to pad your resume again?

I try not to use an ORM and usually pass my result set into a .NET datatable or dataset. It's personal thing, but I like to call the database directly to open, close, and query. I also don't have to wonder, "Is it the ORM language statement, or bad data in the database that caused the error?"