Projects – Fasani Corporation

I wanted to write a small essay about my personal choices and tools for Development. With about 12 years of doing stuff for the web I passed both through server side work all the way to client side validation and administration control panels in almost all the companies where I worked.
I went through also different approaches to solve a problem, from a detailed project analysis that may last months, to agile development where you start with a draft and some ideas right into selecting technologies and coding. An approach that may turn up for the good when you work for a web project or an agency. Deadlines are short, things change on the way, no time to make a detailed specific analysis because after 2 months, things could be quite different from the point where analysis started.
My favourite composer, Herr Gustav Mahler said something very interesting about his creative work:
“To write a symphony is to create a whole world.”

And sometimes when a developer starts with a Project and faces the white page, it’s something alike, you need to create your own world. Select the roles, the actors, the libraries, and the interections between them.
So this is the approach that I will try to explain in this essay along with the tools that are some of the standard choices in the development arena.

Project Planning 101
A good plan always start with some drawings on paper, main ideas, that should be backed up by your team. The team is one of the turning points here, even if you are a loner developer, the ideas must be consented by the people you work for. So next step after this ideas are drawn and approved is to make a Project plan with deadlines and numbered tasks. And for that mission I find very useful OPENPROJ.eu a Java based project planner that runs on any platform:
Repositories
There are many choices to use Github online repositiories. Two of the best ones are:
1- Github – Where everything goes public for a free account
2- Bitbucket – Backed up by the Atlassian company and my favourite so far.
Since you can store your code private and work with fellow developers and numbered #1 Issues to know exactly what group of files you are editing to resolve what (Task / Bug ) Bitbucket has a very good Issue handler, since their company has a product called Jira, that is an online project management tool used by many top-noch companies.
So basically you can organize the Tasks there as well and keep them aligned with the Project Plan and your codebase. For example:

$ git add YourUpdates
you can commit with a message that goes directly to the Issue and links the updated code to it:
$ git commit -m ‘references #7 Jquery validation applied on forms: X & Y’ $ git push

And then you will already have the modified files tracked on bitbucket and your colleagues may be able to review the update or create the test cases for it.Bitbucket supports many calls for their powerful issue tracker. So you can just reference or even ‘fix #7’ or ‘close #7’ an Issue.

Action	Command Keyword	Examples
resolve an issue	close closed closes closing fix fixed fixes resolve resolves resolved resolving	`close #845fix bug #89fixes issue 746` resolving #3117
reopen an issue	reopen reopens reopening	reopen #746 `reopening #78`
mark an issue wontfix	wontfix	wontfix #12
mark an issue on hold	hold holds holding	holds #123
mark an issue invalid	invalidate invalidates invalidated invalidating	invalidates #45
link to a changeset for the issue	addresses re references ref refs see	re bug #55 `see #34 and #456`

So my personal take is, even if you are kind of repeating things on the visual Project Planner and in the repo system, it’s really worth it to keep it updated and to have a visual aid somewhere near your keyboard to be aware of it and go to meetings with the master plan for the deadlines and tasks.
Working in team with a Repository tracking is a must this days. Transparency rules in development, and the super cool thing of using any of this tracking systems is that you are both updated in the projects you work, the libraries you use, and also another projects where your fellow developers work. It’s a kind of an universe of it’s own and keeps you focused on your tasks, knowing exactly what module you are coding and what Issue it solves.
Development is fun
Seriously it is. Even if you are doing a difficult project where you don’t see the light at the end of the tunnel using a good methodology and being organized will make you more effective even on the most complex scenarios.
So if you face something new and you will create a new system where you have freedom to decide what you use, get out of your comfort zone, try to implement some new library or responsive design to leverage your new creation. If you fail, like I did hundreds of times, just start over with a smile and make the right choices.

Whether you don’t achieve something or you don’t make that project work or it’s that goal that was not achieved and it’s just too late to make it happen. I find a good practice to meditate afterwards after the storm is gone.
To extract the knowledge out of it and archive the case for the good, deleting it from my memory, and keep my mind as clean as possible with the new lesson learnt.

If you face something big, start with the most complex and weirdest thing at all. When that is done, you can see a bigger part of the picture and the energy that liberates is reused to go forward.

In my personal baggage of historic failures, that is reopened and analyzed mentally each time I commit a new one, here are the most common turning points:

Rush
Being extremely fast means doing without leaving room to think too much. And unless you are a formula 1 pilot is almost always the weakest point in the chain.
Too fast means always too risky and when you are set in that mood you leave room to make mistakes in every second you gain. Thinking that the GPS autopilot is making the best choice for you because you are too concentrated in driving fast can be a good example of how sometimes we leave key decisions on the wrong place. When we find later that there was a shorter path is too late to arrive to the event. Another route planned with that extra 2 minutes that you are saving because of the rush could make you arrive to destination timely. And that leads to next critic point in the chain:
Short sighted
We cannot connect all the points at the beginning when we are working on something. They will be eventually connected in the future, but at projecting times where abstract rules, you are just too close to see the whole picture.
So planning is essential and maybe starting with something that is a connecting piece, can help you to visualize the remaining as a whole, leading to visualize that points that are so hard to see at the beginning.
The bad ordering
So if you face something big, start with the most complex and weirdest thing at all. When that is done, you can see a bigger part of the picture and the energy that liberates is reused to go forward.
Many times I started with the “decoration part” of a project, only to discover weeks later that was undoable, and I had a lot beautiful drawings plus hours of time that went directly to the oblivion. How much I would have saved if I started with the hard part, that we leave always to end, for fear of failure but also because it’s easier to start with the painting part. We are lazy by nature, especially developers, and that’s not a bad thing if it’s used wisely.
Usually starting with this essential piece is the harder starting point at all, but once it’s done you confirm two things, first that the thing is possible and that the rest can be connected to it letting you foresee the rest of the thing. It’s frequently a bad idea to start with the decoration only to discover later that the whole apartment needs to be painted.

This are the 3 points where most of my own bad histories fails. Of course then there are a plethora of more nifty details that I could imagine but 95% if I’m not being short-sighted fail in this parts. And failing in one of this means that you are close to abandon the ship if you don’t correct it timely.
I didn’t study any of this in the University: I just made too many mistakes :)

Tag: Projects

Perfectioning Development tools 101

The lessons of Failure