Why We Need Programmers

Every few years, it seems, there's another push to obsolete programmers.  Sometimes it's overt, like COBOL was ("We'll make it so the businessmen can just say what they want done!"), and sometimes it's more subtle, but it always gets attention from the industries that depend on programmers.

The problem with all these efforts is that we're still a long way from being able to take a fuzzy natural language description of the desired solution and turn that into a working program.  That means that someone who is not a programmer has to write the code for the program in some programming language.  And that leads to all sorts of issues:

1. Naive code - someone who has not learned about programming practices will write code that is difficult to learn and modify.
2. Incomplete or inefficient programs - someone who has not studied programming will lack knowledge of algorithms, and will lack experience of gap analysis.
3. Just plain shoddy work - the erstwhile programmers will not want to be programming, because they want to be solving their real problems.

The explosion of spreadsheets and database query languages exposed many domain experts to a small facet of programming, and as studies have shown, most people think they are more competent at things than they really are, and the least competent are really bad at seeing their cluelessness.

Programmers will have the background to recognize O(n²) algorithms; they will be familiar with the tools like code versioning systems and parsers; they will have passion for the code itself, so that it will be easy to maintain and modify.

I guess it's rather like plumbing.  It's not hard for a homeowner to run a little length of drainpipe, but when it gets to plumbing a whole house, or handling a sewer  connection, they prefer to use a professional.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

More on Offshoring and Its Perils

As my reader(s) know(s) [Hi Brian!], I'm way behind on my "interesting idea for a blog post" list, so I may be pumping a lot of relatively short posts out to try and get back up to the current set of items.

Anyway, I saw this post about offshoring, written by a developer in India, and I felt it worthy of mentioning, as it rings true - contractors never feel as close to project as full-time employees do, and the more remote the home office, the less involved even the employees feel. (look for the letter from the guy from London)

Adding to this is that nowadays, most of the Indian developers are available through the big consulting houses, so you get even less identification with the project, and more opportunities for corporate shenanigans that derail projects.

Of course, there is always the option of hiring directly, but that runs into the problem of scale.  In the US, a job posting might get 100 resumes; 50 can be dumped right away for totally wrong qualifications, 25 for inadequate skills, 15 weeded out in the phone interviews/standardized tests, and the final 10 interviewd face-to-face and the best picked.  However, in India, that same job posting might bring in 1000 candidates, and unless you have 10X the interview staff, you cannot get it winnowed down to the best 10 people - you might get it down to 100, interview 50, and hope for the best.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

The Good, The Bad, and It's Gonna Get Ugly

(with apologies to Sergio Leone)

While browsing over the past few weeks, I've run across several articles discussing the relative skill levels of developers and the effects of having differing skill levels in your team.

Jay Fields expounds his opinion of Net Negative Producing Programmers (NNPPs), but his solution is to avoid working with them, which is not very practical for most of us who are not freelance programmers.

Over on It's Common Sense, Stupid, Jay's position is accepted, but his conclusion is not.  But the suggestions made are of a similar line - avoid NNPPs if you can, only the way companies work today, you can't make it any better.  But another post there addresses the reason companies don't fire NNPPs - they can't tell who they are.  Code quality is not visible - and the metrics managers try to use to measure it are easily subverted.

Of course the biggest problem about going to managers about NNPPs is that you might be seen as a cocky developer.

If you think you are the best developer in your group, and you feel that you are surrounded by NNPPs, you need to consider how you come across to your coworkers.  If they don't like you, your manager will probably not be able to tell that you are better, and will agree with their opinion.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

The Impossible, We Do Right Away....

Yesterday I was reminded of this post.  Some people do not understand how things work.  Even my upper management.

They want a change of the program's behavior, but they don't want the cost of that change - they don't want to run their tests, or restart their timetables.  They want you to somehow make the error go away without making them do anything different, and when you tell them that it's impossible, somehow you are evil from not trying.

If you face this often, you'll need to start programming defensively - making your programs as data-driven as possible, so that you can change behavior without changing code.  Now, this obviously fails to help when the problems are code issues (threading, loop limits, etc) - so you'll still need to be ready to deal with the nonsense.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

No More Brook's Law?

Every programmer worth his/her salt knows of Brook's Law, from his book The Mythical Man-Month,
and by and large, we tend to agree with it.  But this post points out that there may be new tools and methods in software development that may show a way past Brook's Law.

The main factors in this are the open source movement, the leverage of the better languages, and the better understanding of the effects of software interactions.

Open source allows developers to know more about the code by examination than was previously typical.  Even in the proprietary world, internal developers expect access to the code they work with.

Better languages are simply an order of magnitude (or more) better than the older languages - we can know access a web page in a single line of code; we have built-in data structures that we can use without having to build linked lists, hash tables, etc.  We are able to encapsulate more behavior in less code.

The better understanding of software interactions has allowed us to make better software - we know to separate concerns; we know to build software in layers; we know to make data-driven modules that can handle generic cases or special cases with impunity.

That said, we haven't eliminated the problem, we've just made it small enough to be lost in the noise given the complexity of software we currently develop.

And not all of us work in places and on systems where we get to take advantage of all these new toys.  Many of us are still working with lower-level languages, on systems that are too big to get the comprehension of, with unreasonable deadlines.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

Good Advice From Google, part 1

I have not had much experience with Test-Driven Development yet, as it's very difficult to insert a methodology from the grassroots, especially one that does not necessarily have the buy-in of all your team, but I like the general tenets of TDD, much like I do those of XP and the more encompassing Agile Development movement.

So here are some tidbits of good advice from Google.  I especially like the points about not using "new" except in factory classes, and "ask for, don't look for".  I'm less sure about the diss of Singletons - I understand the general point, but can see reasons for them in fact.  I'm wondering if this is one of those philosophical points, like Platonic vs Aristotelean views.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

Codebase - Asset or Liability?

We've all had occasion to provide a size of the codebase we're working on for a project, whether for management, or for our own resume, and there is a natural tendency to make the KLOC large - it sounds more impressive to work on or manage a large codebase then a smaller; a project that has lots of code sounds more solid, more reliable.

But there is one school of thought that holds a large codebase as a liability - it is harder to shift it; it has more inertia.  And there is some merit to this; a large codebase means that there is greater chance for errors (statistically, at the very least), a greater chance for unwanted coupling, and more places where code has been unwittingly duplicated.  So it behooves developers to minimize code, as described here.  On the other hand, less code doing the same stuff means you've got denser code, and you are at risk of being clever.  Clever code is bad because it obscures its intent, and the next developer to support the code may not be as smart as we are (or like to think we are).

So this means we've got tension between making the code simple, and making it small.  The low-hanging fruit of this is reducing redundancy - it's not hard to understand that all I/O is being done through your library functions, for instance.  The next best step is to use standard libraries where possible - they have the benefit of being available elsewhere, so your next set of developers are likely to have used them before.  A third strategy is good naming - if reading the name does not give you the right idea of what the code does, it will confuse someone later on.

Beyond these steps, you are faced with needing to consider the density of the language you use.  The current trends are towards more "advanced" languages like Python and Ruby, which cover much of the ground C/C++ do, but with less cruft, and with nice things like built-in data structures that are easy to use.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP