Am I a douchebag micromanager?
12 comments
It sounds like your lead developer is possibly out of his depth.
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.
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.
In my experience it can be hard for some developers to link their craft with the larger business. Some times helping them understand how the money side of the business works, helps them to understand that the choices they are making are not being done in a vacuum. Especially if you can show them how, a longer development duration can seriously and adversely affect the company. Now where most developers will rightfully get perturbed is when managers want it done fast and don't want to cut or simplify the feature set. You look like you are doing just that, so given your side of the story I would lean to side with you. The other thing to remind them is that you guys can go back and improve those areas once the crunch is over, just live up to your word and support them going back to fix it afterwards. Constant crisis mode sucks and if a developer cannot double back and clean up some unsavory bits that are going to become frustrated as the technical debt grows. Make sure you pay it down.
#1 - ALWAYS encrypt passwords, no exceptions. Implementing SHA1 salted hashes is trivial.
#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.
#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.
Please don't use hashes for this. Use bcrypt (http://en.wikipedia.org/wiki/Bcrypt). Hashes are designed to be easy to compute, bcrypt is adaptive in the sense that it can be made harder to compute over time, so it's a lot harder to brute force. It also adds a salt by default.
I know I'm being a bit pedantic here, but both bcrypt and SHA1 are cryptographic hash functions.
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).
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).
Micromanagement to me is when the manager keeps asking too many questions that really don't matter.
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.
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 agree totally, this is an area where frameworks should shine.
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.
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.
1) Your developer is way out of his or her league
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) 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.
I'm hard-pressed to accept that .Net isn't a popular framework.
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.
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.
Yes, MVC3 the way forward. I've spent the last year pulling together my minimum viable product with MVC and choosing ASP MVC 3 has to be the best decision I've made.
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.
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.
Sweet Jesus, I would fire a developer who didn't encrypt passwords.
#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.
#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.
Your decision are the right ones. Any experienced developer would chose those. In my humble opinion, they are faster to implement than the alternatives.
The right solutions are often the fastest ones too.
The right solutions are often the fastest ones too.
These examples really won't give a good idea as to whether or not you're micromanaging.
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.
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.
When I was reading this post I was really expecting it to be a troll after reading decision #1, I figured at the end I'd read that you wanted A,A,A. Now I'm just left reconsidering my own title and forced to agree with other posters that these aren't even decisions you should be involved in, and no one who made those choices should be a project lead.
#1 always store passwords encrypted
#2 UTC in DB, convert to TZ in UI
#3 store recurring events only once with recurring meta-information and deal with it in the query implementation and business logic (do NOT use separate table with crons and from time-to-time expansion - that's leads to technical debt)
Many commenters are saying your decisions are right. That's true enough, but they shouldn't be your decisions. If you can't trust your lead developer to make these kind of choices correctly, what the hell are you paying them for? Live with the mistakes, or find yourself a better lead dev.
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.