Am I a douchebag micromanager?
I recently had several encounters where this conflict boiled to a head with the lead developer of a new product. I insisted that things be done a certain way, given Time to Market constraints. I was accused of "micromanagement".
Below are three scenarios where conflict arose. Decide how you would design a solution, and then tell me if I am being a douchebag for my insistence on a certain design.
Here's a generic description of the application: A HIPAA compliant web application for patients to use. Planned development is in .NET, with SQL Server back-end.
Design decision #1: How to handle user passwords. Options: a) Store as plain text or b) 1-way encrypted. Benefits of plain text are - simpler administration, easier for us to pose as a user to duplicate problems, easier to set and reset passwords. Downside: Security. Benefits of 1-way encrypted: security. Downside: harder to implement, harder to administer.
Design Decision #2: We are recording user's scheduled events in the database, each of which has a date/time attribute. Since users could be from different time zones, there's a question of how the date is stored in the database. Say the server is in Eastern Time, and the user is in Pacific Time. Jobs will be run on the server, based on server time. Users want to see their information displayed in their local time. The question is, how do we store the dates and times?
Here are a few options: a) always store it how the user entered it. b) always store it in local time, and convert it when you display it. c) always convert it to UTC, and convert it when you display it. Each has its pros and cons. When selecting a solution, remember to consider Daylight Savings Time, and the fact that not all users will be in zones that implement DST. Consider ease of management and troubleshooting, ease of implementation, and the fact that we have to run server jobs that compare against the time.
Design Decision #3: Recurring Events. As mentioned above, events are entered into the web application. They can recur. The question is, how do you store recurring events? Imagine that a user displays May 2012's calendar - then they should see individual events and recurring events that fall in that month.
Two options are: a) Have a SQL table of events, and expand all recurring events to be individual entries in this table. (Note, for infinitely recurring events, you have to implement a stop date, and advance it periodically, perhaps with a daily job.) b) have two tables - one for individual events, and another for recurring events. Merge the results when you display.
I thought the answer to these issues were obvious and "no brainers", given our emphasis on "Time to Market" and Quality products.
Am I a douchebag for Dictating that we do the following: encrypted passwords; use SQL's datetimeoffset (store in UTC), then time zone issues are addressed for you; use a separate table for recurring appointments - better yet, use pre-written code, like DDAY.iCal which has recurring appointments already implemented.
PS. If I had my way, this would be done in a more popular framework, not .NET. I'd choose Python/Django, but I am open to feedback on that as well.
16 comments
[ 5.6 ms ] story [ 50.0 ms ] threadThe right solutions are often the fastest ones too.
Yes, all those solutions are no-brainers. Micro managers aren't the ones who dictate how parts of the software should be written (especially in these cases - you have legitimate reasons for your chosen solutions); they're the ones who sit there constantly asking a developer "What are you doing? What are you doing now?".
I have had micromanagers in the past, and it's not fun, but there really is a difference between a manager making clear decisions, and one who's messing with a developer.
Seriously, though, if you have a lead developer who thinks that storing plain text passwords is a good idea (ESPECIALLY in a piece of software that has to comply with HIPAA standards), you should probably put him out of his misery, and out of your code base. No amount of "simpler administration" is worth plain-text passwords.
#2 - Dates should be stored in UTC (make sure the server has the timezone correctly set), and display in the user's TZ or a reasonable default. The language will worry about DST. Don't let SQL touch it (in fact, you should probably store a UNIX timestamp - uint - instead of a datetime).
I would argue the above as "best practice" for storing that info. The douchebag is the developer who won't spend 5 minutes implementing either solution.
So please, do use hashes for this, just realize that some hashes will be far more secure (like bcrypt) than others (like SHA1 or, FSM-forbid, MD5).
The decisions you are making seem reasonable. A developer should see this. I mean seriously...you are arguing about whether to hash passwords?! These days it is near mandatory and any framework/library will assume you are doing so. Django definitely does it by default (I personally replaced it with bcrypt). It would be MORE work to implement cleartext passwords.
I really like the approach Django 1.4 is taking. They have a new default hashing algorithm: PBKDF2, but they've also made it easy to choose your own.
You can upgrade hashers at any time by changing the order of the PASSWORD_HASHERS setting, every password will be upgraded on a successful login. Using bcrypt is as simple as installing py-crypt and changing the top choice in the PASSWORD_HASHERS setting.
Increasing the work factor for the hashing algorithm is also really easy to do so: create a subclass of the hashing algorithm you want to upgrade, set the multiple you want to increase the iterations by (say 100 times more), then add your subclass to the PASSWORD_HASHERS setting.
Like you said, it is more work to implement cleartext passwords.
Going back to the OP, when it comes to:
"easier for us to pose as a user to duplicate problems"
I'd say that in cases where you need to access a user's account, it's probably better to allow superusers or staff to "login as user" using a different mechanism than the normal password login/authentication.
As advice, use ASP.Net MVC3 rather than the classic web forms if you have concerns about maintainability/performance. It "feels" a lot more like Django or Rails than it does like Windows Forms, but you still get the performance and development benefits that .Net has to offer.
Also, for a CRUD application like yours, there's little reason not to use Entity Framework to manage your database. I've saved countless hours myself by not having to write SQL or manually keep database tables up to date with classes as code changes.
My only negative comment about ASP MVC is that WebForms requires very little code to create a sexy interactive expanding/collapsing databound table whereas you seem to have to write a lot of code to do the equivalent in ASP MVC (v3 at least...) There are however some great libraries out there like jQuery MVC Grid (http://jqmvcgrid.codeplex.com/) which fill in these gaps. With the current speed of development, it is surely only a matter of time before WebForms becomes obsolete.
2) A more popular framework than .NET? Really?
.NET has built in membership providers which means the encrypted password should be a non-issue. If your lead developer is rolling their own login system then they shouldn't be your lead developer.
The timezone issue and recurring events are also no brainers. I don't think you're micro-managing at all, you're just trying to avoid horrible design decisions which will hamstring your application down the road.
#2 UTC, option 3
# use existing code where possible, this is something that's been done a million times
You're not a micromanager ... (I think) a micromanager is someone who stands over the dev's asking irrelevant questions, or offering unneeded opinions, or actually telling us how to implement (not what to implement)
I wish my manager was more like you, because it's clear you understand the importance of making the right architectural decisions. Fire your lead dev and hire someone who binds with you better.
micromanaging would be you insisting on being included on parts of the design and implementation process that don't really require your input.
Are you so involved in the coding process that the only point of the developers is that they're doing the actual typing? If so, you're micromanaging.
The three examples you gave are not examples of micromanaging by themselves.