This is a story about IT projects...

I'm sorry steady eddies, but if you want to get anywhere with a big complicated project, you're going to need somebody who's a little bit of a madman. There's this idea that building a piece of software is a bit like building an aeroplane. Plan the work, work the plan. The idea is that the software architects will come up with a brilliant design specification, and then programmers can just come along and build it. Wrong.

Firstly, you have to plug together all the bits of tech, and make them work with each other. From the front end to the back end, you have the "full stack" and it takes a special kind of masochist to declare themselves to be a "full stack" developer, because you're liable to be asked to change the buttons to a slightly different shade of green far more often than you're likely to be asked to make a working piece of software.

For me, I'll start with a database design - a schema. I will model the data. Most applications have a CRUD element: create, read, update and delete data. If you think about the classic example of a database that holds all the data on your customers, most of it will be performing CRUD operations to keep the data up to date.

Then the next thing is the data abstraction layer. How is your software going to store and retrieve the data from the database? Software talks one language, databases talk another. Interfacing between them is easiest when you use a bit of software that does the 'translation' for you.

Then you're going to need a bunch of business logic. Sure, you have all this data stored, but you're going to want to do something interesting with it. Maybe you want a piece of code that tells you who all the customers who you need to contact today are. That's a bit of business logic, and you wrap it up in a service.

Then you're going to need APIs. APIs are Application Programming Interfaces. APIs let one bit of software talk to another bit of software, which can be done over the Internet. You need an API so that your website running in your Internet browser, can talk to the server to call the services that get the data to display, and call the services that have the business logic in them. When you click a button on a website, a request goes off to another computer somewhere in the world, which is processed, and then the response comes back. The API describes how this can happen: it's a contract.

Once you've built your APIs, you can build the user interface. The user interface is the pretty bit you see when you download an app from the App Store, or when you visit a website. When you visit a website, the user interface is actually downloaded and it runs on your computer, in your Internet browser.

With a website, the user interface will be built in code that's very different to the code that runs elsewhere. Because web servers execute millions of requests, their code is highly optimised. Because your Internet browser needs to support millions of different websites, developed by millions of different developers, the code is designed to run on almost any computer.

Then, when you've written all this code, you need to set up your infrastructure. You need a server, you need to connect it to the Internet, you'll need to connect your domain name to your server, you'll need to configure the server with website hosting software and the database, you'll need to protect your server against hackers, you'll need to deploy your code onto your server. Then, people can visit your domain by typing www.yourdomain.com and the user interface code will be downloaded to their computer's Internet browser, and then the API on your server will be called to get the data it needs. Bingo! Your software is live.

Just getting a basic website running requires you to be:

• A system administrator (a.k.a. "sysadmin") so you can configure the server
• A security specialist (a.k.a. "pentester") so you can protect yourself from hackers
• A networking specialist, so you can configure your domain name, load balancing, traffic routing
• A database administrator (a.k.a. "DBA") so you can configure the database
• A serverside developer (a.k.a. "backend dev") so you can write the service code
• An API designer, so you can define the interface contract between backend and user interface
• A web designer, so you can make the website look all pretty
• A front-end developer (a.k.a. "UI dev") so you can write the scripts that control the user interface
• A mobile developer so you can make an iPhone or Android app that does what the website does
• A QA engineer (a.k.a. "tester") so you can make sure the damn software works
• A release manager, so you can package up your software and deploy it
• An operational support engineer, so you can diagnose and fix problems when they occur

That's 12 different roles, or "hats" that you have to wear. Also, bear in mind that all your users care about is what colour the buttons are.

If you're a "full stack" developer, you're highly in demand, because you can take a piece of software from an idea, to something that actually works and can be used by people anywhere in the world, via the gift of the Internet.

Do you notice that none of those roles are "programmer". There is no such job as programmer anymore.

Back in the 1970s, you used to ring IBM up and they would wheel a dirty great big cabinet into your basement, and then a zillion wires would connect every "dumb" terminal in the building to it. The dumb terminals would just display on their screens what the mainframe would tell them. Essentially, it was just one computer that had hundreds of monitors, and hundreds of keyboards.

Programmers in the 1980s had everything they needed all in one box. User interfaces were just green text on a black screen. There weren't buttons to click on, that could be different colours, so nobody had to waste their time changing the colour of the buttons. There weren't pretty graphics for people to argue over. There was just green text on a black screen.

Because everything was on one box, everything was the same computer code. The data and the code and the different parts of the system were seamlessly interconnected. There wasn't computer code flying around over the Internet, being executed in billions of different Internet browsers all around the world. There was just one blob of code, running on one computer, with hundreds of users. That was programming: writing programs to run on one computer, not billions.

Programming's not even that hard: if this, then that. That's about the gist of it. If you know what the words AND, OR and NOT mean, you're well on your way to being a programmer. If you can write a list of instructions for another person to follow... that's how you become a good programmer. You just get really good at righting really good instructions for a really stupid person to follow.

