Meeting Smells: Three Things That Should Not Be Said in a Software Requirements Meeting
I've started thinking about a set of phenomena I've termed "meeting smells". These are like code smells, except they happen during meetings. If you notice one, it's likely something is going awry with your get-together. Feel free to send me the smells you've witnessed, and I'll add them to the list.
To start things off, here are three phrases that, when uttered, are almost a sure sign your requirements meeting has taken a turn for the worse.
- Table
"We can make a new table in the database to store this"
Software engineers LOVE this one. Give us a hard problem, and our brains dart to the database like it's a digital comfort blanket.
This is because we often think of solutions as "starting at the database". This is bad because (say it with me)... the database is NOT the application. The details of the database like table structure, are part of development. If you aren't slinging code, you shouldn't be talking tables.
- We WIll
"We will be responsible for the reporting piece of the app."
Make no assumptions about which team will be doing each part of the work. If one system has handled a particular kind of task in the past, there's no reason to assume it's the best thing to do the job this time.
- It Will Be Easy
"Oh yeah, we do LDAP authentication on our sites now, so it will be easy to do the same on this application."
If you haven't yet eaten these words, give it time. This is the core of missed deadlines, scope creep, cholera, and lots of other bad stuff. Something seems simple at first, but ends up way complicated.
Once you utter the E-word, everyone assumes that "easy" means "instant", and that there is absolute certainty the feature will be built. You're setting yourself up for failure. Ego kicks in and you end up taking tons of time to build the "easy" feature that has become a beast of complexity, and steals time from other features.
2 Comments
Leave a comment
The following word shouldn't be used unless *you're* the one saying it, and *you're* doing the work.
word: "JUST"
BAD
---
Business Owner: "You just need to take the bottom half of pageB and move that functionality to pageA. That should just take a day."
Oh really? *just* take half of the functionality of a core page that is deeply entrenched in living where it does (for a reason) and *just* make it work on a totally unrelated page. Great, it will *just* take 6 months.
GOOD
----
Developer: "I just need to make a few minor tweaks to make commenting work on pageA AND pageB. I can have it done and tested in a day."
You're doing the work, and you know the system best. If you're confident in saying this, and it's realistic, then this is a good use of the word "just".
Sadly, I find myself being the culprit of using "just" when speaking of someone else's tasks. I will most often catch myself and verify the validity of my statement right after I say it. In most cases, it isn't fair to speak for somebody else.
Yep. I think that hits the nail on the head. In those initial meetings, any statements of how difficult or complex should be left to the builders and not the askers.
Often, something that sounds easy is actually hard due to legacy reasons.