In an excerpt from the Autodesenvolvimento (Self-Development), I wrote that Tony Stark‘s greatest achievement was not the armor itself. The true feat was the entire project. Imagine the amount of coding time. I think that even if he had the whole code in his head, he would not have time to type all the software for that armor. I must say it’s still development, but I would compare it to heart surgery using a paper clip and whiskey.
Plain answer is: a developer develops. As a developer, I always had a hard time to explain what exactly I worked on …
Yeah, but I understand that this is too simple. So I’ll rephrase the question:
How does a developer develops? What are the actions of a developer?
The text below was not ready for the book, so here it goes an adapted version for this blog. I’ll anticipate: it’s nothing like this:
Planning
The planning part involves defining who will do, when it is going to do, for how long, what is going to be done and so on. Planning before the development is studied by a science called “project management” whose objective is … well, you know the answer: manage the project.
At this stage, the development team should be formed. The skills are assessed to ensure that the project plan is consistent with what the company can perform. Anyone can set up any project plan, any time. To get it done is another beast.
Usually the planning stages is heavily influenced by the developer, even when it is not necessarily performed by him. I have a cool story about it …
One day I was called to talk to my boss about a project. He said:
-Tell me how long it is going to take.
-Me?
-Yep. Your guess will be better than mine. If it would depend on me, I’ll give you an impossible deadline.
Specifications
Specify is a pain. It’s boring. BUT… It is necessary. Any development activity should have a specification that is, deep down, a breakdown of what you want to build.
“Must have a touch screen and the touch screen should have a button to trigger the application menu.” Things like that.
All the future product operations details should be contained in the specification. It should, unfortunately, however, sometimes it is not the case. Sometimes specification comes from a customer, through sales department, which “specifies generically”
I swear I’ve actually heard that.
An open specification in such a generic way equals the following conversation at a restaurant, right out of some Monty Python sketch:
-Please, waiter, I want some meat.
-But we serve meat several different ways. Would you like a steak? Maybe just sliced? Well done? Any sauce?
-Well, you know, meat is fine.
The “action”
Writing code, making diagrams and schematics. The development activity, when it needs to be romanticized for the movies, it usually ends so far from reality that if we are buy what they are selling… Well, the bottom line is: it’s nothing like that.
Want an example? The worst part of the Rocky movies is when there is the routine wake-up-eat-train-sleep-repeat, they put some music to do the action. It works, because there is movement on the screen. Now imagine trying to do this for a software developer: puts up a guy sitting. For days. Place a computer in front of you. And a screen, like this:
Everyone should agree with me: it’s not exciting for a movie and there is no music to save that. To solve that, they start creating some abstractions: animated compilers and graphics that do not put any message on the screen (see the movie Swordfish).
The truth, hard and simple, is:
- Long hours contemplating a blank sheet or “screen (be it wither white or black background)
- Scribbles, doodles, drafts. Things to help organize ideas.
- A bit of typing. A little mouse clicking components.
- More contemplation.
- More drafts.
- A little more “action” (which is typing or operation a mouse).
- And the next day, all over again.
Let’s take the technical part aside, to make a hardware design is very similar to connecting the dots in blocks on diagram creation software. Writing software is, for now, typing. Definitely, create good hardware design has nothing to do with buying junk and assembling something. Creating software has nothing to do with awkward console terminal accesses and to go crazy creating a lot of random squares…
Testing and Debugging
Any code written won’t even compile in a first run. It will not turn into a program, image, etc. A hardware design will definitely have some details forgot. After the creative activity of development, there is the bureaucracy of house cleaning activity or sweep the errors out of the design. Even after that, it is going to be necessary to test the prototype.
Testing things is tricky. When someone builds something expecting it to work, his mind is oriented not find errors in the project, after all, a developer develops stuff waiting them to work. Because of that, it takes another mind with diametrically opposite thought, that is, the tester, who has the mind directed to find errors on the development of others (after all, the “product” of a tester is the test itself).
But even the most optimistic developer will want to test a minimum before passing it over. It equals when tying up a rope: that small “pull” to see if it is firmly attatched and avoid accidents.
Production
Tested, debugged and running, it’s time for the prototype to become a product, to get to market. The production team will make an initial batch to be tested in “beta”, maybe in some selected customers. If errors are found, they are fixed up until the product to be free of errors (or at least the known errors).
Once released into production, the product is then manufactured. There will be factory testing and then they will get the market and maybe peoples houses, computers, etc. At these final steps, there should be minimal activity from the developers, if they have done their job right.
Until now, especially when I wrote about the “action”, it might seem that was monotonous. No, it is not! The development activity is constructive and building things is always satisfactory. And the best part of building things is to see people using them. It is nice when you see that it helps to change the world. Even without the fancy dancing…
