developer – In Search Of

A Proliferation of Architects

Posted on May 12, 2015Leave a comment

One of the things that I have observed over the course of this century is the transition away from traditional “Data Processing” titles like programmer, programmer analyst, systems analyst, etc. The key evidence of this trend is the proliferating of self-aggrandizing titles involving the term architect. In 1985 when I graduated, I don’t remember every hearing of a software architect or a network architect, or God forbid an enterprise architect or an application architect or a solutions architect or any such thing.

I suppose it started with the transition from Mainframe style computers toward what we now refer to as distributed systems. First everything was mainframe and dumb terminals, then it was PC’s. Then it was networks of PC’s and Servers. For a while it was Client/Server and then multi-tier or n-tier and finally the generalization of the term distributed systems. Different computers doing different parts of the work in different places, mostly by “collaborating” with each other.

The programmers who worked on distributed systems had much more diverse titles. They were software developers, application developers, database developers, user interface developers, and with the advent of the internet and the world wide web, there were web developers. Back in the day, there were programmers who worked on the internals of systems that no user would ever see. Those people were called systems programmers, now in the age of distributed systems, their new self-aggrandized title was software engineer! Then as these servers and n-tier platforms started to become more complex, every server product needed a dedicated administrator so the unix operating system need a unix admin and the database needed a database admin and pretty soon we had java “containers” that needed their own admins. The networks that connected all the computers together needed administrators and pretty soon the whole thing got very complicated.

As these systems grew more and more complex, we started to realize that the genius-wizards who were good enough at their job to be able to see the big picture and to help us straighten things out when they got wrapped around the axle deserved a special title “Architect”. This brings me to the ultimate question for this blog post:

“What the hell does an architect have to do with information technology?”

Learn To Code – Now

Posted on January 20, 2015Leave a comment

I recently spent some time working my way through “Learn Python The Hard Way” by Zed A. Shaw. Zed is a programmer who has accomplished more than most in his short time on Earth. He is outspoken and often edgy, and has a reputation for being both brilliant and blunt. Zed is the creator of the Mongrel server engine that powers many Ruby on Rails sites.

Zed comes off as a Hard Ass, more than anything, and his proposed methodology to learn programming is hard, as in hard assed, not hard as in difficult. Learn Python The Hard Way is old school. Which is good, because I am old. It reminds me of learning Fortran in my freshman year of college in 1980. Hollerith cards. 039 keypunch machines. All batch processing. When you are dealing with “physical” cards, and physical sorting of program steps, and waiting an hour to see if your code compiled, let alone executed to completion or got a correct answer you tend to do alot more “desk checking” than we do today. That is the thing that I like about LPTHW is that it teaches some technique around old school desk checking. Like reading your code backwards to find errors, something that we often did on green bar paper at a table at Helmut’s Alpine Kitchen at two o’clock in the morning with a pot of coffee and an order of biscuits and gravy.Continue Reading

Design Philosophy And Coding Style

Posted on September 24, 2013Leave a comment

Caution, Rant Alert!

In my career, I have been some kind of leader on about a dozen new application projects. It is interesting to me that the only time I have ever heard about “design philosophy” or “coding style” is when some new developer comes on a project and gets his butt handed to him in a code review. Specifically, what I hear is a defensive posture which sounds like an excuse for code that is not a good fit for purpose or consistent with the surrounding application.

In a prior post HelpingTheTeam I talk about some new developer problems. This is another, perhaps less common issue.

Here is a list of bad coding practices that I have heard defended as “design philosophy” or “coding style” and why they are neither philosophy or style:Continue Reading

Helping the Team

Posted on May 15, 2012Leave a comment

Perhaps you have experienced the struggles of on-boarding new developers into an already large team in the middle of a project. Everybody who comes wants to have a say in how things are done, no matter how late in the process they get involved. Here is a litany of the types of commentary that I hear in this situation:

On my last project we used <insert product, pattern, or practice> and it worked great. We should certainly use that here.
We don’t need <insert pattern, product, or practice> its too <insert adjective>.
Why don’t you just <insert suggestion>.
The code-base is in a bad state because <cite example>.

Each of these commentaries were delivered, without necessarily an understanding of the choices that were made by the team to get to this point, nor with a full understanding of the work remaining. I sincerely believe that each developer made the comments in a spirit of trying to help the team. I also believe that each of these comments reflects the developer trying to construct a “familiar” environment where he knows how to deliver value.

Here are the problems with this:

Commentary rarely reflects a problem statement before offering a solution.
Commentary rarely exposes the cost (in effort and risk) of adopting the solution.
Commentator may or may not have the experience or skill to lead the team through the adoption of the solution.
Commentator may or may not have thought through the solution to the ultimate conclusion – to determine whether it is feasible, valuable, or reasonable within the context of the project.

I attribute these commentaries to each developer’s on-boarding process, and their process of “mourning” the familiarity of their last engagement, while also trying to understand the current environment.Continue Reading

Heard in the Aisle

Posted on April 10, 2012Leave a comment

Over the last few weeks I have overheard a couple of things that really tickled me, because of their brutal portrayal of some business truism, and because of the skill of the speaker in articulating:Continue Reading