Can you still be technical if you don't code?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/can_you_still_be_technical_if_you_dont_code.htm]

Can you still be technical if you don't code? A lot of developers have a passion for the technology, do a great job in their current role of implementing solutions (which requires coding), and then get "promoted" into some "big picture" role that no longer does implementation - ironically the thing they did so well at. These higher-level roles often do lots of non-trivial things, but not actual coding. For example:

• Infrastructure (Servers, SAN space, database access, network access)
• Design decisions
• Dealing with legacy code
• Handling outsourcing, insourcing, consultants
• Build-vs-buy
• Vendor evaluations/score card; integrate the vendor's product into your own
• Coordinate large-scale integration of many apps from different environments
• Coordination among multiple product life cycles
• Writing guidance docs
• Code reviews
• Occasional prototypes
• Configuration

On one hand, these types of tasks require technical knowledge in that you wouldn't expect a non-technical person to perform them. On the other hand, they don't seem in the same category as hands-on coding.

What do you think - can you be technical (or remain technical) without actually writing code?

Reasons to NOT put version history in the comments

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/reasons_to_not_put_version_history_in_the_comments.htm]

Some coding standards ask that developers add revision history to the top of the method. Not just the normal "Summary" and "Parameter" tags that can be used to automatically create documentation, but rather a full blown revision log with developer name, date, and comment. This was bigger in the 80's and 90's, when source control and refactoring weren't as common. However, in these days, putting revision history in your comments has some really big problems:

• Extra effort - It requires extra effort from developers, and usually the tedious kind of effort. It requires manual developer discipline, so architects don't have a good way to enforce this.
• Bad for refactoring - It discourages refactoring of methods. Say you split a method in two - how do you split up the commented version history?
• Source control already provides this - It doesn't tell you anything that source control history won't already give you. But even worse, it could be misleading - source control is the true authority, a developer could accidentally type (or forget) the wrong comments. Also, by documenting at the top of the method, it is hard to indicate what changed in the middle (whereas source control diff would instantly tell you).

Perhaps for SQL, I can see the benefit, so that when the DBA runs sp_helptext on a stored proc, they get a quick history (and databases aren't usually refactored like C# code). However, for middle tier code, putting revision history in comments seems like an unwise use of time.

LINK: Comments as version control
 

What makes something Enterprise?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/what_makes_something_enterprise.htm]

There's a world of difference between a prototype hammered out over a weekend, and an enterprise app ready for the harsh world of production. Here's a somewhat random brainstorm. In general (there's always an exception), Enterprise apps:

• Are scalable - they handle large loads and can be called many times.
• Have a retry strategy - for example, it tries pinging the external service three times before "failing".
• Have a failover strategy, like an active-passive machine cluster for maximum uptime, and a disaster recovery site.
• Send notifications.
• Handles invalid data (like states, zip codes, and numbers).
• Can integrate with other systems (perhaps providing web service wrappers, or command line APIs, or publicly accessible data repositories that other apps can modify) .
• Are deployable - "it works on my machine" absolutely does not cut it.
• Have Logging - this is especially useful for debugging in production, or measuring how many errors (and which types) are thrown.
• Have long-running process (hours, days, or even weeks) - not just a single thread in memory.
• Have async processes, which usually means concurrency and threading problems.
• Support multiple instances of the app running. You can open two copies of word, or run two MSBuild scripts at the same time.
• Handle product versioning.
• Care about the hardware it's running on (enough CPU and memory).
• Have a pluggable architecture - You may need to switch data providers (Oracle/SQL/Xml).
• Have external data sources (web services, ftp file dumps, external databases).
• Can scale out, such as adding more web servers, or splitting the database across multiple servers.
• Have security constraints (both hacking, and functional).
• Have process that are documented (not just for training, but also for legal auditing and compliance issues).

Much of this code isn't the fun, "glamorous" stuff. However, it's this kind of robustness that separates the "toys" from the enterprise workhorses.

See also: Enterprise Data Access, Enterprise Caching