Do you record historical data of past projects for use with Software Estimation techniques?
Or in short:
Do you measure?
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:
I would replace most of these with one simple question:
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)
(Think Bangalore and San Jose -or- New York and Moscow)
A few more checks ā¦
Do you measure compliance with regulations including:
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 ā¦
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