If there is something I have noticed for years in the programming world is that it is becoming harder and harder to find documentation of Quality.
A few years ago, when someone wanted to start with a new programming language, as soon as he had a bit of interest was more or less easy to find documentation, tutorials, examples and everything a developer could need to take their first steps and then move to create increasingly complex systems.
So I started with PowerBuilder client-server environments, with Pro-C or JAVA, manuals and tutorials based on trying to guide you in the process of software development.
The Evolution.
But as the years pass, the software evolves, it creates new and more powerful development Frameworks, which force you to take more time to master and integrate them into your projects.
You might think that the documentation is also becoming more complex and forces you to spend more time with those first steps, but with the subsequent reward of better applications and shorter development times.
But the truth is not always the case, since the effort spent to create these more complete and complex Development Frameworks have been ahead of the forces for something that is becoming more necessary: DOCUMENT.
Frameworks evolve from projects where documentation and worth you to start and develop your knowledge, to projects where it is customary to find the typical 'Hello World', which is as absurd as useless when what you need is to build large systems.
Objective: Productivity.
AJAX, JSON, HTML 5, MVC, JPA ... All this and even more come to be the day to day in the development of dynamic websites with complex and powerful RIAs, where everything is complicated to change to ensure high productivity.
Or at least it should be, because the sad reality is that finding quality documentation that teaches how to integrate the various technologies of today, how to solve the various problems you may encounter in integration, has become an exercise similar to fishing ... only we have changed our favorite river or lake by Google, and our bait for these keywords to help us discern the solutions of other thousands of developers who also drowned in the same problems as us.
 |
| You're lucky if you give your solution in the vast sea of Google results. |
And all because the same people who are capable of twisting lines of code to create these frameworks tame and highly productive, suffer from interest, capacity or pedagogical skills necessary to sit in front of a word processor and write a guide explaining something more than the fucking 'Hello World'.
So what should be a high initial effort to become lower development times, ends up being a HUGE effort and frustrating days and weeks to not only think about how to create real applications, but to resolve the thousand and one problems that we we can find to begin to understand how to actually use these tools.
But hey, if we were talking about Open Source projects, carried out by newly graduated kids like writing lines and lines of code, but not to explain what they do, one could even understand it.
But when one has to face Frameworks supported by people who assume serious and resourceful, gifted to do things right, faces the enormous frustration is when I start to ask: But what the hell is going on?
And in this case I mean neither more nor less than Google and its GWT, Spring Roo of SpringSource, which are not small companies.
The Road to Frustration.
Two weeks ago, and in order to decide what technology to use for a small web development work, after being given options and looking eager to develop something with GWT, I came to this page:
Rapid Application Development for the Cloud
I read the title, header and starts reading the 'tutorial' and beginning to think I found what I needed.
And to that end I download the development environment for Spring STS, PDF 'Getting Started with Roo', willing to trust these two large companies and devote my time to learn how to create a project with these tools.
For these two weeks can be summarized as: anger, frustration and a sense of wasted time.
The environment is good, Spring Roo is a great idea, great Framework GWT RIA ... but the documentation is pitiful.
Roo's book is outdated, written for version 1.5.5 has been published as version 1.2.0, which could be overlooked if not for the mistakes that you find by following the examples.
 |
| Why does it not work? What have I done wrong? |
First to be behind a proxy, which somehow made the JDBC drivers are not installed even though the application say that everything had gone well.
Then because you're going to find errors occurred with no one knows exactly where, that force you to waste time on finding solutions to the forums.
No solutions, so we only get to 'solve' with the method 'Delete project' - 'Create New Project'.
And the latter because when you try to create your first application with GWT + Spring Roo, which is supposed to be only 4 lines on the Roo shell to have an application, it becomes a ...
'why the fuck FAILS NOW?'
And a lot of inexplicable errors, when compiling assumed that after all has gone well and should run without problems:
 |
| Results after following the steps outlined in the book "Getting Started with Roo '. Here I was about to throw me to mourn. |
The Hangover.
And at that point I am, in deciding whether to give one more chance, spend a day or two to find out why the hell fails, or opt for other options easier.
If I were asked right now ...
Do you recommend for use by people in your office?
My answer is a resounding: NO.
They are good products are powerful, you can end up getting high productivity ... but when the dates are short, when the support is not going beyond a one-page tutorial sad or book incomplete and full of errors, or a forum where no one says you're going to get a response ... with the budget in hand should put aside these products until they either get better documentation, or work as expected.
For now I will give one or two days to spare, but if problems persist it is time to give them aside until someone at Google or Spring to realize that as important as making things work, is to that the documentation will be serious and complete.
Deliberation.
I think the conclusion is obvious, as large as Google and Spring fail in something as important as providing a good, complete and updated documentation ... What we are not doing wrong to others?
Maybe it's the rush, the lack of time or simple carelessness, but simply find various tutorials online to find articles where hardly bare delves into the subject.
But does anyone think that Java would become what it is today if it had not delivered SUN complete API with every release? Or if he had not filled his web of examples on how to develop desktop applications with Swing or how to build web applications?
Unfortunately those days seem to have gone forever, leaving time to a time where everything is rushed and more importantly delivering new versions before going to explain it to anyone who wants to use them how.
We're turning the Art of Software, the work of master craftsmen, working in a production line where what matters is not to understand what you do, if you do not learn what button to press at the time.
