This is a good and short article written by Joel Spolsky about what makes a quality software team:
http://www.joelonsoftware.com/articles/fog0000000043.html
His test is simple and to the point. I like that!
Thanks - vers good read! Point 5 made me giggle and groan at the same time:
- Do you fix bugs before writing new code?
Spolsky is often interesting. This time, he might very well have spilled the recipe for the ObamaCare website. 7 of his 12 suggestions here are just plain bad ideas for teams with fewer than 20 contributors.
Why is #7 Do you have a spec? not #1?
How can you design anything… let alone code it… .without knowing WHAT you are designing?
Reminds me of a time when I was in a design meeting with internal customers… lots of discussion was taking place about what the project needed to do, what the end user workflow shoud be and so on. I sat there listening, making comments and suggestions… Finally the meeting is over… and the Project Manager looked at me and said “Dave… you are the lead architect on this project… but I see you took no notes at all during this presentation… may I ask why?” To which I responded. “This is one of many discussions that will take place before you (Business) finalizes what you want/need. So why should I take notes on a changing environement, when in fact you have to provide me a BSD (Business Spec Document)… which will in fact encompass everything I needed to have taken notes on?” He never asked me that question again.
This got posted in another thread
Creeping Featurism - one of the deadliest disorders known to software.
In my previous life building funds transfer applications for the bank, my manager was pushing a book that said the first thing that should be done when building a new system is to write the user manual and have the users sign off on that. It was a good idea (seriously!) but the users never signed off on it!
Back when I was a Software QA manager I was at a company where I actually had to fight to get testers integrated into the developers’ teams. Before that, testing was treated as an afterthought - a necessary evil. I actually had one development manager accuse me of being melodramatic and insisting that his" developers write code, not bugs". During my tenure there, we took the company from department teams to project teams where all of the departments had people included in the team. By the end, even the customers were praising the product improvement,
As a developer, tester, and software manager I have seen most of the sides of the issue and must say, I agree with almost everything Joel said in his article.
On a side note, but relating to the item of having interviewees write code, I once lost out on a job where I was asked to solve a simple programming problem. After a moments thought, I created a solution and presented it to the interviewers. One of them commented that it would work but then asked if I could find “a more elegant solution” (his words, not mine). I probably ticked him off when I asked, in return, “Do you want an elegant solution or one that works?”
I’ve done that with a team
We had professional writers, user interface designers etc all get together with users & do the whole user manual before a line of code was written
THAT was the best experience I’ve ever had writing software
The company I started out with never had “IT” in the conventional sense - accounting had their own small IT team, etc.
There were some shared resource teams like DBA’s network infrastructure etc.
So I learned way more about accounting & payroll than I ever cared to learn - enough I ran the job costing for a while when their analyst quit then I trained the replacement.
Projects that crossed departments were of douse made up of member from all these smaller IT teams.
It worked really well for people getting to know the various lines of business
Had drawbacks - they all do - but users never had questions about whether we knew their business as we literally shared offices with them & knew their work inside & out.
Had users become IT folks & IT folks move into the line of business it worked so well
I would have laughed out loud at that statement. But I know the feeling. Most of the managers I’ve worked with have treated testing as an afterthought. It’s difficult to make them realize that modern computers are actually more complex…more parts and more complicated interactions…then the Saturn V rockets which put man on the moon. The difference is that computer crashes are virtual, not physical, and typically don’t kill people. Though that’s a possibility where computers control planes, power plants, medical devices, etc.
Beyond a certain level of complexity there is no such thing as designing an error free system without thorough testing. At some point there’s simply no such thing as error free, only thorough testing and a reasonable likelihood of functionality. We are far past that last line in computing. Multiple layers of software abstract and hide much of the complexity so that we programmers can actually accomplish something. But it’s still there.
Though some steps aren’t applicable to a single coder or very small team, Joel nailed it in that blog post.
[quote=51143:@Norman Palardy]We had professional writers, user interface designers etc all get together with users & do the whole user manual before a line of code was written
THAT was the best experience I’ve ever had writing software[/quote]
It’s nice when you have a firm spec like that, isn’t it? Too bad all projects couldn’t be like that.
Nothing changed since Wednesday, August 09, 2000 ?
Yes, the article was published more than 13 years ago.
Hey, my memory is not that bad !
[quote=51250:@Emile Schwarz]Nothing changed since Wednesday, August 09, 2000 ?
Yes, the article was published more than 13 years ago.
Hey, my memory is not that bad !
[/quote]
Yahtzee! I knew there was a reason why I thought the recommendations sounded dated. For a more contemporary view of how good software is actually done, check out Clay Shirky’s take-down of the ObamaCare website:
http://www.shirky.com/weblog/2013/11/healthcare-gov-and-the-gulf-between-planning-and-reality/