We Keep Coding

Is it wise to develop a prototype GUI before designing other part of the system?

Is it wise to develop a prototype GUI before designing other part of the system?
I am using Java for this small project. It will be a program with GUI and database connection. Say the database has table A and B, the user can choose which table to interact with. The program then display the contents of, say, table A in the GUI, and allows the user to change the content and submit the changes, or delete, or insert.

I think GUI should be developed first before any back-end development starts. There are couple of reason to do this:
You gain clarity on how model objects should interact.
Usability poses lots of restrictions on the way you want to pull data. You will probably want to develop and architect after you're 100% sure what constraints are there.
On business point, managers like to have a dumb function UI before any development start. Many times, the feedback leads in major changes in back-end assumptions. Which is a lot less pain than the case when you get a change request after the back-end development is over.
My personal experience goes that simultaneous development of GUI and back-end is a bit messy. Plus GUI provides solid expectation of behavior from back-end. Moreover, this approach makes sure all the developers, your client and your manager on the same page.

I agree with Joel Spolsky that it is a great idea to write a functional spec before writing code. Part of that spec should include a collection of screen mockups. #O.D. is right, Balsamiq is a great tool. It has saved me a lot of time in the past.
Once you have a functional spec in place that the business users are happy with, you will then have a better idea of how to design your system to meet the requirements. e.g. is high performance a requirement, domain model vs simple crud etc.
Then you should start by taking a single use case and building a vertical slice of your application. Build a GUI, service layer, persistence layer, database schema in one iteration. This will hopefully point out any problems with your design and give you the chance to modify it before you start building out the horizontal functionality.

I'd say yes and no.
No because you should design you application to be modularized enough so that your logic and data do not depend on UI design.
Yes because it is always smart to design everything before you actually start implementing it.
So what I mean is that you should make a concept, but not let your UI concept 'tie your hands' when you implement your logic. So if your managers clients don't like your conceptual UI, you can always change it without actually changing your application logic.

Well showing you GUI brfore starting to program is a very a good Idea, specially that you enable the enduser (Customer) to check if the UI is up to his expectations, which can save you lots of time.
In order to do that you dont necessarily need to develope a "real" prototype, you can use programms which enable you to fast design the UI of your App, including a minimal workflow simulation instead of full funcionality.
i had a very good experience with: Balsamiq can really recommend it

Writing spec before your code is always a good idea, because it makes you think. But most specs I have seen are not that good. And if the spec is too technical, users will at the end sign-off your spec without really understanding what are they going to get.
I have seen best results when either presenting the User Manual to the client, or by discussing mockups of the system one scenario at a time.
Note that half-baked mockups won't do the trick. You need your mockups to be fully populated with relevant data (Ever tried to discuss some screens with accounting while the numbers on the screen don't match? There's no way at all you could explain to them these are only dummy numbers...)
And the caveat of using mockups is that users will more often than not believe the app is "almost finished", whatever you do or say. It must be some subconscious thing, I'm not sure. But to avoid that, most of specialized tools have either only "black&white" look and feel or multiple skins you can switch to and from.
There is a pretty complete list of mockup tools here. Many of them are free:
http://c2.com/cgi/wiki?GuiPrototypingTools
My own tool is pretty popular: http://MockupScreens.com, I created it a long time ago exactly because of my own frustration with above mentioned problems.

Document displayer architectural question

I am thinking of working on an online homework submission system where students can upload their text documents that can viewed by somebody(Teacher/Professor) with viewing rights. This person can annotate/mark up/highlight this document and then can pass this document on for further review. After the review is done, this document is sent back to the student with proper feedback.
There are a lot of moving pieces here and I am having a tough time trying to figure out where to start. I am using this project as an exercise to design a scalable/secure/fast web-application using entirely open source tools that supports desktop like user experience but besides the UI-framework(Vaadin) and language(Java), I am having a little bit of trouble figuring out the roadmap needed to make some progress with this.
It will be great if the SO gurus can mentor me through this or provide me with a nudge in the right direction.
Edit: Thanks for the response. This is the standard three-tiered architecture that was described in the response. I need massive scalability and since the application will be primarily document centric and I may have to retrofit search at some later date, I would like to steer away from RDBMS. Since we have a massive amount of users posting their documents at any given time(lets say *.txt) files for the time being, I would need some kind of message queue to process this massive information influx. There has to be some kind of a fast transformation layer that takes the documents in all its formats and displays it in a format suited for annotations and markup....and the list goes on. Starting with the Domain model and moving down would be ideal but I am a little bit of a skeptic.

