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 [MOVED]

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…

Finding "One Game A Month"

I was really excited about the One Game A Month challenge as soon as I heard about it.
For about two years I've struggled in fits and starts to make my way into game development. This hasn't been productive in any of the ways I hoped when I started. Its really difficult to be fairly experienced as a developer, which I believe I am in my day job as a web developer, while struggling really hard at an area in which your experience just doesn't exist.
Its like being a pilot who doesn't know how to drive.

But this challenge provided a new breath to this little hobby of mine. It gave me a scaffolding to experiment, to learn, to reflect on finished projects. I had spent far too much time on game projects that stretched on far past their exciting phases, bogged down by bad decisions and regret.
And it has worked.
I have a lot to learn. I have a lot of experience to gain through trial and error and mistake and discovery. I have a lot of fun to be had making more small games t…