What is "Modern Software Development"?

Do you record historical data of past projects for use with Software Estimation techniques?

Or in short:

Do you measure?

Testingā€¦ what is testing? It sounds like a swear word.

Another problem with this is it doesnā€™t scale up. I have mentioned this before, but even the agile zealots will admit that an agile approach just wonā€™t work for projects that are millions of lines of code.

Ummā€¦ you obviously havenā€™t talked to many agile ā€œzealots.ā€ Obviously there is no silver bullet, but I am a firm believer that ANY project will benefit from most of the concepts. Not every concept is appropriate for every project.

Read Kent Beck, heā€™s pretty modest about agile in v1 of his Extreme Programming Explained, but in the 2nd edition he makes much bolder claims.

I agree that unit testing is highly important. And unit tests become even more useful, if you run them automatically on a regular basis. as a result youā€™d want a central source repository, automatic builds, but most important:

You must keep your code working at all times.

Maybe thatā€™s an item to add to the list: ā€œDo you have a working product from start, and keep it working at all times during the project?ā€

overtime! do you (not) work overtime?

Obviously there is no silver bullet, but I am a firm believer that ANY project will benefit from most of the concepts.

Which is a little tricky:

  • Some of the tenets of XP are incompatible with many projects (such as on-site customers, frequent releases, minimal design, pair programming).
  • Not everyone thinks the XP approach is an improvement on what was done 10 years ago.

I would replace most of these with one simple question:

  • Does anyone on the team fully understand the problem?

If you canā€™t answer yes, then source control, automated tests, code reviews, etc. arenā€™t going to help much.

And I donā€™t believe that having a product spec is a replacement for understanding the problem. I doubt that most people can really build a working solution based solely on a product spec (at least Iā€™ve never seen one that was thorough and clear enough to do so).

Iā€™m still having trouble pursuading people to use Source Code Control, let alone all the other points raised.

We still have a long way to go where Iā€™m living before those lists are considered by the mainstream as anything but ā€˜fussyā€™ and ā€˜adding to cost and development timeā€™ (oddly, the latter is the opposite of the truth, but few managers believe that).

There are a number of reasons behind this attitude, which are too long to mention here, and make it hard to do otherwise. (and another reason that I really need to write my own blog articles rather than reply to other peoples, sigh).

ā€œDo you follow agile methodologiesā€

Ah, that question just translates to ā€œis your process up-to-date with trendy buzzwords?ā€.

Focus on what people actually do, rather than which development religion they belong to.

Do you follow a Coding Standard?

Having and following some kind of coding standard is key. Per McConnellā€™s Code Complete, while there are better/worse standards, generally any coding standard is better than none.

I tend to agree that:

Do you use and maintain unit tests?

is another good candidate for list. The only problem I have with this one is that unit testing is not a substitute for writing good code. Relying on unit tests to ā€œtest inā€ quality is a bad practice. It is clearly better than not unit testing at all, but you hope your unit tests are used for verifying you have good quality at each unit, and are not a mechanism to assist in obtaining correctness.

I am not sure the best way to capture the notionā€¦but whether or not you are doing unit testing, if there is any part of your project code that just about anybody on the team would not be willing to sit down and examine and then make changes to it without lots of trial and error, then you are doing something wrong!

ā€œDo you follow agile methodologiesā€

Another problem with this is it doesnā€™t scale up. I have mentioned this before, but even the agile zealots will admit that an agile approach just wonā€™t work for projects that are millions of lines of code.

Have you removed every last error message from your user interface?

About agile methodologies: thereā€™s a lot to like about them, but they are again no panacea. There are many situations where you would not dream of using them (like writing space shuttle software). Alistair Cockburn has a matrix that determines how heavyweight a process is needed, based on the team size and the size of potential loss due to system failure (e.g. loss of time, loss of money, loss of life). I propose that there is another factor that needs to be considered: volatility of interfaces.
When you are architecting a large system that presents many interfaces, especially external interfaces, you canā€™t blithely say that if you donā€™t need it right now, youā€™ll put it in sometime in the future. Quite frankly, as with writing software libraries, if you donā€™t get your interfaces right by the time you release the software, you are S.O.L. because the interfaces are now cast in concrete. Once you have a large user base out there you canā€™t just decide to refactor and rearchitect because you didnā€™t get it right before releasing it. You will face a revolution in your user base, unless your user base is so captive that all they can do is grumble and shake a fist at you. A case in point: Microsoft changed the Windows API many times in the early days, and it cost the world a huge amount of grief. Not that MS Agilists; far from it. At the time, they were little more than cowboy coders, but the principle holds.
I am not saying that Agile methodologies are bad - on the contrary. In many cases they are just what you need. Just use them when applicable.
One poster said that you must have detailed and well-written requirements documents. Well, I have news for you. In many of the jobs I have had, that was just not possible because (a) very, very few people can write a really good requirements document (b) the end users/stakeholders often donā€™t know what they want up front, and they often donā€™t even know what they know, so it takes a highly skilled analyst to get the details out of them Ā© there is such a lot of pressure to get a project going that not enough time is given to do this, and (d) the information superhighways are littered with the corpses of projects that tried to use a waterfall methodology, which is what I think of when I read about having complete requirements up front.
I mean, yeah, Iā€™d love to have great requirements docuemnted up front, but in reality? I have seldom seen it happen. If you get anything, itā€™s a stack of documents that are so inconsistent, and missing so much necessary detail, that you wind up interviewing the users yourselves, and doing an evolutionary delivery of the system. By all means, if you have a crackerjack business analysis team that can nail 99% of the requirements, thatā€™s great. Many of the rest of us donā€™t.
So, as people like Steve McConnell recommend, adopt the development practice that is most suitable for your particular project. If thatā€™s an Agile, low-ceremony practice, great; if itā€™s a heavyweight, high-ceremony process, well, thatā€™s what is needed. The only general certainty I have is that of the systems I have worked on in the past 20 years, only those that were developed using a model based on iterative development and incremental integration were truly successful. Some had comprehensive upfront requirements; most didnā€™t.

One important difference from even just 5 years ago ā€¦ (esp. for small companies)

  • Does your development methodology work well with people in opposing timezones?

(Think Bangalore and San Jose -or- New York and Moscow)

A few more checks ā€¦

  • Do all locations have VoIP (Skype)?
  • Does everyone use some webmeeting (VNC)?
  • Does everyone use IM software that logs all chats (Trillian) ?

Do you measure compliance with regulations including:

  • Retention and versioning of requirements
  • Testing and test results
  • Approvals
  • Bugs and work requests

Iā€™m amazed that nobody proposes the following:

ā€œDo you usability test often?ā€

Usability testing is cheap if you keep it simple (and follow Steven Krugā€™s advice). And it helps guide software development of features of uncertain metrics such as the GUI to the right track.

I agree to whatever mentioned in the top of this mailing list. In fact, we try to follow them as far as possible for small team.

I depend on following ā€¦

  1. Comprehensive realistic schedule
  2. Weekly tracking
  3. Bring up close risks as early as possible.
  4. update everyone (who are party to this project) about the status.

Do you reuse components from earlier projects in order to speed up software development?

Where I work, the motto is:

When in doubt, rush it out.

Jeff can you take care of reorder every one input either on a reply post or a new one, I belive that doing such act could create a community, that urge such a list on each dev houses