Related
I have an question when I practice TDD cucumber java.
In order for developer like me to work together with business user or project manager, where shall the feature file stored? Confluence ? GIT/SVN?
If we store feature files in confluence, we probably need to synchronise these files from time to time.
If we store feature GIT/SVN, don't think business user/PM know how to use it.
A feature file has two major stages in its lifecycle. When its first being created its a collabaritive document that wants to be shared between all the involved parties. At this point in its life you can treat it like a user story.
The second stage is when the feature is implemented. As soon as you start running scenarios from it the feature is now code. This means it really should be stored in a SCM system (GIT), and it now belongs to development (they should be able to refactor it).
The difficult part is when review takes place and suggests that a feature should be changed somehow. Here you need the developer to talk directly to the reviewer and take responsibility for making the relevant scenarios available for discussion and refinement.
One thing that makes all of this much easier is the writing of highly abstract scenarios. These remove all the detail of how something is done, and instead focus on scenarios/features describing WHAT is done and WHY its important. In this way features are used much less in review, as the vast majority of review is about HOW something is done.
Whenever I have the need to design an API in Java, I normally start off by opening up my IDE, and creating the packages, classes and interfaces. The method implementations are all dummy, but the javadocs are detailed.
Is this the best way to go about things? I am beginning to feel that the API documentation should be the first to be churned out - even before the first .java file is written up. This has few advantages:
The API designer can complete the design & specification and then split up the implementation among several implementors.
More flexible - change in design does not require one to bounce around among java files looking for the place to edit the javadoc comment.
Are there others who share this opinion? And if so, how do you go about starting off with the API design?
Further, are there any tools out there which might help? Probably even some sort of annotation-based tool which generates documentation and then the skeleton source (kind of like model-to-code generators)? I came across Eclipse PDE API tooling - but this is specific to Eclipse plugin projects. I did not find anything more generic.
For an API (and for many types of problems IMO), a top-down approach for problem partitioning and analysis is the way to go.
However (and this is just my 2c based on my own personal experience, so take it with a grain of salt), focusing on the Javadoc part of it is a good thing to do, but that is still not sufficient, and cannot reliably be the starting point. In fact, that is very implementation oriented. So what happened to the design, the modeling and reasoning that should take place before that (however brief that might be)?
You have to do some sort of modeling to identify the entities (the nouns, roles and verbs) that make up your API. And no matter how "agile" one would like to be, such things cannot be prototyped without having a clear picture of the problem statement (even if it is just a 10K foot view of it.)
The best starting point is to specify what you are trying to implement, or more precisely, what type of problems your API is trying to address. BDD might be of help (more of that below). That is, what is it that your API will provide (datum elements), and to whom, performing what actions (the verbs) and under what conditions (the context). That leads then to identify what entities provide these things and under what roles (interfaces, specifically interfaces with a single, clear role or function, not as catch-all bags of methods). That leads to an analysis on how they are orchestrated together (inheritance, composition, delegation, etc.)
Once you have that, then you might be in a good position to start doing some preliminary Javadoc. Then you can start working on the implementation of those interfaces, of those roles. More Javadoc follows (in addition to other documentation that might not fall within Javadoc .ie. tutorials, how-tos, etc.)
You start your implementation with use cases and verifiable requirements and behavioral descriptions of what each thing should do alone or in collaboration. BDD would be extremely helpful here.
As you work on, you continuously refactor, hopefully by taking some metrics (cyclomatic complexity and some variant of LCOM). These two tell you where you should refactor.
A development of an API should not be inherently different from the development of an application. After all, an API is a utilitarian application for a user (who happens to have a development role.)
As a result, you should not treat API engineering any diferently from general software-intensive application engineering. Use the same practices, tune them according to your needs (which every one who works with software should), and you'll do fine.
Google has been uploading its "Google Tech Talk" video lecture series on youtube for quite some time. One of them is an hour long lecture titled "How To Design A Good API and Why it Matters". You might want to check it out also.
Some links for you that might help:
Google Tech Talk's "Beyond Test Driven Development: Behaviour Driven Development" : http://www.youtube.com/watch?v=XOkHh8zF33o
Behavior Driven Development : http://behaviour-driven.org/
Website Companion to the book "Practical API Design" : http://wiki.apidesign.org/wiki/Main_Page
Going back to the Basics - Structured Design#Cohesion and Coupling : http://en.wikipedia.org/wiki/Structured_Design#Structured_Design
Defining the interface first is the programming-by-contract style of declaring preconditions, postconditions and invariants. I find it combines well with Test-Driven-Development (TDD), because the invariants and postconditions you write first are the behaviours that your tests can check for.
As an aside, it seems the Behaviour-Driven-Development elaboration of TDD seems to have come about because of programmers who did not habitually think of the interface first.
As for my self, I always prefer starting with writing the interfaces along with their documentation and only then start with the implementation.
In the past I took another approach which was starting with the UML and then using the automatic code generation.
The best tool I encountered for this matter was Rational Rose which is not free but I'm sure there are plenty of free plugins and utils.
The advantage of Rational Rose over other designers I bumped into was that you can "attach" the design to your code and then modify on either code or design and the other will update.
I jump right in with the coding with a prototype. Any required interfaces soon pop out at you and you can mould your proto into a final product. Get feedback along the way from whomever is going to be using your API if you can.
There is no 'best way' of approaching API design, do whatever works for you. Domain knowledge also has a large part to play
I'm a great fan of programming to the interface. It forms a contract between the implementors and the users of your code.
Rather than diving straight into code, I usually start with a basic model of my system (UML diagrams etc, depending on the complexity). Not only does this serve as good documentation, it provides a visual clarification of the system structure. Having this makes the coding part much easier to do. This kind of design documentation also makes it easier to understand the system when you come back to it in 6 months, or try to fix bugs :)
Prototyping also has its merits, but be prepared to throw it away and start again.
We have an agile enterprise application built on JSP and Servlet without any design strategy.
This application was built in early 2002 considering 1000 users. After 2002, we received lots of requests from the marketing partners.
Currently, the application has lots of spaghetti code with lots of Ifs and elses. One class has more than 20,000 lines of code with a huge body of functions without abstraction.
Now, we need to support billions of records,
what we need to do immediately and gradually?
We have to refactor the application?
Which framework, we need to use?
How the usage of the framework will be helpful to the end users?
How to convince the leaders to do the refactoring?
How to gain the faster response time as compare to the current system?
Here is how I would approach this if I had appropriate company resources at my disposal (yeah right):
Get a good QA process going, with automated regression testing set up before making significant changes. I don't care how good you are, you can't put a system like that under unit test and reasonably control for regressions.
Map out interdependencies, see how much an individual class can be tested as a unit.
How do you eat an elephant? One bite at a time. Take a given piece of required functionality (preferably something around the increase load requirements) and refactor the parts of the class or classes that can be worked on in isolation.
Learn how do 3 above by reading Working Effectively with Legacy Code.
Convenient way to refactor the application.
There are no "convenient" or "easy" ways to refactor an existing codebase, especially if the codebase looks like spaghetti.
... what we need to do immediately and gradually?
That's impossible to answer without understanding your system's current architecture.
We have to refactor the application?
On the one hand, the fact that you have a lot of poorly designed / maintained code would suggest that it needs some refactoring work.
However, it is not clear that it will be sufficient. It could be that a complete rewrite would be a better idea ... especially if you need to scale up by many orders of magnitude.
Which framework, we need to use?
Impossible to answer without details for your application.
How the usage of the framework will be helpful to the end users?
It might reduce response times. It might improve reliability. It might allow more online users simultaneously. It might do none of the above.
Using a framework won't magically fix a problem of bad design.
How to convince the leaders to do the refactoring?
You need to convince them that the project is going to give a good return on investment (ROV). You / they also need to consider the alternatives:
what happens if you / they do nothing, or
is a complete rewrite likely to give a better outcome.
How to gain the faster response time as compare to the current system?
Impossible to answer without understanding why the current system is slow.
The bottom line is that you probably need someone from outside your immediate group (e.g. an external consultant) to do a detailed review your current system and report on your options for fixing it. It sounds like your management don't trust your recommendations.
These are big, big questions. Too broad for one answer really.
My best advice is this: start small, if you can. Refactor piece by piece. And most importantly, before touching the code, write automated tests against the current codebase, so you can be relatively sure you haven't broken anything when you do refactor it.
It may not be possible to write these tests, as the code may not be testable in it's current format. But you should still make this one of your main goals.
By definition refactoring shouldn't show any difference to the users. It's only to help developers work on the code. It sounds like you want to do a more extensive rewrite to modernize the application. Moving to something like JSF will make life a lot easier for developers and will give you access to web component libraries to improve the user experience.
It is a question which needs a lengthy answer. To start with I would suggest that the application is tested well and is working as per the specification. This means there are enough unit, integration and functional tests. The functional tests also have to be automated. Once these are in place, a step by step refactoring can take place. Do you have enough tests to start?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I have an application written in Java. In is stored in several files. It uses different classes with different methods. The code is big and complicated. I think it would be easier to understand the code if I have a graphical model of the code (some kind of directed graph). Are there some standard methods for visualization of code. I am thinking about usage of UML (not sure it is a correct choice). Can anybody recommend me something?
ADDED:
I consider two possibilities:
Creating the graph by hands (explicitly).
Creating graph in an automatic way. For example to use some tools that read the available code and generate some graph describing the structure of the code.
ADDED 2:
It would be nice to have something for free.
I tried using a number of UML tools and found that the reverse-engineering capabilities in most UML tools were not helpful for understanding code. They focus on designing needs and reverse-engineering capabilities often just ends up showing huge pictures of lots of useless information. When I was working on the Microsoft Office codebase, I found using a pen-and-paper more helpful that the typical design/modelling tools.
You typically want to think about doing this in a number of ways:
Use your brain: Someone else mentioned it - there is no substitute to actually trying to understand a code base. You might need to take notes down and refer back to it later. Can tools help? Definitely. But don't expect them to do most of the work for you.
Find documentation and talk to co-workers: There is no better way than having some source describe the main concepts in a codebase. If you can find someone to help you, take a pen and paper, go to him and take lots of notes. How much to bug the other person? In the beginning - as much as is practical for your work, but no amount is too little.
Think about tools: If you are new to a part of a project - you are going to be spending a significant amount of time understanding the code, so see how much help you can get automatically. There are good tools and bad tools. Try to figure out which tools have capabilities that might be helpful for you first. As I mentioned above, the average UML tool focuses more on modeling and does not seem to not be the right fit for you.
Time vs Cost: Sure, free is great. But if a free tool is not being used by many people - it might be that the tool does not work. There are many tools that were create just as an exploration of what could be done, but are not really helpful and therefore just made available for free in hopes that someone else will adopt it. Another way to think about it, decide how much your time is worth - it might make sense to spend a day or two to get a tool to work for you.
Once there, keep these in mind when going trying to understand the project:
The Mile High View: A layered architectural diagram can be really helpful to know how the main concepts in a project are related to one another. Tools like Lattix and Architexa can be really helpful here.
The Core: Try to figure out how the code works with regards to the main concepts. Class diagrams are exceptionally useful here. Pen-and-paper works often enough here, but tools can not only speed up the process but also help you save and share such diagrams. I think AgileJ and Architexa are your best bets here, but your average UML tool can often be good enough.
Key Use Cases: I would suggest tracing atleast one key use case for your app. You likely can get the most important use cases from anyone on your team, and stepping through it will be really helpful. Most IDE's are really helpful here. If you try drawing them, then sequence diagrams arethe most appropriate. For tools here I think MaintainJ, JDeveloper and Architexa are your best bets here.
Note: I am the founder of Architexa - we build tools to help you understand and document Java code, but I have tried to be unbiased above. My intention is to suggest tools and options given that this is what I focused on as part of my PhD.
The most important tool you should use is your brain, and it's free.
There's no reason why you have to use any sort of standard method of visualization, and you can use whatever media you like. Paper, whiteboard, photoshop, visio, powerpoint, notepad: all of these can be effective. Draw a diagram of classes, objects, methods, properties, variables - whatever you think is useful to see in order to understand the application. The audience is not only other members of your team, but also yourself. Create diagrams that are useful for you to look at and quickly understand. Post them around your workspace and look at them regularly to remind yourself of the overall system architecture as you build it.
UML and other code documentation standards are good guidelines for the types of diagrams you can do and the information you should consider including. However, it is overkill for most applications and basically exists for people who can't take personal responsibility for documenting without standards. If you follow UML to the letter, you'll end up spending way too much time on your documentation instead of creating your application.
It is stored in several files. It uses different classes with different methods. The code is big and complicated.
All Java code written outside the school is like that, particularly for a new developer starting on a project.
This is an old question, but as this is coming up in Google searches, I am adding my response here so that it could be useful to the future visitors. Let me also disclose that I am the author of MaintainJ.
Don't try to understand the whole application
Let me ask you this - why do you want to understand the code? Most probably you are fixing a bug or enhancing a feature of the application. The first thing you should not try to do is to understand the whole application. Trying to understand the entire architecture while starting afresh on a project will just overwhelm you.
Believe me when I say this - developers with 10+ years of solid coding experience may not understand how certain parts of the application work even after working on the same project for more than a year (assuming they are not the original developers). They may not understand how the authentication works or how the transaction management works in the application. I am talking about typical enterprise applications with 1000 to 2000 classes and using different frameworks.
Two important skills required to maintain large applications
Then how do they survive and are paid big bucks? Experienced developers usually understand what they are doing; meaning, if they are to fix a bug, they will find the location of the bug, then fix it and make sure that it does not break the rest of the app. If they need to enhance a feature or add a new feature, most of the time, they just have to imitate an existing feature that does a similar thing.
There are two important skills that help them to do this.
They are able to analyze the impact of the change(s) they do while fixing a bug. First they locate the problem, change the code and test it to make sure that it works. Then, because they know the Java language well and the frameworks 'well enough', they can tell if it will break any other parts of the app. If not, they are done.
I said that they simply need to imitate to enhance the application. To imitate effectively, one needs to know Java well and understand the frameworks 'well enough'. For example, when they are adding a new Struts Action class and adding to the configuration xml, they will first find a similar feature, try to follow the flow of that feature and understand how it works. They may have to tweak a bit of the configuration (like the 'form' data being in 'request' than in 'session' scope). But if they know the frameworks 'well enough', they can easily do this.
The bottom line is, you don't need to understand what all the 2000 classes are doing to fix a bug or enhance the app. Just understand what's needed.
Focus on delivering immediate value
So am I discouraging you from understanding the architecture? No, not at all. All I am asking you is to deliver. Once you start on a project and once you have set up the development environment on your PC, you should not take more than a week to deliver something, however small it may be. If you are an experienced programmer and don't deliver anything after 2 weeks, how can a manager know if you really working or reading sports news?
So, to make life easier for everyone, deliver something. Don't go with the attitude that you need to understand the whole application to deliver something valuable. It's completely false. Adding a small and localized Javascript validation may be very valuable to the business and when you deliver it, the manager feels relieved that he has got some value for his money. Moreover, it gives you the time to read the sports news.
As time passes by and after you deliver 5 small fixes, you would start to slowly understand the architecture. Do not underestimate the time needed to understand each aspect of the app. Give 3-4 days to understand the authentication. May be 2-3 days to understand the transaction management. It really depends on the application and your prior experience on similar applications, but I am just giving the ballpark estimates. Steal the time in between fixing the defects. Do not ask for that time.
When you understand something, write notes or draw the class/sequence/data model diagram.
Diagrams
Haaa...it took me so long to mention diagrams :). I started with the disclosure that I am the author of MaintainJ, the tool that generates runtime sequence diagrams. Let me tell you how it can help you.
The big part of maintenance is to locate the source of a problem or to understand how a feature works.
MaintainJ generated sequence diagrams show the call flow and data flow for a single use case. So, in a simple sequence diagram, you can see which methods are called for a use case. So, if you are fixing a bug, the bug is most probably in one of those methods. Just fix it, ensure that it does not break anything else and get out.
If you need to enhance a feature, understand the call flow of that feature using the sequence diagram and then enhance it. The enhancement may be like adding an extra field or adding a new validation, etc. Usually, adding new code is less risky.
If you need to add a new feature, find some other feature similar to what you need to develop, understand the call flow of that feature using MaintainJ and then imitate it.
Sounds simple? It is actually simple, but there will be cases where you will be doing larger enhancements like building an entirely new feature or something that affects the fundamental design of the application. By the time you are attempting something like that, you should be familiar with the application and understand the architecture of the app reasonably well.
Two caveats to my argument above
I mentioned that adding code is less risky than changing existing code. Because you want to avoid changing, you may be tempted to simply copy an existing method and add to it rather than changing the existing code. Resist this temptation. All applications have certain structure or 'uniformity'. Do not ruin it by bad practices like code duplication. You should know when you are deviating from the 'uniformity'. Ask a senior developer on the project to review the changes. If you must do something that does not follow the conventions, at least make sure that it's local to a small class (a private method in a 200 line class would not ruin the application's esthetics).
If you follow the approach outlined above, though you can survive for years in the industry, you run the risk of not understanding the application architectures, which is not good in the long run. This can be avoided by working on bigger changes or by just less Facebook time. Spend time to understand the architecture when you are a little free and document it for other developers.
Conclusion
Focus on immediate value and use the tools that deliver that, but don't be lazy. Tools and diagrams help, but you can do without them too. You can follow my advice by just taking some time of a senior developer on the project.
Some plugins I know for Eclipse:
Architexa
http://www.architexa.com/
nWire
http://www.nwiresoftware.com/
If you want to reverse engineer the code, you should try Enterprise Architect
have you tried Google CodePro Analytix ?
it can for example display dependencies and is free (screenshot from cod.google.com):
Here is a non UML Tool which has very nice visualization features.
You can mapping the lines of code per class / method to colors / side lenght of rectangles.
You can also show the dependencies between the classes.
http://www.moosetechnology.org/
The nice thing is, you can use Smalltalk scripting for displaying what you need:
http://www.moosetechnology.org/docs/faq/JavaModelManipulation
Here you can see how such a visualization looks like:
http://www.moosetechnology.org/tools/moosejee/casestudy
JUDE Community UML used to be able to import Java, but it is no longer the case. It is a good, free tool.
If your app is really complex I think that diagrams won't carry you very far. When diagrams become very complex they become hard to read and lose their power. Some well chosen diagrams, even if generated by hand, might be enough.
You don't need every method, parameter, and return value spelled out. Usually it's just the relationships and interactions between objects or packages that you need.
Here is a another tool that could do the trick:
http://xplrarc.massey.ac.nz/
You can use JArchitect tool, a pretty complete tool to visualize your code structure using the dependency graph, and browse you source code like a database using CQlinq.
JArchitect is free for open source contributors
Some great tools I use -
StarUML (allows code to diagram conversion)
MS Visio
XMind (very very useful for overview of the system)
Pen and Paper!
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
What do you do when your manager wants you to implement something in a quick and dirty way and you just know it's going to backfire?
My manager wants me to develop a web app for a client and to do it as quickly as possible. This is the first web app we're building for this client, and I think it's important that we do it right so that we will be able to build upon it when they inevitably ask us to enhance it or create a new one.
I'd like to spend some time setting up a framework (even if it's just something simple like Stripes), and configuring tomcat to use DBCP. I also think we should be using css templates, and giving at least a minimum amount of thought to the presentation and design of the app as, in my opinion, nothing looks quite as unprofessional as a poorly designed web page (unless it's an email with really bad grammar).
The problem is not so much that we're under pressure to get this done, but more that my manager does not feel he can justify billing extra hours for something he himself does not consider a necessity. His "just get it done ASAP" approach has already backfired a few times - once, for example, he told me not to design the code to handle a certain error situation as it was very unlikely to occur, and then when it did occur it was a big mess (that I had to clean up).
So what do I do? Do I really do it "quick and dirty"? Do I decide that the quickest way is to do it right and deal with the fallout if it takes me longer than he had hoped? Part of the issue here is that while I have done web development in the past, it's always been within an existing framework, so setting up a framework from scratch involves a learning curve for me.
Keep in mind that in his point of view, billing lots of hours makes the sale less appealing to the customer. This could be a good marketing approach (even if it's a horrible design decision) to write it quick and dirty now so the client likes it, and when they want changes he can bill more hours in the future because now he has the client "in his net".
But my advice is: look around you, he's in charge, so do it his way otherwise you're only creating problems for yourself. If you want to do things right, become the boss or find another company that does believe in doing things the right way. But simply going against the grain will only get you fired or in the doghouse with this guy, this is how life works.
Do quick and dirty. That's what they want, that's what they're willing to pay for. Take the money and deliver that.
Later, when the system is unmanageable because it's complete and utter chaos in there, and the client is in a position to want and pay for a robust, well-engineered solution, take the money and deliver that.
See, you get paid twice!
Furthermore, a crap solution will end up with some ongoing manual processes. These can be charged for. You get paid again!
No wonder your manager likes that approach!
In spite of the risks, I'll offer a management perspective on this. :-)
One challenge I've had with some team members is that they sometimes have a hard time seeing the big picture. That's obviously a statement that developers can make about their managers too--certainly managers (especially nontechnical managers) can fail to appreciate how hasty decisions now will lead to problems later. But I'll repeat that it's not just managers who can miss the big picture. Developers can too.
One time my team was supposed to develop a simple demo, and I had two people working on it. This was in all likelihood a throwaway demo. Was there some chance that we might end up keeping it and elaborating it? Sure. The chance was even decent--maybe (just making up a number here) 25% just for argument's sake. After nearly a month there was no deliverable and finally I called BS. It turned out that the developers were "engineering" the thing. Setting it up to be modular, pluggable, testable, etc. I told them to stop and I wrote the demo myself in a single afternoon. The "big picture" was to deliver a proof of concept to the customer quickly, and if for whatever reason we decided that we wanted the demo to evolve into an actual piece of production software--fine--in the worst case we throw away a single afternoon's worth of "hard work". And that was the worst case. It wasn't like I was able to make a few hundred lines of code that complicated.
No doubt sometimes managers make bad calls in the name of expediency, but just because I ask my team to do something quick-and-dirty doesn't mean I'm being short-sighted. Most of the time it means that delivering value quickly is more important in the situation that getting the engineering right. Unfortunately for some developers (a minority, to be sure), the very suggestion is blasphemy.
Start polishing up the resume.
If by 'first web application' you mean prototype then you should probably do it quick and dirty. Your client probably wants to see something before they commit to anything. You CAN do something quick however; without making it dirty. If you were careful about how you designed the web app and wrote it you could probably turn the web app into a work of art in no time after you've released the first version.
Allow your boss to learn from their mistakes.
If you always strive to protect them from themselves then they will never be able learn from their bad decisions, and you will always be trying to mitigate their next bad decision.
It is also important that you don't shield them from the repercussions of a bad decision, for example by quietly putting in a weekend for something that you feel guilty for.
You can and should of course do all this graciously with no hint of spite. Better still, diplomatically talking through the reasons for each approach as early as possible can work wonders.
Of course some people never learn ;-)
I feel that sometimes you have to make choices based on integrity and not fold to the demands of expediency or just because your under pressure from your boss. That doesn't mean I have an answer to your question, only you have to decide for yourself what is appropriate in this situation, with this customer, in your organization. Ask yourself:
How much does your boss really know about what the customer wants?
Do you know better than your boss? Is your relationship with the customer stronger?
Where is the pressure coming from to do it quickly?
Does the customer realize the costs/benefits associated with "quick and dirty"?
What kind of orginization do you work in? Would you consider yourself kind of more of a consultant (very close to the customer) than an employee or vice versa?
How well thought of is your boss (at your company or by the customer? Similarly how well thought of are you?
Is the code truly throw away or if its going to actually be used in the future
If it's just a demo for a client I think a quick-and-dirty solution is sufficient, but ultimately it is you're job as a developer to protest if you think it's going to backfire. Uncle Bob in Clean Code drives home the point well:
"What if you were a doctor and had a
patient who demanded that you stopped
all the silly hand-washing in
preparation for surgery because it was
taking too much time? Clearly the
patient is the boss, and yet the doctor
should absolutely refuse to comply.
Why? Because the doctor knows more
than the patient about the risks of
the disease and infection. It would be
unprofessional (never mind criminal)
for the doctor to comply with the
patient.
So too it is unprofessional for
programmers to bend to the will of
managers who don't understand the
risks of making messes."
This is a case where you need to manage up. Your boss doesn't see the need to implement a good design because he doesn't see that it's going to be easier in the long run. You can either convince him now or make sure that he sees the problem when modifications end up taking longer. At the very least you can steer his thinking over several small tasks so that you train him to go for good design over time.
Just do the quick-and-dirty implementation. Your job is to turn the spec into a working program, not to analyse tradeoffs between immediate costs & future benefits. I've worked with engineers who insisted on adding loads of layers of indirection, wrappers, unused code etc. which no-one was paying for, insisting they knew better than the PM. I've also been that guy (for a couple of years after I graduated) and it does not make you popular. I don't do it anymore.
Hmm, if your boss is only willing to fund quick-and-dirty and you disagree with the assignment, then find another job. Sounds like you don't like doing what you are being paid to do.
I'd go quick & dirty if that's what you've been asked for, as jcollum suggest, Ruby on Rails mught be a solution.
The reason I'd go for quick a dirty, is that if the user and your manager have a time frame and budget, and you can provide a stable solution that meets these and any other requirements, you should do so. Bottom line, if you're working for someone else, it is about meeting their requirements, not necessarily your own ideas about best practice or framework design. That said, if you can convince your manager and the client of the long term benefits of more upfront investment for a better long term outcome, go for it, and fair play to you.
My guess is once you have done a few more implementations, you will be better able to combine fast & good.
On the one hand you're not necessarily privy to all of the factors and pressures on the boss. Perhaps he/she knows this is a "one-off" and you won't be doing any business with this client.
The bottom line is that you're getting paid to implement whatever they tell you to implement. Yes, you have a responsibility to point out the pros and cons but, in the end, it's their decision.
But, to be safe, document EVERYTHING! If people start playing the blame game you can at least have your backside covered. (Might not do any good but always protect yourself.)
My advice would be to say that there is a quick and dirty way to meet the requirements within X days/weeks/months and that if there are major enhancements or features then there will be a cost to move to something larger that can handle what is now required.
Something to consider here is the idea of YAGNI if the client doesn't want anything more than the basics that they wanted in the first implementation. There is also the question of how much of a framework will you be building in this first go round.
If you were in charge, I would imagine you'd do it the "correct" way with a good design, even if it takes longer. The problem though is your manager is in charge. So, this sounds like a conversation you should be having with your manager.
Remind him (subtly) of the times his approach resulted in a mess and suggest that a bit more attention be made to the project. Suggest it may be a good marketing decision to put a little more effort into this project because the relationship with this client may be crucial. Don't get into an argument, just make yourself heard. At least it may get him to stop and think again about his decision - maybe he can have another conversation with the client about how much they're willing to pay.
In the end, respect his decision but make sure he does realize it was his decision and you're simply following orders. That way if a problem does develop in the future, it doesn't end up being your problem.
If he's not the approachable type, I think you're stuck doing it the quick-and-dirty way. I would document the situation though to minimize future ass-biting potential.
Ruby on Rails. If that's an option. I've heard plenty of times that it's the fastest way to get a CRUD site up and running well.
[edit]
Building your own framework is a huge waste of time, you're not going to be able to build a world class framework in any reasonable amount of time. Don't reinvent the wheel. I've heard plenty of programmers say "oh yeah I could build that soooo much better." Sure but could you build it even close to as good in the 5-10 hours of paid time that it will cost your company to just buy it outright? Unlikely.
If this is something that your company does frequently then you should talk your boss into letting you find an off-the-shelf solution to the "quick and dirty but still decent" problem. It might mean extra time now but will save time in the future.
[/edit]
I wouldn't be too judgemental on the boss. Like many people say, he/she has a POV just as you do. You need to adapt to handling this type of demand by learning some kind of rapid prototyping tool. I use the Microsoft platform for business and web applications (Java for scientific tools) so whenever someone wants to see a prototype web site I can hack something together on my local dev platform pretty quickly using ASP.NET. Usually for a prototype, ugly doesn't matter as much as functionality. If the customer knows a thing is possible then they will be apt to buy into the beautification (unless its internal - then who cares what it looks like - ha!).
Think about the fact that you are supposed to be a "professional software developer".
Being a member of a professional group means adherring to some codes and rules. That means that you don't just give up on your principles just because management tells you to.
If you really believe that setting up a framework and using CSS templates is necessary to deliver a product of proper quality, then insist on doing it.
Imagine if a construction engineer was told to do a bridge design in a quick-and-dirty way by his manager. Would he do it even if he knew the design was of poor quality? What would be the consequences if he did, for him personally and for construction engineering as a profession?
I think we as software engineers need to take more pride in our work, and show more professional responsibility.
I'd interpret "Q&D" to "Quick and Feature-Poor". Dirty is seldom Quick, even for a demo or proof of concept. Whatever you do to start, you'll be refactoring it anyway. Just give it the time available, and focus on YAGNI and Minimum Sufficient Solution.