Developers make you money. Engineers save you money.Engineering is a study of stresses and forces. It's obvious when a civil engineer designs a bridge that she has to deal with different stresses and forces. Gravity pulling it down, wind pushing it from the side, seismic activity shaking it around. If you analyze other engineering fields, it's easy to see how each deals with different stresses and forces.
So what the hell is Software Engineering? What kind of stresses and forces do programs have to deal with? Even the closest kin to it, or rather the predecessor of software engineering, electrical engineering, is an obvious study of electrical forces. Like a mechanical engineer devising a combustion system that directs the flow of gasses to move pistons, electrical engineers direct the flow of electricity through various machines and gates.
But what does software engineering control? What stresses do software engineers have to account for?
Software engineering is a study of stresses and forces on information. Software engineering is a discipline of controlling the flow of information. The stresses that a software program has to deal with are of time and scale.
Information Overload
At the most basic level of programming, you're following a road. There is ever only one road, both literally and figuratively. There's always a beginning to a software program, then you can go down the code and trace the flow of information. You use variables as references to stored pieces of information, and use if-statements and for-loops to change that information around. But unlike a real road, where the destination is the important bit, for software roads it's the journey that matters. The journey down the road transforms the information into what you want.Let's say you're the manager of a company. You have an epiphany one night and realize that the universe is vast and possibly infinite, and you are a conscience being, probably the rarest thing in the universe. You're not alone either, there are other precious conscience beings with you, and they're helping you do things that you wouldn't be otherwise capable of doing. And yet they are getting vastly under-rewarded for being such rare and amazing collection of matter. So you decide you're going to give everyone a 10% increase in pay. The next morning you bring up your employee directory and you take a random employee and multiply his salary by 1.10, then replace his current salary on the directory.
Wonderful, but you look at your directory and you realize that you have 5,000 employees, since you're a pretty successful boss. The process of taking an employees salary, modifying it, and then replacing it is a road that can be laid down by a developer. But unlike normal roads, you want to travel this road 5,000 times with every single employee.
In a software product, there are lots of roads that changes information the way you need it to. And these roads are traversed multiple times from various different directions, and they keep growing. New roads are being laid down, old roads are being changed. But how do you know that the road you're changing doesn't cause problems for some un-suspecting traveler, one you didn't know used that road?
One aspect of software engineering is how to deal with the scale of your program as it grows in complexity. And EVERY successful program will grow in complexity, it's a guarantee. As the complexity of your program grows, so does the time it takes to execute it. Depending on what you're doing, this might not be an issue. But usually programs that automate changes to information should be really fast, usually there is a lot of information to crunch.
Scale and time are the two forces that software engineering has to contend with. And it comes in various other flavors.
Relationships
Information is never alone. The nature of information is that it's informing about something. So there's always a subject, a thing, the information is describing. Flip it around and lets look at the thing itself. Most likely any thing will have more than one piece of information attached to it. A table not only has height, but width and depth as well. What's more, subjects might be pieces of information about other subjects. That table is also made up of legs. Legs also have widths, heights, and depths. Tables might have three legs, or four, or five, or maybe just one big one in the center.You can see that if you were to create a program called "Table Factory," you would immediately come across some challenges representing the different types of tables, different types of legs, and how they are associated with one another.
These associations, or relationships, between pieces of information is both hard to create, and also hard to manage. Lets say that your table factory produces different table tops. Each of these table tops has three different configuration of legs. And you have different types of legs. "Table A" can only use two types of legs, in all three configurations (tripod, quad, single large stem). "Table B" though, can use all any types of legs, but it can only be the traditional 4 legged table. Etc.
How will you store these information such that the table factory can assemble these tables in the right configuration? There's possibly hundreds of different types of tables you can produce with all these combinations and rules, do you make a specification for each one? That would be tedious, and there is the seed of a problem of scale.
Let's say you did the calculations and you found that there are only 94 combinations, your current supply chain offers limited types of tables and legs. That's not that hard, a couple hours and you have 94 different tables specifications for how to build each one. Then your boss comes in and says, "John, I gave you a 10% raise, I'm a good boss aren't I? Well, it seems we're doing so well that I can afford to be generous! In fact, we just got a fresh supply of a new type of table legs. Could you go ahead and make sure our factories can produce tables with these new legs? It's gonna be fantastic!" And BOOM! now you have a full blown scale issue.
And with scale, comes a stress on time. Your table factory is highly optimized, down to the nano-second. Every single piece of information has to be there just when it needs to be. When the leg-attaching machine gets a Table type 3a and legs type XZ, it needs to know how to put that thing together PRONTO. Did you store the information in such a way that you can link up all the relationships and rules to get the leg-attacher to do the right thing? No? Well too bad, you didn't deal with your time constraints properly. Now your entire assembly line grinds to a halt because of bottlenecks in the system.
There goes your 10% raise.
The Business
Those are just analogies, and they seem quite academic. Who cares if things are just a bit slow and complicated? There's no real impact as long as processors get faster and memory gets cheaper, right?There's another flavor of the time and scale forces in software engineering, and this one hits you right in the wallet. The fastest processor, or biggest hard drive in the world, isn't going to protect you.
Software changes information. But how it changes information, is itself a piece of information. You know of it as the code. And this information becomes complex very quickly unless you deal with the stresses of scale. If you're going to make money as a software developer, you're going to have to develop something useful that people pay you money for. Your software then becomes a product. And as products become popular, more and more people want it, and in better forms. So you have to hire more developers to help you grow the product. Here you have the beginnings of an issue of scale.
Like a lot of things, software is a collaborative process. Car manufacturing is a collaborative process. But no one who's responsible for the tail of a car, goes up to the front and changes the steering wheel so that the car will turn perfectly around bends, so as to display the beautiful tail he's been working on. But that does happen in software. It HAS to happen in software, due to the nature of those high-traffic roads we already talked about.
Software is a book being written by several authors. Sometimes all at once, but usually an author picks up where another author left off weeks, if not years, earlier. And each author might have different writing styles, different values of what determines a good book, and different ideas about how a character in the book should develop. This is where your scale problem explodes in your face.
When your code becomes disjointed and hacky, you start to have problems with how well your business handles the force of time . Every change now takes 10x, 100x, 1000x longer than it used to. Your competitors are coming out with better products, faster than you. Your product is released, but comes back with all sort of user complaints and bugs. Get ready to close shop, you're business is not going to make it.
