Month: February 2011
The Peter Principle says, basically, that people are promoted until reaching a level of incompetence. I think the reverse of this can be true as well: An employee may not be promoted because he or she performs very well in a given role.
This is just me talking, but I think there are a few problems with the way we view employment hierarchies in the software engineering world:
- Managers never knew software development
- Managers who used to know software development have been away from it for so long that they no longer know it
- Developers don’t know management
- There is no clear promotional path for the motivated software engineer
I’ve known a number of software developers who have either turned down promotion or given up a management role because they preferred software development. I suspect then, that the people left to do software management are either people who didn’t like software development or were not very good at it. This isn’t to say that they aren’t great managers (they may be), but it does lead to the possibility that the people in charge of software decisions may not be the best equipped to make those decisions.
Managers Never Knew Software Development
These days many large companies like to assign a PMP to a software project. This is an individual whose job is only to “manage a project.” The individual contributors of the team (software developers, testers, writers, etc.) don’t actually report to this person. The project manager’s role is specifically to work on timelines, track progress and ask the people who are working diligently to report their status (presumably for input into the timelies). If the company doesn’t have a dedicated project manager, this set of tasks falls onto the shoulders of some other manager.
What ultimately happens is that a lead developer will be tapped for all this information anyway, since the project manager, who doesn’t know software development and isn’t writing software, isn’t equipped to provide a meaningful level of detail in this regard. Interrupting a software engineer to ask his “status.” achieves nothing that a good project plan and appropriately used ticketing and version control system cannot.
That said, a good project manager is an individual who knows and understands software development and can provide project status details to upper management without constantly interrupting a team. I’ll take it a step further: I don’t think there is ever a need to have a project manager on a team who isn’t in some way directly contributing to team goals. This doesn’t mean that the project manager must also be a software engineer, but the project manager should be a product contributor. Creating timelines, scheduling meetings and asking people, “When will you be done with that?” is not a full time job!
Yes, we may need a “project manager,” but only if the amount of work is so significant that project management activities are warranted. A better model, in my mind, is to have the group manager, that person who is responsible for the project, have a working team lead for each subgroup. In many cases I think a single team lead of all activities (software, QA, documentation) can suffice.
Managers Who USED TO Know Software Development
Here’s something that annoys me to no end: For a software engineer to take his or her career to the next level, moving into management, seems to require giving up on ever actually engineering software again (at least in the workplace). Ironically, the very people who are required to be hands-off are also expected to make major decisions about software, while their software expertise dwindles. Software engineering is a unique discipline in this regard. As a friend of mine recently put it, it is one of the few careers in which those of us involved with it essentially learn all new stuff every 5 year years.
I find this strange because, in my experience, there very best software leader is not the MBA or the person who has never been a software engineer, rather, it is someone who is STILL a software engineer; Its someone who knows what is going on in the world of Ruby, Rails, Grails, Hibernate, Spring, JQuery, Clojure, , Git, Maven, etc. because he/she is someone who uses such things regularly. The manager whose most recent software engineering experience is a string as a Cobol developer on an AS400 years ago isn’t very well equipped to make assumptions about the effort involded with a web application, for example. 20 years from now I don’t want to be telling some junior developer how easy a project should be because “I wrote the same thing in Java in 2 days back in 2010.”
No Clear Career Path
What I’m getting at is this: A software engineer NOT have to give up writing software in order to move into management (even beyond the lead engineer role). On the contrary–I think it would be better if software management, from director on down, included actual software engineering.
This is a somewhat old article (2006), but it eludes to something that I have found a bit bothersome about attitudes regarding software engineering career paths.
I recently interviewed for a Business Analyst position with the CIO of a large multi-national software development firm. This man was in charge of the company’s worldwide IT operations, including offshore development projects, for which he was searching for qualified Business Analysts. The interview quickly became a casual conversation about current trends within the IT service sector, how the company was planning to take advantage of those trends, and, most importantly, how I could fit into those plans. It was during his evaluation of my skills that I asked how I fit and whether it was technical or business skills that were most valuable to his projects. The CIO summed up his advice about my career path with one small sentence: “Stay on the business side.”
The author goes on to state:
My job searches have suggested that business and systems analysts with a good programming background and a high-level of “business savvy” are becoming the next hot ticket. More and more organizations are finally hiring business analysts to explore, record, and recommend systems that fit the business—as opposed to the other way around.
While I agree with what the author is trying to say here, I think he missed the point. And the CIO quoted above is severely mistaken… Sure, you can train anyone to “be technical” and write a program, but you cannot train those people to do it well. There is a
big huge critical difference between a software developer and a good software developer. I first observed this in college, when some of my classmates loved working on programming assignments and performed very well on such things, while others fumbled through the simplest assignments, unable to get their code to compile, much less work.
Why were such people majoring in computer science? I’m not sure, but its probably because they thought they liked computers and would therefor like programming, or maybe because they heard it would make for a good career.
I don’t mean to pat myself on the back, but I (like many others in my field) didn’t realize that software engineering may be a good career until I was well into my Computer Science major. I started writing simple programs in the 6th grade, going to the library and checking out every single computer and computer programming book I could find. Later, after I had read all of the books that the small local public library had on the subject, I discovered Nibble magazine (also available at the library). Every good/great programmer I know is someone who landed in the career because it was something that he was drawn to naturally, and most of these people began at a young age. These are the people who write software because they like it, and this is why they are good at it.
Anyway, at one point, after being frustrated that my library didn’t have any more computer programming books to read, I found a strangely titled book that had been misplaced next to a book about Applesoft BASIC: The Peter Principle. I checked it out, if only because I thought the title was funny, and I took it home and read it–all of it! I was probably the only 7th grader in the world to ever read the book, which by that time was already very dated. The closest I had ever come to the corporate world by that point in my life was delivering newspapers. I was a fairly competent paperboy, and even if I wasn’t, failing as a paperboy doesn’t lend itself to a very clear path of promotion. That said, the wisdom of The Peter Principle was lost on me.
Little did I know that years later this strange book would be remembered much more vividly than the Applesoft BASIC book that I had checked out dozes of times.
The CIO, probably much older, wiser and richer than me, missed something major: Anyone can write code, but do you want just anyone making important technical decisions that can make or break your project, department or company? I didn’t think so either. Not just anyone can write good code. I’ve seen the results of software written by cheap labor… Indeed, I’ve rewritten code written by cheap labor!
I think there is a very obvious career path for software developers, and it doesn’t necessarily involve moving into a role that no longer includes hands-on software development. I disagree that upper management doesn’t realize this. I think in many organizations they do. I intend to write more on this subject…
Standard Subversion authentication using plain text user settings and passwords in the passwd and authz files in the Subversion conf directory. This is all fine for a very small installation on a localhost, but it doesn’t work very well in a work environment. Alternatively, SVN can be set up to use LDAP authentication. That’s okay too, but as a lead developer I’d like to have a little more control over the development setup and users. So, even better, its not too difficult to set up Subversion to authenticate using Unix accounts. I say its not too hard because there are some tricky things to contend with. Here goes.
1. Set up your Subversion repository.
I prefer a single repository for all projects, but this is a separate writeup.
2. Install Apache
3. Install Apache Modules
Okay, 1 and 2 were easy. Here’s where it starts to get tricky. We’re going to need a few things (and I’m assuming we’re using Redhat/Fedora/CentOS here). Some of these things may already be installed. Gcc (you probably already have this) and http-devel are both necessary. Http-devel (the development tools for Apache). This is required because we will be building a couple Apache modules. We’re also going to need to install an apache module for Subversion: mod_dav_svn.
yum install gcc yum install http-devel yum install mod_dav_svn
We need an Apache module for mod_authnz_external. There is no yum installer, so it will have to be downloaded and built (no biggie). Grab the tarball from here Building an Apache module is a little different than building other things… To build an install we use the apxs command (this was installed previously using yum install http-devel). So once the mod-auth-external tarball is downloaded we’ll do something like this:
tar xvf mod_authnz_eternal-3.2.5.tar.gz cd mod_authnz_external-3.2.5 apxs -c mod_authnz_external.c (build the module) apxs -i -a mod_authnz_external.la (install the module)
5. User Groups
Next we’re going to install a tool to handle the authentication part.
This is important: Before we install this tool (pwauth) we need to think about how we want to handle Subversion authentication. Do we want specific users to have access? Do we want to create a specific group with access? As a lead developer in charge of administering Subversion access, I recommend creating a subversion group, and call it something like “svnusers.” This is important because when pwauth is built we will have to provide it with a list of groups and/or users who will be allowed to run it (for security purposes).
Go ahead and add a user or two to this group.
useradd -G <user> svnusers
Now take a look at what the group ID of svnusers is:
This command will show all the groups that a user belongs to, and something like 501(svnusers) should be one of them.
6. Download, build and install pwauth
Pwauth is a handy program for authenticating a user against the Linux user db (/etc/shadow) that is designed to be used with mod_authnz_external. Download it and untar it and go to the directory where you untarred it.
In the pwauth directory you will see a config.h file. Open this up and make the following changes:
#define SERVER_UIDS 501 (or whatever the UID of your svnusers group is)
The SERVER_UIDS setting pwauth that anyone in the svnusers group can be authenticated. The MIN_UNIX_UID setting tells pwauth what the minimum user UID that pwauth can authenticate is. Leave this value out entirely or set it to 0.With this changes save it is safe to compile. From the command line:
After pwauth is built it is time to install it. There is no simple install script, so it is important to read the INSTALL text file that appears in this directory. Everything that you’ll ever need to know about installing pwauth is in this text file. A few important notes are: * pwauth is owned by root so that is has the necessary access to read the shadow file. So wherever you placed the pwauth executible, you’ll have to do something like this:
chmod o+s pwauth
7. Finally, we need to do some stuff to our Apache configuration (httpd.conf).
These are the modules that make the SVN and pwauth magic happen.
Later in the httpd.conf file we’ll create a VirtualHost specifically for serving up Subversion. Any client will use http:// rather than svn:// to access the Subversion repository. That said, I recommend using Apache Virtual Hosts to use different ports for different purposes (for example, plain old port 80 remains your normal http index and port 3600 can be used for Subversion access).
So in httpd.conf do something like this:
Listen 80 Listen 3600 NameVirtualHost *:80 NameVirtualHost *:3600 <VirtualHost *:80> DocumentRoot "/var/www/html" ServerName myserver </VirtualHost> <VirtualHost *:3600 DocumentRoot "/" ServerName myserver <Location /> DAV svn SVNPath /var/svn/repo SVNListParentPath on AuthType Basic AuthNAme "Restricted" AuthBasicProvider external AuthExternal pwauth require valid-user require group svnusers </Location> AddExternalAuth pwauth /usr/local/bin/pwauth SetExternalAuthMethod pwauth pipe </VirtualHost>
Restart Apache (service httpd restart). Now when you want to view, checkout or commit to the Subversion repo you’ll use an ip address something like:
And, of course, you’ll need to enter the username and password of a valid user who belongs to the svnusers group on the Subversion server. To check out a particular subfolder you would use http://my.host.name/project. Notices in the example above I made the SVNPath include the repo (/var/svn/repo). I could have made it simply /var/svn, requiring clients to include the /repo at the end of the URL. This is just a matter of personal preference.
8. One last thing: Back to the repository
That repository that you already created is owned by the user it was created as but it is now accessed via Apache, and we are no longer using the default Subversion authz settings. This means that if a client attempts to modify it (check something in), it will be done as the Apache user, and change are the Apache user doesn’t have read/write access to the repository. So you’ll want to do something like this:
chown -R apache.apache /var/svn
Notes: There are certainly other ways to handle this configuration, and it may be wise to make a few different groups (for example, svnusers, svnreaders, svndevelopers, svntechwriters and so on).
Here‘s a simple way to configure Subversion to authenticate a user using Unix credentials (through http) with Apache, pwauth and mod_authnz_external. Its not really rocket science, and its not anything that others aren’t already doing (the post is over 3 years old), but it certainly is useful.
I like authenticating Subversion users in this way because it offers a very convenient non-LDAP approach for a development group. It allows me to maintain the ability to add and remove users and access levels from any repository and do so using the same user accounts that are already present within our development environment. This assumes, of course, that users of Subversion have a user account on the Subversion server. There are a few hoops to jump through, such as adding the mod and pwauth, but nothing too severe.
There are some gotchas to be aware of when setting up pwauth, such as compile with the correct user access SERVER_UIDS and MIN_UNIX_UID.
Oh boy. Redmine has been forked now? There are many, many comments here, which I’ll be reading through. I’m a fan of Redmine, and I fully intend to continue using it.
There are certainly a number of alternatives out there, but the appeal of Redmine is that it is widely used, and as such, all the plugins you could ever ask for have already been created. I also like its high level of configuration and the fact that it works well for multiple projects (unlike Trac, which I loved until the day I saw Redmine).
I got a laugh out of a link I saw on the Jenkins CI page today: “Upgrading from Hudson?” Of course, I’ll be using Jenkins going forward, as it appears that most people in the community are already heading this direction (because Jenkins IS the real Hudson). Comparing the Jenkins CI change log to the Hudson CI change log, already we see that there is more activity on Jenkins.
I read somewhere, and I can’t remember where (so I can’t give a link), that Hudson CI is (was) the CI tool of choice for the Java community, with over 80% of Java projects using it. That’s a pretty large following. It will be interesting to see how this plays out, but my money is on Jenkins.
Of course, when creating software solutions in a corporate environment, most of us don’t intend to update our build server frequently at all. Its simply not feasible to do so.
Not that long ago a very wise coworker said this in a meeting:
The biggest lie in software is, “We’ll clean that code up later.”
Insightful. I admit, I’ve said this before, and, like others, I haven’t followed through. I suspect this happens often because, being busy developers, if a section of code works there seems to be no immediate value in refactoring it. It works, we have other things to do, and we move on…
I was thinking about the “biggest lie in software” again recently. This time the problem was a little different, but still something that I have come across numerous times.
I can’t recall the number of times I’ve been asked to put together a prototype or a very simple application for a temporary purpose only to find that the prototype/temporary application somehow morphs into a “real” application. (By “real,” I mean, people start using it daily in an ongoing manner that was never intended.)
This happened to me again somewhat recently, and I was very surprised when I was asked if there are a requirements document for the application (which I had spent all of a half a day putting together).
What’s the solution here? I’m not sure. Things move fast and everyone has needs to be met. Sometimes, even in the year 2011, people don’t really understand what software can do for them, so when they see a simple prototype or temporary application, they are excited about the increase in productivity that it can offer and they run with it.
I have a few more thoughts on this subject, but for now I’ll end with a list.
- Set expectations clearly. If an application is a prototype or throwaway, make it very well-known that this is the case.
- This is a little more difficult: Never write code with the assumption that it will be thrown away after demonstrable use or serving its temporary purpose. For example, I’ve created a few GUI applications that grow into something bigger. I used no real patterns or MVC layout–I simply threw something together using AWT and Swing in NetBeans. Its full of global variables and improper forward and backward class access to methods and values that should probably be private. If any real software developer were to look at the code I would probably blush.
- To pull off #2, write your own code with reuse in mind. That temporary application is likely to be useful when implementing our full-blow project.
I’m writing these rules as if I follow them myself. To be honest, I don’t always do this. Sometimes there are a number of groups tugging developers in different directions, and its difficult engineer something both appropriately and quickly all at once. That said, we shouldn’t be surprised when that throwaway application we whipped up one afternoon a few weeks ago takes on a life far beyond anything we ever anticipated.
It all started back in December, when Oracle claimed to own Hudson.
It’s official: Hudson has been forked. The “real” Hudson is now called Jenkins. Of course, Oracle will say they’ve got the “real” Hudson because they’ve inherited the name. Or, rather, they’ve sat down upon the name and made it impossible for anyone to pull the project out from under them.
What a mess. I wonder when the folks at Oracle will realize that open source projects will continue on their merry way.
(Rather, Oracle drops Ruby support.)
This is unfortunate. While many people use Eclipse and don’t worry about Netbeans, I actually prefer it. I suppose I’ll have to make the transition to Eclipse for once and for all.
The founder of Ruby on Rails, David Heinemeier Hansson, said in an email that he was “not surprised” by the NetBeans move. “I never came across anyone using NetBeans for Rails. Everyone I talk to uses TextMate, VIM, or Emacs. Full-fledged IDEs are not all that popular in the Rails world,” Hansson said.
Hey, I like VIM as much as the next geek, but a solid IDE for Ruby/Rails is something that is still very nice to have.
I really did like it better when Sun owned Java. Now I think everyone is starting to really wonder about the future of Java with Oracle ownership. Oracle may find that since they cannot charge for Java it isn’t worth keeping, and simply let go of it (we already have Open JDK, which is perhaps one step in that direction.
Here is a list of random stuff that recently caught my eye:
- Hirelite Blog: What developers think when you say “Rock Star”
- Hudson’s Bright Future
- Ruby on Rails on Ubuntu in One Line
- Ruby and Rails in a Single Windows Installer
- Ruby Best Practices Book–FREE
- Fedora vs. Ubuntu, Is Either Better? (I prefer Fedora)
- NetBeans drops Ruby
- Stop Googling/Look at the code!
My friend Eric is going to start a new Ruby on Rails Hack Night group in the area. Hopefully I have time to join him! (I plan on it.)
Things like this may seem like just one more thing to do in a busy week (I have children and a wife and other hobbies), but it does provide an excellent way to meet other developers in the area and learn from others. When I interview people for a position it is always import to me to know that a candidate takes a personal interest in software and keeping up with the software world.