IF you see some gold THEN go and pick up the gold

Looks pretty easy, right? Well, then you find that your program doesn't work very well when the gold is on the other side of a Plexiglas window. The automatons following your instructions are going to get stuck on the "go" part, and will find themselves just walking on the spot, with their nose pressed against the glass, trying to get to the gold that they can see.

Fast forward to the present day, and you might have the situation where your website looks absolutely awful because granny is still using Internet Explorer, but you only tested your code in Google Chrome. We have the situation where your website works perfectly fine when one person is using it at a time, but when millions of visitors are trying to access it at the same time, they're all treading on each other's feet and the whole thing falls in a heap.

A lot of techies want to be programmers, but programming is such a tiny part of anybody's job. If you hire a bunch of programmers, and they all insist that they only want to do programming, you're never going to have a website.

If you hire a bunch of web designers to build you a website, you'll have a very pretty looking thing, but it won't work very well. It'll be fake. It'll be window dressing. It'll be a film set, where the buildings don't actually have anything behind them: they're flat fronts, propped up from behind.

If you hire a bunch of back-end developers to build you an application, you'll have a beautiful set of services and APIs, but you won't have anybody to tell to change the colour of the buttons. If you tell the serverside developers how important it is that the button colour gets changed for the millionth time, they'll just say "yeah, yeah, yeah... I'm writing down on my invisible TODO list".

So, you hire a full-stack developer, because they can do everything. Trouble is, they're all a bit mental.

If you can do everything all on your own - you can wear 12 different hats and context-switch between them - then you're going to be driven mad if you have to work for somebody else.

Even though I can do everything, it's not like I should do everything. It's not healthy, to have constant interruptions, and to be pulled from one thing to another all the time. In fact, it's distinctly unhealthy.

The only way that a full-stack developer can make any progress is to work really, really quickly.

If you throw together a fully working application in the blink of an eye, you can get it done before anybody asks you to change the colour of the damn buttons. These herculean efforts are incredibly draining. Holding so many different competing tasks, and also the big picture, in your head, while working as fast as you can... that's exhausting.

Most software ends up in the bin anyway, so you might as well throw together these hastily built applications, that at least prove that things can be done, technically. There's already too much useless vapourware crap out there that doesn't actually do what it purports to be able to.

And so, I end up working on project after project that's clearly going wrong. I hastily cobble something together. I get something working end-to-end. Then, I'm burnt out and I have to take the money I've earned and go have a lie down in a darkened room.

I actually don't think software can be built without some nutter who's actually going to fill in all the blanks and prove out the concepts. Every important computer system that I've ever worked on has had one madman who's single-mindedly taken the project to the point of MVP - Minimum Viable Product.

It's unhealthy for your moods, to be expected to sprint as fast as you can, and then reap the rewards but be burnt out, but it's certainly lucrative and a good career strategy. The financial incentives can't be ignored. Also, if you're a complete-finisher personality type, it's the only way you're ever going to see a successful IT project, because so many people are happy to bumble along until the project eventually goes so far over budget and has spectacularly missed its deadlines, that it gets cancelled.

My current project - which is getting cancelled because it's over budget and late - has been slightly better for me than other projects have been in the past, because I just concentrated on making sure my team was on time and on budget, instead of thinking about the overall project. Net result, I'm out of a job again, but at least I've got a happy customer and a good reference, plus I'm not totally burnt out. It's a damnsight easier to only think about my 1/8th of the project, rather than feel responsible for the whole thing.

God knows how I'm going to reconcile my personality - a completer-finisher - with IT's staggeringly bad track record of ever successfully delivering projects on time and on budget. My health is suffering as I've tried to single-handedly get projects back on track, and I never get any thanks when I do that. I'm not saying I'm a hero. I'm just saying that I don't like to bumble along and fail.

Although I can do full-stack development, I don't think I should because it's just too much stress, being spread across 12 different roles. I reckon I'm going to look for some kind of development manager job, where I can have more management input into the way things are run.

It'd be interesting to know what my mental health would be like without the kind of external pressure to rush, rush, rush. It'd be nice to work on a project where I could take my time, take pride in my work, do the things I'm good at. Do those projects even exist?

I think it's the engineer's curse. "Can you do this?" is always answered honestly. Yes, I can probably fix your damn car, but should I really be doing that if my skill is as a software developer? "Yes I could, but I'm not sure I should" is the correct answer, but engineers aim to please. So few managers understand that it's a dumb idea to ask their capable engineers to do everything and anything, and expect them to spread themselves so thinly.

Even though management doesn't agree with me - too frustrating and boring - at least it gives me the opportunity to throw a bubble around my development team and protect them from bad managers. At least I can create the kind of culture that I'd like to have, as a developer, for my team.

It's hard to know how to balance your skills, your needs, your values, and the fact that life's a lot easier if you're paid a lot of cold hard cash.

Anyway, it's all rather academic until I've dug myself out of the debt hole.

Tags: #career #agile #computing #bipolar