You are here

Advice To My Fellow Techies

After spending a fun couple of days unraveling a mess inherited by a prior co-worker, I will share a few observations that I have made over my career.
Simple and functional that meets the business need wins!
We get it.  You are smarter than the rest of us.  You can do many different things inside of one statement that would take other mere mortals many.  I call this "Too Smart By Half".  Since everyone prefers to create, not maintain, your complex monstrosity will not be a perpetual reminder of your grandiose skill.  It will ultimately be maintained by someone who a) doesn't understand it and b) will undoubtedly break it.  Someone will have to come along and decompose it to its constitutent parts and be using every insulting adjective to describe your parents marital status while they do it!
You are not your title!  You are not a Developer.  You are not a Tester.  Your are not a BA.  You are not a Manager, ScrumMaster, Architecture, etc.  You are a Value Adder!
Most companies don't pay for "code" or "testing" or other SDLC activities (unless you happen to work for a software vendor).  Even they really don't (as you will see).  They pay you for adding value to their initiative.  Your work is the means; not the end.  The end goal is to produce value that someone will want.  It is easy to find (and replace) task-doers.  Organizations are looking for  those who can add value.
The world does not need any more applications, websites, and products that suck!  Make sure yours is not one of them. 
Whether you are a seasoned professional or a the most junior of interns, we have all used software that just made sense when you picked it up.  We all know what good usability means because we have all encountered stupid implementations  and frustrating interactions that were not intuitive.  Behind every painfully obtuse technology interaction is a developer or team of them that decided the steaming pile of cow dung was "good enough".   As a corollary, you are better off implementing part of a solution that really works well than a "complete" solution that is unusable.
Finally, anybody who suggests implementing a partial solution to meet a release that you will "fix in a subsequent version" is lying.  If you are saying it, you are the liar!
The utility that will be used "once to migrate data during the release" will undoubted become the permanent replication solution running daily with your suboptimal data model.  If your solution to authentication in your first release is to grant "admin" rights / roles to all Users in advance of implement security later, don't bother.  Save yourself the time and argument by accepting that there will not be differentiation of the Users.  Regardless of your intentions, you will never have more Unit Test coverage in a subsequent release than you do on your first.  You will not create the User Documentation later and, frankly, if you would build good software that was usable, it would not matter.  Children pickup iPhones and are destroying buildings with cartoon birds in less than five minutes.
I only share these realities because there are two types of people in the technology arena.  There are those who are lucky enough to create software and applications and there are those who end up inheriting the crappy results of their grandiose plans!
Feel free to add other "advice" in the comments or let me know if YOU are the exception to the realities that I've shared above.