{"by":"ThrowAway1q","descendants":16,"id":3420115,"kids":[3420237,3420259,3420243,3423182,3431072,3423263,3434136,3420195,3443465,3443732,3423900,3443305],"score":9,"text":"I co-own a small software company. As a small business, Time to Market is critical. We are constantly making the tough decisions between doing things quickly and doing things \"the right way\".

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.\nOptions: a) Store as plain text or b) 1-way encrypted.\nBenefits 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 \nentries 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.","time":1325607644,"title":"Am I a douchebag micromanager?","type":"story","url":""}

ThrowAway1q

Recent submissions

Am I a douchebag micromanager?