I believe a spec is a test-environment, right?
A spec is what an analyst gives you so that you understand what the database design and the business logic is. It is essential when dealing with customers that specifications are agreed to show that both the developer and the customer fully understands the business. Without this you will achieve missed dead lines, over budget code and the sort of bugs that are known as "features".
When working on your own, you need to understand the full project life cycle from conception to deliver and then on to support. How can you charge a customer for more work if the spec doesn't exist. The won't understand the need for an extra weeks coding because you "misunderstood" their requirements.
Consider how a £250,000 project works from conception to completion. It starts with a requirement, gets turned into a spec, code gets written, tests are run, Quality control passes and code gets delivered, support requests come in and so it goes on.
It doesn't matter what language, or technologies are used or the size of the project, it's always the same. Some might use UML as a spec, others use flow charts but whatever is used the business logic MUST be nailed and tests MUST be written. I've worked on multi million pound projects and 1,000 pound projects, I've worked for many different software houses, I've worked in-house and as a freelancer. I've used dozerns of different technologies, languages, databases and design techniques and worked on many different types of project from major financial institutions, telecoms companies to small factories to satelite systems. It doesn't matter. The difference between success and failure is a well defined specification so that both parties fully understand exactly what is needed, how the screens will flow and what the rules are.
It all boils down to one word COMMUNICATION. Many companies are bad at that and that's why they either fail or go badly over budget and time scales.
Tests are also incredibly important. They PROVE that your code works. Not just once but every time your code changes. On small scale projects and with the correct testing suite (as in the how I test railscast) tests can also act as a specification. There is nothing wrong with delivering tests to your user. It helps them see your progress as they see the tests start to pass and gives them confidence that you are on target and are actually doing what they have asked you to do and helps define clear milestones.
Also, Rails needs tests more than the vast majority of languages because it's interpreted rather than compiled. Typos are picked up by compilers and you need to fix them before you can produce an executable. With Rails the only way you will pick up on a typo is if you run the code or you have an incredibly good IDE, but you shouldn;t rely on an IDE and it's not possible to run every single line of code every time you make a coding change unless you have a test that does it for you.
It's so much nicer and quicker running
and watching everything go green than having to run through the same forms, pressing the same links, looking at the same data time after time.
Yes, you will still hit the browser and run through the views, but this becomes more of a cursory check to see what things look like than a test. If you find something wrong, write a test for it and you know it will never go wrong again without you knowing about it. I can not recommend that railscast strongly enough http://railscasts.com/episodes/275-how-i-test - It's what everybody should be doing.
When you just have a login screen and one page, tests don't seem to be so relevant but add more than a couple more screens, options and functions and you soon find yourself just hitting the new stuff and ignoring the old stuff coz it works, right? I can guarantee that at some point it will stop working! There are bugs in all software that is not tested thoroughly and when writing code, every single full swtop, comma or space can be the cause of a bug. It might sound pedantic (To those that are not in the game it is incredibly pedantic) but the best programmers are pedantic beyond belief.
I have made a design with GIMP to see the structure of the site and what I need and what I have to do. That's what you mean right?
That's one way. GIMP I would consider overkill, pencil and paper sketches are usually good enough. One analyst I know used to write specs on the back of a matchbox, for a multi million pound contract, and wondered why things went wrong!
I was thinking that working with different widgets made by myself, it would benefit the view of the page for me as developer. Am I thinking wrong, or just thinking to early on it? I just don't want to end up with chunks of code where I have to re look what they are meant for.
That's cool! It's an OO approach and OO is very good. Ruby is pure OO and that's what makes it a good language. Rails is is less OO because of the nature of views and HTML but it tries to be OO with the DRY (Don't Repeat Yourlsef) principle which is exactly what you describer you are trying to do. Keeping things small neat and descriptive is a very good approach.
In a professional environment a software department consists of not just developers, there are graphic designers, Quality Control staff, project managers, database gurus, network engineers, hardware engineers, support staff, the list goes on. When you are on your own, you have to wear all those hats and suit them all well. It's a daunting prospect and hard, but great fun
Obviously if you are writing a non mission critical project (Is there such a thing? I can't think of any) you can take a pretty lax approach and not bother with any of the above and get something approaching a usable piece of software but it will take longer than if you do it properly and it won't be as good.
Last edited by jamesw (2012-10-23 13:01:39)
What you want and what you need are too often not the same thing!
When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.
(Quote by me 15th July 2009)