

Am I a douchebag micromanager? - ThrowAway1q

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".<p>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".<p>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.<p>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.<p>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.<p>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?<p>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.<p>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.<p>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.<p>I thought the answer to these issues were obvious and "no brainers", given our emphasis on "Time to Market" and Quality products.<p>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.<p>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.
======
samlev
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.

------
kls
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.

------
Rust
#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.

~~~
spp
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.

~~~
huxley
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).

------
jtchang
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.

~~~
huxley
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.

------
JS_startup
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.

------
Khelvaster
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.

~~~
perspective
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.

------
malux85
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.

------
remyroy
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.

------
loupgarou21
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.

------
Jacquass12321
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.

------
clyfe
#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)

------
lmm
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.

