Skip to main content

How To Recognize "Software Development" Is Step One

We're all "making software," but what's that mean? There is no shortage of resources on writing code. Debates rage on about this library and that, emacs versus vi, or nix versus windows versus osx. How much of it matters? We're arguing what car dealership gives us the best deal, automatic versus manual transmissions, and shades of colors to promote the best feelings when you see that shiny new car. Great, you've got the nice car (we all do), now you've got to drive the damn thing and keep it maintained for its lifetime. Who is paying attention here?

We spend thousands of hours discussion how to write software and millions of dollars helping us do it, but most of us have no clue how to keep that code around and get it in the hands of users. I won't make this a post about "The Cloud", but I will say its largely successful, because it solves a problem most developers either ignore or are never properly exposed to.

I won't blame PHP, but it fits to the bill to describe what is either a symptom or a cause of the problem: dump it and forget it deployment, while useful, has made a generation of developers unaware of what may well be the majority of work in their chosen line of profession, if you look at it right. How many people deploy their site by copying some files via FTP, even today? A frighteningly larger number than you might think! How do you think those same individuals debug? Do they even know what the word means?

The problems here stem beyond simply the code slingers, but to the cash slingers as well. Have you ever tried to convince a client that the time spent building deployment, logging, and diagnostics facilities upfront really isn't just a way to bloat your invoices?

I want to take a time out here to admit I'm not really sure where I'm trying to go with this...

Let's have fun and be completely arbitrary in the comments: What percentage of the job do you expect to be writing code when you start and what is the reality?

Comments

Patricio said…
If you are getting at something having to do with good project config, I think that this sort of thing is still up to the developer or managing developer to set up with the least possible overhead based on previous experience. You should generally not experiement with new development, bug reporting, and release practices when starting a new contract, and if this overhead is as critical todevelop
ent as you say it is (I
and if it's done correctly then I agree with you) the costs of this overhead should be included in up-front "development costs" and is not critical to be mentioned to the client.

Sometimes when you get into the nitpicky argument or discussions that you are mentioning it's because you aren't explaining it well enough and/or are pushing a technology that you aren't as familiar with a you think. This is a dance that I think occurs in these situations no matter what field you are in.
SwitchBL8 said…
What the hell is wrong with xcopy-deployment? It's simple, so it sucks? And for the same matter, the people that are in an environment that has the luxury of xcopy-deployment are the same people that don't debug?

Dude, you're assuming to much. You know what "I assume" means, don't you?

And the comparison with cars? Ridiculous. Ever seen the maintenance statistics of Mercedes lately? It's supposed to mean something, that star on the hood, but it doesn't. Not anymore.

And to be arbitrary: writing code includes debugging, testing and writing deployment scripts/plans. So the percentage? I'd say more than 80.
Calvin Spealman said…
SwitchBL8: Don't take it so personal. If you are able to spend the time to put the infrastructure in place and you dont need to badger the money men to budget for testing and performance analysis, you're in the right camp and don't apply to what I'm talking about. You're disgruntled attitude about what I wrote is akin to being upset that I say people who talk in movies suck, because you don't talk in movies.

Popular posts from this blog

On Pruning Your Passions

We live in a hobby-rich world. There is no shortage of pastimes to grow a passion for. There is a shortage of one thing: time to indulge those passions. If you're someone who pours your heart into that one thing that makes your life worthwhile, that's a great deal. But, what if you've got no shortage of interests that draw your attention and you realize you will never have the time for all of them?

If I look at all the things I'd love to do with my life as a rose bush I'm tending, I realize that careful pruning is essential for the best outcome. This is a hard lesson to learn, because it can mean cutting beautiful flowers and watching the petals fall to the ground to wither. It has to be done.

I have a full time job that takes a lot of my mental energy. I have a wife and a son and family time is very important in my house. I try to read more, and I want to keep up with new developments in my career, and I'm trying to make time for simple, intentional relaxing t…

The Insidiousness of The Slow Solution

In software development, slow solutions can be worse than no progress at all. I'll even say its usually worse and if you find yourself making slow progress on a problem, consider stopping while you're a head.

Its easy to see why fast progress is better: either you solve the problem or you prove a proposed solution wrong and find a better one. Even a total standstill in pushing forward on a task or a bug or a request can force you to seek out new information or a second opinion.

Slow solutions, on the other hand, is kind of sneaky. Its insidious. Slow solution is related the Sunk Cost Fallacy, but maybe worse. Slow solutions have you constantly dripping more of your time, energy, and hope into a path that's still unproven, constantly digging a hole. Slow solutions are deceptive, because they still do offer real progress. It is hard to justify abandoning it or trying another route, because it is "working", technically.

We tend to romanticize the late night hacking…

Why I Switched From Git to Microsoft OneDrive

I made the unexpected move with a string of recent projects to drop Git to sync between my different computers in favor of OneDrive, the file sync offering from Microsoft. Its like Dropbox, but "enterprise."

Feeling a little ashamed at what I previously would have scoffed at should I hear of it from another developer, I felt a little write up of the why and the experience could be a good idea. Now, I should emphasize that I'm not dropping Git for all my projects, just specific kinds of projects. I've been making this change in habit for projects that are just for me, not shared with anyone else. It has been especially helpful in projects I work on sporadically. More on why a little later.

So, what drove me away from Git, exactly?

On the smallest projects, like game jam hacks, I just wanted to code. I didn't want to think about revisions and commit messages. I didn't need branching or merges. I didn't even need to rollback to another version, ever. I just …