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 9 years ago.
Improve this question
What is the most useful strategy when your application throws an exception in the middle of the demo, in terms of keeping the client's mood still positive?
If your client doesn't trust you, there's nothing you can really do. I build trust with my clients so when something like this happens, they believe me when I give them an explanation. And when I tell them what I'm going to do to prevent future problems, I make sure to follow through.
Depending if this is a "final" demo or if its a mid-project demo will also affect whether you can really alleviate the customers' concerns. There's very little you can do to make the customer happy if it's the end of the contract and there's no more budget for testing and bug-fixes.
One generic strategy I've used: if you have someone in the room document the exception/problem in front of the customer and let them know it is going into the bug tracking system for investigation and testing, that will demonstrate to them due-dilligence and alleviate some concern. You, of course, need to follow through and make sure to fix the problem.
Just tell the truth but humorously, like saying apparently our software is still not that perfect, and we are keeping making it perfect.
don't ever lie or try to cover it up. clients are not dumb.
I'd say it depends on what stage you're in. If you're selling something, my experience is that it is always preferable to just bring static material for demonstration. Powerpoints are alright, but printed screenshots that the clients can toss around the table are unbeatable. It allows you to only show exactly what you want, in a very controlled manner, while still looking very professional.
If the client has already bought the project, and the demo is related to, say, a launch that's coming up, the best you can do is to smile and say "as you can see, we're still working out a few quirks"
I usually let the client know up front that I'm running off a live dev environment so we might see some weirdness. If I am aware of parts that have issues (inconsistent crashes..) I let the client know about them before I show that section (along with the fact that production won't do this and I am working on it already).
Update: based upon other responses, I agree that early demos with static material are better for generating discussion.
The last time I presented a project to a conference, I planned a live demo, but I actually had a set of slides headed "If you can see this, the live demo didn't work!" with big screen shots. Inevitably the live demo didn't work (it needed a globally routable IP address and this wasn't available) and the slides were called for.
I think it personally depends on your relationship with the client and how satisfied they are with your product this far.
I usually tell them it was bad data from testing or jokingly say that was a test to see how the application handles errors (if you have a generic, catch-all error message/page). You can also use the time to reiterate the importance of user testing/acceptance.
I've never done a demo where I didn't set expectations beforehand. If this is a work in progress, make sure they know that up front. This goes a long way towards keeping them positive. EVERYBODY has issues during demos. Just smile, tell the truth and continue.
Probably the best way to help keep your client positive is to project positivity and confidence yourself. If you seem unsure of yourself it'll show as being unsure of your app.
Possible strategies:
Telling the audience "we're all going to stay here until whoever did that owns up".
Complaining about the prevalence of evil monkeys.
Seriously, I'm majorly against public product demos. Don't attempt demos until you're 99.99999% sure the damn stuff works. And even then it's a bad idea, you're setting yourself up to fail with all the variables that can go wrong - which may not even be with your software. If you must do it, attempting to impress customers with a flashy UI is best done one-on-one. That's the way we've always done it.
Is this shipping product or still under development?
Assuming it's a shipping product, just recover and move on. Work the room while recovering (rebooting, restarting the app, etc.) and don't dwell on what happened. Customers understand stuff happens.
I was an applications engineer and this happened frequently. IMO, the key to recovering from this starts at the beginning of the relationship / sales process / demo, not one particular event. Establish trust and build credibility with your audience as early as possible. If you have this and an exeption gets thrown, the audience will probably trust you enough to think nothing about the software failure and just move past it. Yeah, you will have the occassional person looking to crucify you regardless of what you do but that comes with the territory.
Be honest if someone asks (they probably won't) and never talk negatively about your product. I also found when questioned about a fatal error, it helps, and they are very foregiving, if you can explain what happened in terms the audience understands. It demonstrates your knowledge of the software process and goes back to trust.
Write down the Exception and why/how it occurred IMMEDIATELY. Then they will see that you will be fixing it.
Related
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 7 years ago.
Improve this question
I've been holding off on releasing a library I wrote because it is the first library which I'll be releasing publicly. Here are my concerns:
The library isn't complete it is in a very usable state, I'd say it is version 0.3, however it still lacks a number of features which I would like to at some point implement, and control how they're implemented (meaning not merging someones implementation).
I'm fearful of criticism, I know there are a few things which should be reorganized/refactored, but I wrote the initial class quickly to be functional for another project I am working on.
So when is the best time to release? Should I just throw it up on github and work on the issues post-release? Or should I wait until I refactor and feel completely comfortable with what I have written?
Most classes/libraries I see are always very elegantly written, however I have not seen any in very early release stages, are a lot of classes fairly sloppy upon initial release?
Release early, release often.
Criticism is a good thing as long as its constructive. Ignore the haters, pay attention to the folks filing bug reports and commenting.
The internal structure of the code matters, but it matters more if it works for its intended purpose. In general, refactoring will change how code works internally but will not affect how it is used. Same inputs and outputs.
You need to get something half-way
useful first, and then others will say
"hey, that almost works for me", and
they'll get involved in the project.
Linus Torvalds
Linux Times (2004-10-25).
It depends on why you are doing this. If it's to provide something useful and it's useful and has benefits that no other library has, then go for it. Just list the status and what's coming next.
If you are doing this to point to on a resume, get it in good shape (the code, not necessarily feature complete). Imagine a future employer poking around the code to see what it looks like, not downloading and running the code.
Whether you release the code in an incomplete state or not, it's always worthwhile having enough documentation to allow users to understand how to use the library.... even if it's only API docs. Make sure that anything incomplete is tagged as TO DO - it helps to maintain a target list of tasks to complete, and lets users know that the feature/method/whatever hasn't been forgotten.
Providing a set of code style/standard documents (perhaps with architectural notes on class relationships) allows other developers to contribute more readily, and in a manner that enhances the library rather than making it a hotch-potch of spaghetti code. It's never easy releasing a library, then having to refactor, while maintaining backward compatibility for users who have already taken up and are using that library in a production setting.
EDIT
Don't be afraid of criticism... it goes with the territory.
Some critcism can be constructive (take heed of that).
There'll be plenty of other people who criticise your code (for whatever their reason) without being constructive, or who just denegrate your work. The difference is, you've produced the goods, they probably haven't ever contributed to any OS product/library.
Users expect you to fix their problems immediately, or to write their code for them to use your library, or simply say "it doesn't work" without any explanation of what they mean. You have to learn to live with that 24x7x365.
But just once in a while, somebody will thank you for saving them hours of work, or for providing something useful... and suddenly all the stress and hassle feels worthwhile.
I read a document by Joshua Bloch, a pricipal software engineer at Google that talked a lot about the best type of API design. Basically, once you release it, it is more or less set. He says
Public APIs are forever - one chance to get it right
You can check out the slides here. It's definitely worth reading. I have a PDF of it as well; let me know if you need it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Some time ago I observed a few people trying to start an open source project. About a week after the project started it more or less completely dissolved, partly due to issues with how the project itself was managed.
The ideas behind the project were however very well thought and a lot of people are still interested in seeing it realized. So far no one have made any serious attempt to recreate it but a few of us are thinking about doing so. Of course we don't want the project to end the same way it did last time.
Now to my question. How should one start a successful open source project, where successful is defined as "the project does not die unless no one is no longer interested in the software itself anymore?"
Nice question, though it's more worthy of a book than a simple article, IMHO. And I hope it comes as no surprise that most of the best advice is social, not technical.
Here are some observations in no particular order:
Don't make a big infrastructure investment up front Unless you're already an Apache committer (or somesuch), don't shop around for a sponsoring organization or host your own servers, etc. Get up on GitHub in 5 minutes and don't look back. Put your energy in features.
Lower the barrier for entry Don't make potential contributors jump through hoops or undergo a background check before you'll listen to their ideas. Open source projects are networked economies... you need the energy of others. Even misguided activity is better than no activity on your project. You can always steer the codebase in a better direction later.
Minimize custom code Don't write a custom logging tool or XML parsing API... there are open source implementations that are (1) good enough, (2) better maintained, and (3) better than yours will become anyway. The more energy you can focus on your core problem, the better.
Live on the edge People and organizations will only invest in improving your project if they will directly benefit. Eat your own dogfood. Create dependencies in your other projects (like with your employer) on your open source project, even if it isn't "perfect" yet. (Hint: software projects are never perfect, they're either works-in-progress or dead.)
GitHub is a good place because it makes it easy for someone with even just a little bit of interest to fork your project and apply his/her patches to share with others.
But it's really about the attitudes around your project more than where you host it or other simple considerations like that. Be benevolent, serious, and judicious, keep a community going even though it will be pretty small for a while, and so on. Accept patches that should be accepted, reject patches that should be rejected. Just be a good person, developer, and manager, and apply those skills to your project, and it should be fine.
You are saying it yourself. The most important thing is that it should have people who care enough about it to deal with the problems instead of abandoning.
If no one cares enough, it will die again. Try a different project where you do care enough.
"A lot of people interested in seeing it realized" means nothing if nobody will actually do the work, fight the fights and stay put.
I don't think it's set in stone, but for me the biggest point is that your project should fill a gap in the existing ecosystem. In other words, there has to a space for your project to live.
Other than that, I can say that the best way to stay motivated is to work together with people. You say that there are still a lot of people interesting in seeing it realized. So, why don't those people do something about it? Surely they can do something. I think a common misconception is that contributing to an open-source project means you have to be able to write code.
There's more to it:
Write documentation
Create graphical elements
Discuss features and roadmaps
promote the project
etc. etc.
Sure, not all of these points are applicable to every project, but trying to get people to commit to a project will eventually help you and/or your projectmembers to stay commited as well. You don't want to let down all the other folks on the project, do you? ;-)
This is kind of off-topic on SO, but I'll bite anyway.
Most FOSS projects are started by a SINGLE person. Other people come on board after this person has produced some code that does something vaguely useful. So if you want to start a project, do it yourself, set up a site on something like Google Code, and write some code. The last is the most important.
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 1 year ago.
Improve this question
I am writing a system requirements document and need to include non-functional requirements relating to the usability of the system, but am not sure of the best way to express this.
"The system shall be easy to use" seems a bit vague to me, and not testable. Are there any 'official' standards/guidelines that can be adhered to relating to the usability of a program?
Usually, we try to hash out an application-specific definition of 'easy to use'. For example, for our current project, easy to use means:
-All delays in the system longer than .5 seconds will produce a dialog box that says "Please wait."
-It is possible to reach any given system function from the main window in less than 3 clicks.
-It is possible to accomplish any given task with just the keyboard, without the mouse.
-All buttons in the system will adhere to established button convention (link to established button convention regarding size, naming, position, etc.)
-All screens will have a help button. Each help button on a given screen must provide at least one 'topic' for each control on the screen.
-etc.
These sorts of things are testable, and taken together, constitute a 'pretty good' usability standard. That said, nothing substitutes for actual users trying it out.
Usability requirements are hard because the only way to know if your system is usable is by having real users try it out. How will you know if your requirements have been met? To do that, you need formal metrics for usability. Those metrics have to somehow be extracted from the results of usability testing, and if you abstract your usability testing to the point where you're just getting metrics out, you're missing out on its usefulness.
Some items like "must be able to do X with Y many clicks" or "system must respond in Z milliseconds or less" are useful, but they're actually functional requirements that have to do with usability, not usability requirements in themselves. It's quite possible (if not likely) that you can design and implement a system that meets all such formal requirements and is still frustrating for the users. Again, the only way to know is through usability testing.
Well, 'The system shall be easy to use' is exactly the kind of documentation that frustrates both designers and developers, so let's see if we can do a little better than that shall we? :)
To start with, you may find it helpful to sit down and imagine exactly who the intended user is. Give them a background, give them a bit of colour, then send them to your imagined application and try and figure out how they as individuals would want to interact with it.
Remember, different users are concerned about different aspects of usability. Don't just concentrate on the story path you think you would follow if you were using the application.
Next it might be helpful to break the site down into usability components. Does it have a lot of pictures? If so, what's the best way of presenting a lot of pictures to a user. Does it have a deeply nested menu structure? Might there be a better way than a sitetree to help your users navigate their way around?
Usability design patters will help you here. A good resource for design patterns for usability can be found here and here. Design patterns are good because they clearly explain to everyone involved how certain functionality is supposed to work.
Take a moment to consider accessibility in combination with usability. How the site work with javascript turned off is always a very good place to start and can be a great help to developers who tend to get very tired of watching their designer stick yet another <a> link on a page that is going to need to submit a form.
Remember, usability is about clarity and it begins with clear communication to the people building the system. If you can't speak clearly about what you want built how do you expect the developers to build something functional? Take the extra time to paper prototype if you have to.
My reply may be a little too 'web' focused to be of enormous use to you, but I hope it provides a few useful tidbits amongst my ranting.
Metrics & Usecases.
We have a number of personas that encapsulate our different customer types.
We have the user poweruser (George, he's a nerdy, university type),the non-tech person (Frank, who can barely use a calculator) and someone in between (Susie, she knows how to surf the web and can talk to tech support but don't ask her what emacs is).
Based on that we say:
For feature X, George should be able to access it without using the help or pausing longer than a few seconds, Suzie may need to look at the help but probably won't and if Frank does it better be real clear because he doesn't have much patience.
Now, for metrics, we also have usability study guidelines, like out of 10 people, 8 should be able to access Feature Y without looking at the help or be able to do it with 30 seconds.
Those are really subjective, but it might help you get going to in the right direction. Plus, it may help you talk to non-developer types who "just want it to work and be easy".
It wouldn't hurt to read Joel on Software articles too.
The most unambiguous way to include usability requirements in a requirements document that I could find is: make lots of screen mock-ups (and connect them with the "flow" of the performed actions, e.g. by having an arrow point from one item at image1 to the relevant next item on image2 etc.). If people actually see how something is supposed to work, it's easier to understand and leaves less room for interpretation.
Here's GNOME's documentation regarding human interfacing. This is intended as an example of how to specify, not what to specify (as I don't agree with everything they're saying in there).
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 5 years ago.
Improve this question
Lately, I've been going through a pretty weird phase. I feel the need to write/rewrite all the tools I use ( text editors,IDE's,libraries/modules ) and I don't know why . Even though this can be seen as a good thing ( because I learn alot of things in the process , and my software design skills are improving constantly ) ,
the weirdest part is that I throw away all the code after I'm done, so I kinda work in vain. I'm never satisfied with the code I write. Have you been experimenting this too? How did you get over it?
It sounds like you're driven by one of a couple different possible "syndromes" (or maybe more than one).
Not invented here syndrome (NIHS). This is where nobody's code is good enough, or does things in the way you want them done. So you think you can do it better.
How Does It Work? Syndrome (HDIWS). This where you are fascinated by a program and want to understand how it works, so you basically get down to writing it yourself.
Biting off more than you can chew syndrome (BOMTYCCS). This is where you think "That can't be too hard to do, so i'll just write it myself then I know what it's doing". Then, you get partway done with it, enough to make it kind of work, and you realize that your code sucks and that you made too many compromises to get it done quickly, so you throw it away.
Too cheap to buy it so you figure you can build it cheaper syndrome (TCTBISYFYCBICS). The name speaks for itself. The problem is that you get partway done, then you realize you've fallin into #3 above and think your time is worth more than whatever it is.
I have suffered from all of these, and more.. (Like the classic "Need to create an acroynm for everything syndrome (NTCAAFES)" ;)
I do this all the time (well, except for the throwing away part). Personally, I started to do this early in my programming learning (when I was a student); it got the point where I would examine the Java core source code and if I didn't like it, I would make my own/extend it. It got to the point where the running class joke was that I was going to reinvent Java.
Personally, I never got over it... Instead I found new ways to use the to my benefit. For example, rather than simply reinventing things, I found that there were things that I wanted that were/are not available anywhere else, so I would make them for myself. My first such project was a chat program. Sure many existed, but this was the only one my teacher didn't know about (hehe). Sure learned a lot about networking protocols through it, but once it was "done", my first action was to send it to all my buddies and we would chat while the teacher was lecturing... Soon enough he found out about it and has since then forced all his students to turn their monitors off while he is talking, but it was fun while it lasted.
Since then, I have been continuing to come up with my own projects that are useful to me, have at least one aspect that I will need to learn along the way, and one or more aspects of there not being a current program that solves the problem for me for free.
So in all, I recommend that rather than trying to reinvent the IDE and then throwing your code away, try to find some project or problem that you would like to solve on your own and use again. I believe that dogfooding (using your own programs) is the best any programmer can hope to achieve.
Put whatever code you write in a website and make it open source.
Let others discuss the code and make it better.
This helps you to improve your coding skills while you are giving back to the community.
Later you will be amazed to find that your code got better than what it was when you left it.
I think the nature of us as programming species is to want to control everything. We're total control freaks. Everyone has tons of reasons not to trust someone else's work. Any given day at the office can be proof of that.
However, in general, you'll be wrong. Chances are that tool/library/IDE/whatever was developed by a team that put a lot more time in to it than you'll be able to. Sure, it has it's flaws from the outside, but by the time you're done with your version, you'll probably find that yours has a few flaws of it's own.
It's just something you have to come to terms with.
In hindsight, it's not an entirely bad habit. It takes you out of your normal programming area and gives you exposure to other problems. Ultimately you'll be more versatile for it. If you continue doing it from that perspective, and mix it in with real productivity, I think it's perfectly healthy.
I commend you on this. You wouldn't be a good coder if you didn't obsess about the perfection of your tools, and also wonder how they were made, so:
Don't waste too much time,
make sure you release whatever you can open source,
but I look at it like a Padawan building his/her own light saber. It has to be done.
If you are just duplicating your existing tools, there is little value. But if have an idea on how to make it better, even in just one way, its worth it.
This way at the end of it you'll have a slightly better tool and you won't just throw it away.
I went though a similar phase with tools, but then I got more interested in other topics like graphics and games.
I only write tools when it's going to save me time (or, of course, achieve more in the same time).
There's plenty enough application code to be written without wanting to write tools as well.
If you're doing it in your spare time, then each to his own, I guess, but I find that the need to make money from the code I write kinda focuses my mind on what's important.
We programmers are flow-junkies. We enjoy the mental states associated with problem-solving and progress toward solution. Sometimes, when the projects at work get bogged down -- for a variety of reasons -- its tempting to turn to side projects as a way to get the flow-fix.
This isn't necessarily bad, as long as you're sharpening your tools or learning something, and it doesn't take time away from other responsibilities (work or relational).
You opted for the red pill didn't you? Somebody should have told you NOT to do that.
The problem is that if you really really like computers, and you spend way too much of your life thinking about them, you get to this point where the entire random/irrational state of software development -- that arbitrarily complex working mess -- seems to be clearly far more convoluted than necessary, even if you don't know what necessary is yet.
There is underneath it all, a fabulously amazing tool just waiting to be set free. It teases you from time to time, hiding in various programs, embedded along with various bits of data. Tantalizing functionality, that if only you could find a real way to join it all together to make one big super-cool system, you could ...
It's that purely mathematical sense that computers could in fact be something wonderful, if only they didn't suck so much.
Now take the blue pill, and get back to work ...
It also sounds like you might be really dissatisfied with the other work you are doing. I find that when I'm not enjoying my job, I tend to find anything else to do, and will get especially fixated on things that I can excuse as not being time-wasters because they are, on the surface, productive. Things like going back and cleaning up code that was really a one-time only ad-hoc, rewriting what already works, and making my own "improvements" on tools. If I'm right, it makes sense that you would then throw it out/walk away/find something else because if you are only doing that to avoid doing other work.
I've experienced it sometimes. For example, when preparing HTML documents for publication, I felt compelled to write my own tool to do it just the way I want. It's natural to want to make the world better. If you feel that urge - I suggest you go for it.
I think this is probably a good thing, if it's not getting in the way of getting things done.
But don't chuck it, even if it's rubbish, put it on the net somewhere, and when somebody else tries to do the same thing they can see yours and at the very least avoid making the same mistakes.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
While solving any programming problem, what is your modus operandi? How do you fix a problem?
Do you write everything you can about the observable behaviors of the bug or problem?
Take me through the mental checklist of actions you take.
(As they say - First, solve the problem. Then, write the code)
Step away from the computer and grab some paper and a pen or pencil if you prefer.
If I'm around the computer then I try to program a solution right then and there and it normally doesn't work right or it's just crap. Pen and paper force me to think a little more.
First, I go to one bicycle shop; or another.
Once I figure nobody invented that particular bicycle,
Figure out appropriate data structures for the domain and the problem, and then map needed algorithms for dealing with those data structures in ways you need.
Divide and conquer. Solve subsets of the problem
This algorithm has never failed me:
Take Action. Often just sitting there and being terrified or miffed by the problem will not help solve it. Also, often, no amounting of thinking will solve the problem. So you have to get your hands dirty and grapple with the problem head on.
Test. Under exactly what conditions, input values or states, does the problem occur? Make a mental model of why these particular conditions might cause the problem. Check similar conditions that don't cause the problem. Test enough so that you have a clear understanding of the problem.
Visualise. Put debug code in, dump variable contents, single step code whatever. Do anything that clarifies exactly what is going on where - within the problem conditions.
Simplify. Remove or comment code, poke values into variables, run particular functions with certain values. Try your hardest to get to the nub of the problem by cutting away the chaff or stuff that doesn't have a relevance to the problem at hand. Copy code into a separate project and run it, if you have to, to remove dependencies.
Accept. A great man said: "whatever remains, however improbable, must be the truth". In other words, after simplifying as much as you can, whatever is left must be the problem, no matter how bizarre it may seem at first.
Logic. Double, triple check the logic of the problem. Does it make sense? What would have to be true for it to make sense? Is there something you're missing? Is your understanding of the algorithm wrong? If all else fails, re-engineer the problem away.
As an adjunct to step 3, as a last resort, I often employ the binary search method of finding wayward code. Simply comment half the code and see if the problem disappears. If it does then it must be in that half (and vice versa). Half the remaining code and continue.
Google is great for searching for
error messages and common problems. Somewhere, someone has usually encountered your problem before and found a solution.
Pencil and paper. Pseudo Code and
workflow diagrams.
Talk to other developers about it. It
really helps when you have to force
yourself to simplify the problem for
someone else to understand. They may also have another angle. Sometimes it's hard to see the forest through the trees.
Go for a walk. Take your head out of
the problem. Take a step back and try
to see the bigger picture of what you
want to achieve. Make sure the problem you are 'trying' to solve is the one your 'need' to solve.
A big whiteboard is great to work on. Use it to write out workflows and relationships. Talk through what is happening with another team member
Move on. Do something else. Let your subconscious work on the problem. Allow the solution to come to you.
write down the problem
think very hard
write down the answer
I can't believe no one posted this already:
Write up your problem on StackOverflow, and let a bunch of other people solve it for you.
My method, something analytic-sinthetic:
Calm down. Take a deep breath. Focus your attention in what you're going to solve. This may include going for a walk, cleaning the whiteboard, getting scratch paper and pencils ordered, some snacks, etc. Avoid stress.
High level understanding of the problem. In case it is a bug, when does it happened? in what circumstances? If it is a new task, try to diverge of what results are needed. Recollect data, evidence, get acceptance descriptions, maybe documentation or a talk with someone that knows about the issue.
Setup the test playground. Try to feel happy with the tools needed. Use the data collected in the previous step to automate something, hopefully the bug if that's the case, some failing tests otherwise.
Start sinthesizing, summarizing what you know, reflecting that on code. Executing once and once more. If you are not happy with the results, return to step two with renewed ideas, diverge more: maybe apply tools (in order of cost) that helped before, i.e. divide and conquer, debug, multithread, dissassemble, profile, static analysis tools, metrics, etc. Get in this loop until you can isolate the problem and pass the over the phone test.
Now it's time to fix it but you have all the tools set up. It won't be so much trouble. Start writing code, apply refactoring, enjoy describing your solution in the docs.
Get someone to try your solution. She can eventually get you to step 2 but that's ok. Refine your solution and redeploy.
I'm interpreting this as fixing a bug, not a design problem.
Isolate the problem. Does it always occur? Does it occur only the first time run on a set of new data? Does it occur with specific values, but not with others?
Is the system generating any error message that appear related to the problem? Verify that the error messages are not generated when the problem does not occur.
Has anything been changed recently? Those are likely places to start looking.
Identify the gap between what I know is working (e.g. I can start up the app and attempt to do a query) and what I know is not working (e.g. it gives me an error instead of the expected results). Find an intermediate point in the code where it seems possible to look for a problem (does this contain valid data at this point?). This allows me to isolate the problem on one side or the other of the point I looked.
Read the stack traces. If you have a stack trace, find the first line that mentions in-house code. The problem is not in your libraries. Maybe it will turn out to be, but just forget about that possibly first. The error is in your code. It's not a bug in java, it's not a bug in apache commons HTTP client, it's in code written in your organization.
Think. Come up with something the system could be doing that can cause the symptoms you see. Find a way to validate whether that is what the system is doing.
No possibility the bug is in your code? Google for anything you can think of related. Maybe it is a bug in the library, or poor documentation leading you to use it wrong.
Logic.
Break the problem down, use your own brain and knowledge of each component of the system to determine exactly what is happening and why; then on the basis of this you will discover where the problem isn't, and hence determine where it must be.
I stop working on it until tomorrow. I usually solve my problem in the shower the next day. I find stepping away from the issue, and allowing my brain to clear, allows a fresh perspective on the issue.
Answer these three questions in this order:
Q1: What is the desired output?
I don't care if this is a napkin with scribble on it. I want something tangible that shows me what the end result is supposed to look like. If I don't get at least this far then I stop.
Q2: What is the input?
I find out what data I have coming in. Where this data is coming from from. What formulas I may need. What dependencies there might be on A happening before B. What permissions if any are necessary to get this data. I then ask Question 3.
Q3: Is there enough input to create the output?
If the answer is No then I go back to Q2 and get more input from whoever can give it to me.
For very large problems I break them down in Phases and apply Q1 Q2 and Q3 to each phase.
To paraphrase Douglas Adams, programming is easy. You only need to stare at a blank screen until your forehead bleeds. For people who are squeamish about their foreheads, my ideal architect-and-build for the bigger problems would go something like this. (For smaller problems, like George Jempty I can only recommend Feynman's Algorithm.)
What I write is couched in an on-site business setting but there are analogues in open-source or distributed teams. And I can't pretend that every, or even most, projects pan out this way. This is just the series of events that I dream about, and occasionally come to pass.
Get advanced, concise warning of what the problem is likely to look like. This is not the full, final meeting, but an informal discussion. Uncertainty in certain specification details is fine, as long as the client (or manager) is honest. Then take a piece of paper or text editor, and try to condense what you've learned down to five essential points, and then try to condense those to a single sentence. Be happy you can picture the core problem(s) to be solved without referencing any of your documentation.
Think about it for maybe a couple of hours, maybe playing with code and prototyping, but not with a view to the full architecture: you should even do other stuff, if you've time, or go for a walk. It's great if you can learn about a job an hour before home time in order to deliver a decision around midday the next day, so you get to sleep on it. Spend your time looking at potential libraries, frameworks, data standards. Try to tie together at least two languages or resources (say, Javascript on PHP-generated HTML; or get a Python stub talking RPC to a web service). Flesh out the core problems; zoom in on the details; zoom out to make sure the whole shape is still distinct and makes sense.
Send any questions to the client or manager well in advance of a meeting to discuss both the problem and your proposed solution. Invite as many stakeholders and your programming peers along as is convenient (and as your manager is happy with.) Explain the problem back to them, as you see it, then propose your solution. Explain as much as you can; pitch the technical details at your audience, but also let your explanations fill in more details in your own mental model.
Iterate on 2 and 3 until everyone is happy. Happiness is domain-specific. Your industry might require UML diagrams and line-item quotations, or it might be happy with something jotted on a whiteboard with an almost invisible drywipe marker. Make sure everyone has the same expectations of what you're about to build.
When your client or manager is happy for you to start, clear everything. Close Twitter, instant messenger, IRC and email for an hour or two. Start with the overall structure as you see it. Drop some of your prototype code in and see if it feels right. If it doesn't, change the structure as early as possible. But most of all make sure your colleagues give you a couple of hours of space. Try not to fight fires in this time. Begin with a good heart and cheer, and interest in the project. When you're bogged down later on you'll be glad of the clarity that came out of those first few hours.
How your programming proceeds from there depends on what it actually is, and what tasks the finished code needs to perform. And how you ultimately architect your code, and what external resources you use, will always be dictated by your experience, preference and domain knowledge. But give your project and its stakeholder team the most hopeful, most exciting and most engaged start you can.
Pencil, paper and a whiteboard. If you need more organization, use a tool like MindManager.
Andy Hunt's Pragmatic Thinking and Learning has a lot to say on this question.
Question: How do you eat an elephant?
Answer: One bite at a time.
One technique I like using for really big projects is to get into a room with a whiteboard and a pile of square Post-it Notes.
Write your tasks on the Post-it Notes then start sticking them on the whiteboard.
As you go, you can replace tasks that are too big with multiple notes.
You can shift notes around to change the order that the tasks happen in.
Use different colours to indicate different information; I sometimes use a different colour to indicate stuff that we need to do more research on.
This is a great technique for working with a team. Everybody can see the big picture and can contribute in a highly interactive way.
I think about it. I take anywhere from a couple minutes to a few weeks to mull over the problem and develop a general plan of attack.
Hammer out an initial solution. This solution is probably half-baked and one or more aspects may not work.
Refine that solution. Keep working on the problem till i have something that solves the problem.
(and this may be done at any step in the process) Ask questions on stack overflow to clear up any difficulties i'm having at the moment.
One of my ex-colleagues had a unique Modus Operandi. Whenever faced with a hard programming problem (e.g. Knapsack problem or some kind of non-standard optimization problem) he would get stoned on weed, claiming his ability to visualize complex state (such as that of recursive function doing operations on set passed on the stack) was greatly improved. The only difficulty, the next day he could not understand his own code. So eventually I showed him TDD and he has quit smoking...
I write it on a piece of paper and start with my horrible class diagram or flowchart. Then I write it on sticky notes to break it down to "TO DO's".
1 sticky note = 1 task. 1 dumped sticky note = 1 finished task. This works really well for me so far.
Add the problem to StackOverflow, wait about 5-10 minutes and you usually have a brilliant solution! :)
The following applies to a bug rather than building a project from scratch (but even then it could do both if reworded a bit):
Context: What is the problem at hand? What is it preventing, doing wrong, or not doing?
Control: What variables (in the wide sense of the word) are involved? Can the problem be reproduced?
Hypothesise: With enough data on what is occurring or required, it is possible to hypothesise, that is, to draw a mental image of the problem in question.
Evaluate: How much effort, cost, etc, will the correction require? Determine if it's a show stopper or a minor irritant. At this point, it may be too early to tell, but even that is a form of evaluation. This will allow prioritisation.
Plan: How will the problem be approached? Does it require specifications? If so, do them first.
Execute: A.K.A. The fun part.
Test: A.K.A. The not-so-fun-part.
Repeat to satisfaction. Finally:
Feedback: how did it come to be this way? What lead us here? Could this have been prevented, and if so, how?
EDIT:
Really summarised, stop, analyse, act.
Probably a gross oversimplification:
But really, this holds 100% true.
CONCEIVE
What are you without an idea? You may have a problem, but first you must define it more explicitly. You have a frozen pizza that you want to eat. You need to cook that pizza! In programming, this is usually your brainstorming session for coming up with a solution from the hip. Here you decide what your approach is.
PLAN
Well, of course you need to cook that pizza! But HOW! Will you use the oven? No. Too easy. You want to build a solar cooker, so you can eat that frozen pizza anywhere that the sun grants you power to do so. This is your design phase. This is your pencil and paper phase. This is where you start to form a cohesive, step-by-step method to implementation.
EXECUTE
Well, you are going to build a solar oven to cook your frozen pizza; you've decided. NOW DO IT. Write code. Test. Commit. Refactor. Commit.
Related question that may be useful:
Helpful points of view, concepts or ways to think about problems every newbie should know
Every problem I've ever had to solve on a computer has had something to do with solving a task in the real world. Therefore, I've learned to look at how I would accomplish something in the real world and map that to the computer problem.
Example:
I need to keep track of my student's grades and come up with a final grade that is an average of all the grades throughout the year?
Well, I'd save the grades in a log (database) and I'd have a page for every student (Field StudentID) and so on...
I always take a problem to a blog first. Stackoverflow would be a good place to start. Why waste your time re-inventing the wheel when someone else may have already solved a similar problem in the past? If anything you will get some good ideas to solve it yourself.
I use the scientific method:
Based on the available information about the programming problem I come up with a hypothesis about what the reason could be.
Then I design / think up an experiment that will reject or confirm the hypothesis. This could be observing something in a debugger or screen/file output. Or changing the program slightly.
If the hypothesis is rejected then repeat 1. The information gathered in 2. may help in coming up with a new hypothesis.
If the hypothesis is confirmed then the hypothesis may be refined/become more specific (repeat 1.). Or it may already be clear what the problem is.
This directed way of find the problem is much more effective than changing things at random, observe what happens and try to (inappropriately) use statistics.
No one has mentioned truth tables! But that's probably because they're usually only mildly helpful ;) (although your mileage may vary) I used one for the first time yesterday in my 8 years of programming.
Diagramming on whiteboards or paper have always been very helpful for me.
When faced with very weird bugs. Like this: JPA stops working after redeploy in glassfish
I start from scratch. Make a new project. Does it work? Yes. Start to recreate the components of my app one piece of a time. DB. Check. Deploy. Check. Until it breaks. Continue until it breaks. If it never breaks. Ok. You just recreated your entire app. Discard of the old one. When it breaks. You pinpointed the exact problem.
I think - what am i looking for?
What method best solves this problem?
Implement it with solid logic - no code
Pseudo code
code a rough cut
execute
These is my prioritized methods
Analyse
a. Try to find the source of your problem
b. Define desired outcome
c. Brainstorm about solutions
Try on error (If I dont want to analyse)
Google a bit around
a. Of course, look around on stackoverflow
When you get mad, walk away from pc for a cup of coffee
When you still mad after 10 cups of coffee, Go sleep a night to think about the problem
GOLDEN TIP
Never give up. Persistence will always win