I'm a Java guy. How I would approach this problem will be,
Figure out the data model. What are the Objects that the system will be using.
Based on that design your database. You can use ORM frameworks like Ibatis or Hibernate ( Ibatis has a code generator which generates pretty much all the DAO's to access the tables. It gives you the CRUD methods and you can add on top of it).
Once you are done with that, then you can start designing your service layer. Its not a good practice to expose the DAO's directly to the controllers( MVC pattern). This is where your business logic should go in.
The choose one of the web frameworks available. The most popular java web frameworks are Spring MVC. You can also try Google Guice.
Final step will be to design your front end. I think your project will include a lot of javascript. So look into JQuery or EXT JS
I hope this helps you to get started with.

Not really a "full answer" but hopefully some food for thought.
I am using this project as an exercise to design a scalable/secure/fast web-application using entirely open source tools...
That's a great thing to be doing - so my question would be why worry about the architecture? I admit this is a bit strange coming from someone who see's themselves as an advocate for architecture, but "learning architecture" and learning new technologies can both be demanding. Maybe you just want to get up-to speed with one first, then tackle the other?
Architecting, designing and building a system that is "scalable/secure/fast" isn't trivial. In a "real-world" business driven case you'd have a system context to fit in with, and non-functional requirements to hit: these might suggest a different technology stack. Different key drivers will have a huge affect on how you approach things and what decisions get made - and of course the architecure would be built around that.
Edit:
I'd start with what was more important to you; then as I start on the "other" topic I'd be constantly checking what I'd learnt / my assumptions.
Depending on the two subjects there might be some "synergies" which suggest a different approach. Part of me wants to recommend doing enough on one to get a good basic grasp and then bring the other one up to a similar level - then move on. That way you're kind of more consistent.
Another part of me says - just do what's most interesting!
Should I plumb the depths of a given technology stack before moving forward or get the blueprint right from a tool agnostic standpoint?
As a start, you'd definately want to get a broad but shallow view; maybe go into some specific areas in a little more detail if they were of particular importance to you.
Or is my blueprint going to change because of the technology constraints?
By this I'm assuming you mean that: if you discover a "given technology works in such a way" and how it works it different form what you were expecting - then will this affect the blueprint?
It could do - that's why a broad but shallow view of the relevant technology should help you avoid the worst / most obviously bad mistakes. I'm also assuming that you have enough overal experience to know what you're looking at when you start doing this - that you can recognise an area that needs more detailed study before committing to a design.
At a high level, all you're looking to do is ensure you're not restricting options further down the path.

How to organize web services, so developers can easily find them?

We're developping a software for a large bank. So, the problem is that bank operates in SOA way. I mean, we have an entry point to the system and then there are WebServices fow everything, and when I tell everything, I mean EVERYTHING, there are like 3500 services.
Right now these services are just stored in a database table with (or without, sometimes) their descriptions, so, you can imagine the hell we're living in. I guess that sometime it's easier to implement new web service than to find the right one, this produces redundancy.
So, my question is, is there some way of organizing this kind of stuff? I mean, we have many bussiness lines and some common components, but I'm totally newbie in WS. Anyway, I need some kind of way to provide the developers with information what service they can use in any case.

A good documentation may help. Or google for the more sophisticated approaches like web service registries using WS-Inspection or UDDI.

I've seen it done with a simple web site where developers can find descriptions, WSDLs, etc. I think it's sufficient; I wouldn't recommend UDDI or buying a sophisticated tool. Yours is a problem in advertising and marketing.

High Level Logic: Rethinking Software Reuse in the 21st Century
http://highlevellogic.blogspot.com/2010/09/high-level-logic-rethinking-software.html

From where to start coding a software?

The project which I am going to start is my first project and it is very big. Though it's a great opportunity for me, I don't want me to trapped myself in a messed-code in the end so I have made a whole design of the software (software architecture) divided it into three tiers:
Presentation Tier ---- (will be implemented through Java Swing)
BusinessLogic Tier -- (will be implemented through EJB technology)
DatabaseLayer ------- (will be implemented with the help of Hibernate)
Q1. Which Tier should I select to start with?
I don't have any experience of Standard Product Development environment but I am sure that there is some specific order which is better than other.
Q2. I think that these things come under Good Design Principles and Best Practices. I have searched the internet for these kinds of resources and have found some good resources too but I would be grateful if you recommend me some resources that you know have short, to-the-point and quality content?

"my first project and it is very big"
Please don't do that.
Please do a small project first.
Write the "model" (business logic) first. This will be very difficult, since it's your first project. Keep it small and focused on just business logic that you can test and prove that it works.
Throw that away.
Now do another project.
Write the "model" (business logic) first. Based on lessons learned during the first project this will be much better. This will be hard, since it's your second project. Keep it small and focused on just business logic that you can test and prove that it works.
Write the persistence and the object-relational mapping second. Adding database persistence will be very hard, since it's only your first database project, and only your second project.
Throw that away.
Now, you have some idea what you're doing. Start a third project.
Write the "model" (business logic) first. Based on lessons learned during the first two projects this will be much better. By now, this will still be a lot of work because you finally understand what you're doing. The work, however, will no longer involve technical issues, it will now involve real issues around use cases and what the application actually does.
Write the persistence and the object-relational mapping second. Based on lessons learned during the first projects this will be much better. This will still be hard. Nothing makes this easy. It's only your second time, so you'll still make mistakes; there will be fewer mistakes.
Write the presentation last. Always.
This is actually the fastest way to do a large project when you don't already know the technology.

Do the implementation in vertical stripes: implement one capability of the project from the three layer so that the design could be validated from end-to-end.
The database layer could be skipped first, data could either be hard coded, not persisted, or simply store in test files first.

There are two approaches to this and both have advantages and disadvantages:
Top-down
First develop the UI and implement the data access and buisness logic where required for the UI.
Bottum-up
Develop the Database Layer first and then add the UI functionality later.
The first has the advantage that you have a (at least partially) working UI fast which is something the customers like, so it's the de-facto industry standard. The latter one provides a stable and complete Database and business logic layer but they usually have some overhead because it is not clear how the data is later required/accessed.

I think you should start with the business logic layer as this layer should be the one that dictates which functionality the other layers should have. If you start with the data access layer there's a risk that you will end up with a lot of YAGNI code, and furthermore any application should be centered around business logic and not persistence or presentation logic.
You should look into such best practices as DDD and TDD, and you could probably benefit from knowledge about MVVM or similar pattern too.

I would add to the existing answers:
Do not use lots of technologies you're unfamiliar with or only have a basic undersyanding; EJB, Hibernate, etc. They give you no appreciation of what's going on under the covers and add to the learning curve, pushing out your deadline. Instead go for something a lot simpler; e.g. RMI client-server application with JDBC or Spring/JDBC for persistence. You can always rework elements later but better to deliver incrementally than not at all.

Q1. Take a pen and a lot of paper and start designing. That way you make "plans" before writing code.
Q2. Using paper first help designing for quality; regular refinement, refactoring and review help maintaining quality.

Design Principles:
Start here
http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

How do you begin designing a large system? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
It's been mentioned to me that I'll be the sole developer behind a large new system. Among other things I'll be designing a UI and database schema.
I'm sure I'll receive some guidance, but I'd like to be able to knock their socks off. What can I do in the meantime to prepare, and what will I need to keep in mind when I sit down at my computer with the spec?
A few things to keep in mind: I'm a college student at my first real programming job. I'll be using Java. We already have SCM set up with automated testing, etc...so tools are not an issue.

Do you know much about OOP? If so, look into Spring and Hibernate to keep your implementation clean and orthogonal. If you get that, you should find TDD a good way to keep your design compact and lean, especially since you have "automated testing" up and running.
UPDATE:
Looking at the first slew of answers, I couldn't disagree more. Particularly in the Java space, you should find plenty of mentors/resources on working out your application with Objects, not a database-centric approach. Database design is typically the first step for Microsoft folks (which I do daily, but am in a recovery program, er, Alt.Net). If you keep the focus on what you need to deliver to a customer and let your ORM figure out how to persist your objects, your design should be better.

This sounds very much like my first job. Straight out of university, I was asked to design the database and business logic layer, while other people would take care of the UI. Meanwhile the boss was looking over my shoulder, unwilling to let go of what used to be his baby and was now mine, and poking his finger in it. Three years later, developers were fleeing the company and we were still X months away from actually selling anything.
The big mistake was in being too ambitious. If this is your first job, you will make mistakes and you will need to change how things work long after you've written them. We had all sorts of features that made the system more complicated than it needed to be, both on the database level and in the API that it presented to other developers. In the end, the whole thing was just far too complicated to support all at once and just died.
So my advice:
If you're not sure about taking on such a big job single-handed, don't. Tell your employers, and get them to find or hire somebody for you to work with who can help you out. If people need to be added to the project, then it should be done near the start rather than after stuff starts going wrong.
Think very carefully about what the product is for, and to boil it down to the simplest set of requirements you can think of. If the people giving you the spec aren't technical, try to see past what they've written to what will actually work and make money. Talk to customers and salespeople, and understand the market.
There's no shame in admitting you're wrong. If it turns out that the entire system needs to be rewritten, because you made some mistake in your first version, then it's better to admit this as soon as possible so you can get to it. Correspondingly, don't try to make an architecture that can anticipate every possible contingency in your first version, because you don't know what every contingency is and will just get it wrong. Write once with an eye to throwing away and starting again - you may not have to, the first version may be fine, but admit it if you do.

I also disagree about starting with the database. The DB is simply an artifact of how your business objects are persisted. I don't know of an equivalent in Java, but .Net has stellar tools such as SubSonic that allow your DB design to stay fluid as you iterate through your business objects design. I'd say first and foremost (even before deciding on what technologies to introduce) focus on the process and identify your nouns and verbs ... then build out from those abstractions. Hey, it really does work in the "real world", just like OOP 101 taught you!

Before you start coding, plan out your database schema - everything else will flow from that. Getting the database reasonably correct early on will save you time and headaches later.

The main thing is being able to abstract the complexity of the system so that you don't get bogged down by it as soon as you start off.
First read the spec like a story (skimming through it). Don't stop at every requirement to analyze it right there and then. This will allow you to get an overall picture of the system without too many details. At this point you would start identifying the major functional components of the system. Start putting these down (use a mindmap tool if you like).
Then take each component and start exploding it (and tying each detail with requirements in the spec document). Do this for all components, till you have covered all requirements.
Now, you should start looking at relationships between the components, and whether there are repetitions of features or functions across the various components (which you can then pull out to create utility components, or such). Around now, you would have a good detailed map of your requirements in your mind.
NOW, you should think of designing the database, ER diagrams, Class Design, DFDs, deployment, etc.
The problem with doing the last step first is that you can get bogged down in the complexity of your system without really gaining an overall understanding in the first place.

I do it the other way around. I find that doing it database-schema-first gets the system stuck in a data-driven-design that is difficult to abstract from persistence. We try to do domain model designs first and then base the database schema on those.
And then there's the infrastructure design: the team should settle on conventions on how to structure the program first and foremost. And then we work together to agree first on a design for the common functionality of the system (e.g., things everyone needs like persistence, logging, etc.). This becomes the framework of the system.
We all work on that together first before we split the rest of the functionalities amongst ourselves.

It has been my experience that Java applications (.NET also) that consider the database last are highly likely to perform poorly when placed into a corporate environment. You need to really think about your audience. You didn't say if it was a web app or not. Either way the infrastructure that you are implementing on is important when considering how you handle your data.
No matter what methodology you consider, how you get and save your data and it's impact on performance should be right up there as one of your #1 priorities.

I'd suggest thinking about how this application will be used. How will future users work with it? I'm sure you know at least a few things about what this application needs to handle, but my first advice is "think of the user and what he or she needs".
Draw it up on plain paper, thinking of where to section off the code. Remeber not to mix logic with GUI code (common error). This way you will be set to extend your applications reach in the future to servlets and/or applets or whatever platform comes along. Section in layers so that you can respond to large changes faster without rebuilding everything. Layers should not see any other layers than their closest neighbouring layers.
Begin with true core functionallity. All that time consuming fluff (that will make your project 4 weeks late), wont matter much to the wast majority of users. It can be added later once you are sure you can deliver on time.
Btw. Even though this has nothing to do with design I'd just like to say that you won't deliver on time. Make a realistic estimate on time consumption and then double it :-) I assume here that you will not be alone in this project and that people will come and go as the project progresses. You may need to train people midway through the project, people go on holiday / need surgery etc.

Split the big system to smaller pieces.
And don't think that it's so complex, because it usually isn't. By thinking too complex it just ruins your thoughts and eventually the design. Some point you just realize that you could do the same thing easier, and then you redesign it.
Atleast this has been my major mistake in designing.
Keep it simple!

I found very insightful ideas about starting a new large project, based on
common good practices
Test Driven Development
and pragmatic approach
in the book Growing Object-Oriented Software, Guided by Tests.
It is still under development, but first 3 chapters may be what You are looking for and IMHO worth reading.