Entries Tagged 'Programming' ↓
October 14th, 2013 — Programming
I get paid to take on technical debt. In my work I see a lot of hard-to-maintain code, and I see many of the same avoidable problems over and over.
I specialize in debugging, fixing, maintaining, and extending legacy software systems. My typical client has a web site or internal application that works, more or less, but the original developer isn’t available. Business requirements have changed and the software hasn’t kept up. Or my client has something that is “almost finished” but they parted ways with the developer after using up their budget and schedule. Usually there’s a list of missing features and bugs.
My typical client usually has been told by other developers that they need to throw everything away and start from scratch. Most programmers don’t like maintaining code, and they especially don’t like maintaining someone else’s code. When writing code programmers often ask the wrong questions when they talk about maintainability—see Matt DuVall’s article The myth of maintainability for a good description of how that happens.
Here are some things you can do in your own software projects to keep me in business:
Don’t use version control
I’m always surprised to find big projects written in the last few years that aren’t under source code version control. When you don’t use version control the next programmer to come along has to figure out which files are part of the current system and which are obsolete or backups. The next programmer won’t have any commit messages or change logs to get the code’s history from. I covered how not to use version control in my article Introduction to Abject-Oriented Programming.
Customize your development environment. A lot.
Don’t make it easy for the next programmer to start working on the code. Require specific versions of languages and tools, and make sure they conflict with the versions that come with the operating system. Customize your Eclipse or VisualStudio or vim environment like crazy, then write macros and scripts that only work with that setup. Don’t have a disk image or scripts to replicate your development environment, and don’t bother writing any documentation—it will be intuitive.
Create an elaborate build and deployment environment
For a web site deployment to a staging or production server should look like one of these:
Programmers can argue about simplicity and elegance in code, and then turn around and build the most elaborate and baroque build and deployment systems. This is one of the off-the-radar things that programmers do without their client or project manager reviewing or understanding it, so it easily gets out of control. While you’re chaining together eight different tools with various scripting languages remember to leave out the documentation.
Don’t set up testing/staging platforms
Changing a production system is exciting. Don’t bother with a testing/staging server. Instead have secret logins and backdoor URLs to test new features. Mix test data with real data in your database. Since you aren’t using source control keep copies of previous versions just in case. Don’t build logging into the code. Don’t disable outgoing emails, credit card authorizations, etc. during testing.
Write everything from scratch
Don’t bother with a well-understood framework like Django, Rails, or CakePHP. You can write a better templating engine, ORM, sort or hashing algorithm. I scratch my head when I see code with comments like “faster than native dictionary method” or “replacing PHP library function because parameter order sucks.”
Add dependencies to specific versions of libraries and resources…
Throw in as much third-party code as you can. Link to as many shared libraries as you need to. I’ve seen code depend on large external libraries just to get access to one function. Modify the source code of the third-party libraries so they can’t automatically be updated to a newer version, but don’t bother forking or keeping your modified versions under source code control. I will be able to
diff your version with the original and figure it out.
… But don’t protect or document those dependencies
I get more urgent calls because of updates and upgrades gone wrong than for any other reason. A seemingly innocuous WordPress upgrade, Linux package update, or new jQuery release will trigger a chain reaction of failures. Don’t make your code check for the specific version or modified copy of your external resources or third-party libraries. Don’t even add a comment to remind yourself.
Use a bunch of different programming languages and stay cutting-edge
Every day HackerNews and Reddit buzz with cool new languages. Try them out on your client’s time. Any decent programmer can learn a new language in no time, so if the next programmer who gets to work on your code is a newb that’s not your problem. The boundaries between the languages, the incompatible APIs and data formats, the different server configuration requirements are all fun challenges to overcome and post about on StackOverflow. I’ve actually seen PHP web sites with pieces of Ruby wedged in because everyone knows PHP sucks and Ruby is better. Half-baked caching, aborted Rails and Node.js projects, and especially NoSQL solutions (“It’s more scaleable!”) are my bread and butter.
Where’s the programming advice?
It won’t matter much if your code is beautifully object-oriented or shiny and functional—programmers pretty much always see spaghetti code when they have to maintain a legacy system. I am good with
grep and Ctags, tracing through code, refactoring, and debugging. I’ll figure out the code. The most beautiful, elegant code is still hard to work with if there’s no source control, too many dependencies and customizations, and no testing/staging facility. It’s like finding one clean and nicely-decorated room in a house straight out of “Hoarders.”
Related and possibly interesting: The joys of maintenance programming.
September 30th, 2013 — Programming
In my career as a programmer I’ve seen lots of projects go off the rails because of strict adherence to some practice, rule, or fashion. It may be something the entire team has bought into, like OOP or TDD. It may be something a single member of the team bullies everyone else about, like tabs vs. spaces or braces style. Even a programmer working alone can sabotage a project by honoring fetishes above productivity.
Here are just a few of the fetishes I have observed wasting hours and days of programmer time:
- Spaces vs. tabs, how much to indent each line
- Braces style
- CamelCase, mixedCase, names_with_underscores, etc.
- Variable naming conventions, especially Hungarian notation
- No function can be longer than 50 or 100 lines, or no function can be more than one printed page
- Never use GOTO, eval, operator overloading, singletons, or some other language feature deemed evil
- Functions can have only one return
- No global variables
- Pure OOP, pure functional
- Design patterns
- TDD (test-driven development)
- Gannt charts, Agile, Scrum, Extreme, User Stories
- Never use SQL stored procedures, or always use SQL stored procedures
- SQL vs. NoSQL
- Never use PHP short tags
- All web interfaces must be RESTful
- HTML must validate with W3C
- Strict XHTML
Not all of these things are necessarily bad ideas. And it is important for programmers on a team to follow some guidelines so their code is understandable and plays well with the rest of the system. The problems arise when a programmer or a team decides that purity according to an arbitrary rule is more important than delivering a working solution. If someone is paying you to develop an application or solve a business problem it really isn’t important how the source code is indented. It is important to the customer that the programmers not waste many billable hours debating whether singletons are bad or not, or if all of the variable names follow one person’s favored convention.
The problem is similar to cargo cult programming. It’s bad enough when newbie programmers do things without understanding why. It’s worse, I think, when experienced programmers turn their own preferences and biases into fetishes and then force themselves and everyone they work with to follow them, even when that means putting the project at risk.
For the last few years I’ve specialized in debugging and fixing code, a lot of it abandoned when the developer and the customer divorced over budget and schedule overruns and missed expectations. I see code that doesn’t even work sprinkled with self-congratulatory comments referencing the GoF patterns. I see badly-written replacements for library functions that exist only because the programmer decided that the standard version’s name sucks. I see specs full of justifications for technical choices that don’t mention important business rules.
I also see lots of code that doesn’t use my preferred indentation, tabs, braces style, variable naming, etc. Spending time “fixing” the code to satisfy my aesthetic sense would be a waste of time and money for my client. I’ve figured out that code that wasn’t written to my tastes is really no harder for me to read and maintain than my own code.
Methodologies, techniques, and best practices should be understood and used to solve problems, not worshipped as rules that must be obeyed no matter what the cost. If you are spending more time debating naming conventions with your colleagues (or yourself) than you are writing code that solves a problem you are wasting time with programming fetishes.
May 11th, 2013 — Programming
I’m your next potential dream boss. I run a cool, rapidly growing company in the digital field, where the work is interesting and rewarding. But I’ve got to be honest about some unfortunate news: I’m probably not going to hire you. … If you want to survive in this economy, you’d be well-advised to learn how to speak computer code.
— Kirk McDonald, president of PubMatic, writing in the Wall Street Journal, 10 May 2013
This is another article beating the “everyone must learn to code” drum. Employers can’t find enough people with programming skills, schools aren’t turning out enough engineers, jobs at these cool companies are left unfilled because American students are too lazy or short-sighted to spend a summer learning “basic computer language.”
If only it was that simple. I have some complaints about this “everyone must code” movement, and Mr. McDonald’s article gives me a starting point because he touched on so many of them.
A dilettante is not a programmer
That isn’t writing at all, it’s typing. — Truman Capote
Learning a little bit of programming is probably worse than not learning it at all if you are going to be working with professional programmers. Anyone who has worked in the software business has had to deal with a manager or marketing or sales person who took a BASIC or Pascal class back in college. Although their exposure was shallow and short, they will refer back to it as if their mastery of a FOR…NEXT loop qualifies them to make decisions about programming projects. Consider Mr. McDonald’s example: “Suppose you’re sitting in a meeting with clients, and someone asks you how long a certain digital project is slated to take.” How exactly does knowing a little bit of Python help answer that question? I’d rather hire someone who said “I can’t tell you offhand but I will find out,” and then consulted people who can help estimate.
There are lots of people who have training and degrees in computer programming who can’t program: see Jeff Atwood’s article Why Can’t Programmers.. Program?. I can’t see how adding more amateurs to these ranks is a good thing. I specialize in debugging and fixing code that is abandoned or unsupported by the original programmer, so I see plenty of what happens when someone who half-understands programming tries to develop real programs.
Programming languages are not programming
Teach yourself just enough of the grammar and the logic of computer languages to be able to see the big picture. — Kirk McDonald
The grammar and logic of computer languages are not the big picture. Programming languages are not the hard part of programing; not even the most important part. Programming is methodically using software to solve problems — business problems, rocket guidance problems, selling ads online problems. Programming languages and APIs are tools to write programs: they aren’t programming. By analogy you know you are in a group of amateur photographers when they have $3,000 cameras but don’t know what an f-stop is or how it affects depth of field. Professional photographers talk about composition and lighting, not camera features.
Good programmers can construct, hold, and analyze complex models in their head. They can translate business requirements into code. They know how programming languages and software tools can be applied to solve a problem.
Not everyone has the talent or inclination to program
I never learned to skateboard. I can’t dance. I can’t play a musical instrument. I struggle learning foreign languages. I know people who can do those things well. They apply themselves because they are interested and motivated, in the same way I applied myself to computer programming, for years, until I got good at it. I used to tutor college students and teenagers, and I learned that very few people find programming interesting or fun. Students sit through the courses because they have to. Their experience paying me to write their Fibonacci sequence assignment while they tried and failed to understand recursion will be cited later in their career as programming expertise. Maybe they will estimate important projects based on that half-remembered exposure to Visual Basic.
I’m not saying programming should be exclusive. I’m all for the kind of curriculum upgrading and partnerships with business that Mr. McDonald supports. Anyone who wants to learn programming should be able to, and experienced programmers should help and mentor. But let’s not kid ourselves that everyone wants to program, or will have the combination of talent and interest to get good at it.
It’s setting people up to fail
Most people who try to learn to program are going to fail or lose interest. Telling high school and college students and job seekers that they don’t have a chance because they didn’t learn to “speak computer code” is creating a phony bar to entry. At best it’s a distraction, like business students forced to take a programming class they will forget about. At worst it’s another demoralizing episode—like trigonometry was for a lot of us— where students are told they must master something that most of them will find uninteresting and difficult and inapplicable to their life.
In most jobs some level of familiarity and comfort with computers and technology is required. But you don’t need to know how to write code to do most jobs. I’ve worked in ad agencies and most of the employees didn’t program but could do the job they were supposed to be doing just fine.
Programmers have worked hard to learn their skill
So the book can only be talking about a superficial familiarity, not a deep understanding. As Alexander Pope said, a little learning is a dangerous thing. — Peter Norvig
Suggesting that just anyone can learn programming in a summer spent with Python tutorials and getting “acquainted with APIs” trivializes the amount of real time and effort required to learn programming. Peter Norvig wrote Teach Yourself Programming in Ten Years, and I think he got it right. Malcolm Gladwell came to similar conclusions in “Outliers.” As a professional programmer with 35 years experience, much of it continuously upgrading my skills, I’m a bit offended at the suggestion that everyone and their mother can be programming after watching some videos online.
The idea that programming is something anyone can learn if they just sit down with a book and type examples is not just offensive to programmers—it’s a dangerously misleading idea for management to hold. It feeds the idea that programming is a rote skill that can be trained into anyone, and that programmers are therefore more or less interchangeable. Many of my friends and almost all of my colleagues are programmers, but I would flail for a while trying to do their jobs if I was rotated in as a new “resource” or headcount. Programmers tend to specialize. Our underlying expertise and experience, and our innate interest in programming, means that we can do another programming job better than someone fresh out of school, but we aren’t interchangeable.
So what do I tell my kids?
I tell my own kids to invest in learning useful skills, whether the skill is programming, plumbing, writing, or fixing cars. Learning any skill well enough to make a living from it takes a lot of time and commitment. I also teach them that credentials are not the same thing as expertise, and the more competitive the job market gets the more skills and experience will be valued over credentials, especially as we figure out how degraded a lot of credentials really are. I teach my kids that they can learn anything they are interested in, but I can’t make them interested in any specific thing. And I tell them to be skeptical of advice like “Everyone must learn to code.”