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.
There are many CASE tools, many software for diagrams, drawing, documenting. But can they replace old good paper?
Every day, all day! (Okay, not all day, but a lot)
I actually had a debate a while back on the value of psuedocode, and I was giving my input on how much pen/paper and some pseudocode could work wonders at times :)
I use computers to solve easy design problems, but when I hit something really hard I break out the powerful tools - pen, paper and brain.
I use a whiteboard for design and pen-and-paper for TODOs.
Especially when it comes to doing some math before the implementation, there's nothing better than putting it down on paper first!
No software can ever replace the sheer ease of jotting down ideas and solution sketches using pen/paper! EVER!
Once you have your critical thinking down on a paper you can take your time to beautify them using fancy softwares and tools.
All the time I use pen and paper, I find them invaluable tools to programming! Making notes, etc, etc...
Using quick sketches is an invaluable tool in clarifying requirements with a client. You don't have to be Da Vinci to quickly encapsulate complex business logic or UI behaviors in some simple sketches. Leah Buley at Adaptive Path has great resources on sketching for UX. Programmers can learn these techniques as well. You'll save a lot of time using paper first, before sitting down in front of Visio.
I vastly prefer pencil & paper (or pen & markerboard) for real-time thinking. It can handle just about anything my brain thinks of. If I need to create any official artifacts, I'll take what I've drawn and set it up using a tool. But usually the initial copy is sufficient.
On a side note, I'm still not sure why just about everyone in college switched to laptops for taking notes. You don't have anywhere near the ability to express your thoughts in Word as you do on paper.
All the time, especially for complex logic with lots of conditional programming!
I always find it easier to jot down what I'm about to draw/model before using application tools.
All the time. When I want to draw/write something complex, I don't want to master a piece of software to do it. Also means there are no extra applications hogging up my system resources. Plus, there's something satisfying about writing at all angles on a piece of paper :).
Most of the times when I program you can see papers all over my desk, some are wrinkled on the floor and some are not.
I usually do my brainstorming on paper and preliminary UML diagrams.
If only I had a whiteboard... :)
I don't use pen and paper when working alone, but I always use them when working with other people, talking with customers and so on. I mainly use pencils to draw diagrams.
In my opinion, the most beauty about programming, its heart its about designing good algorithm or pseudocode.
I thought before that a paper and a pen could be a good idea but I went ahead to write it, They were easy programs though, short ones.
I just approached the PNP question, not that I expect to resolve it but curiosity rules me,
You do not need to face such a big problem to use paper and pen but since I got into that I realized how important It is.
It saves time, makes you more efficient.
General while you are programming you concentrate in small concepts like: Is this variable int...?
To have a big picture of the program, the best way It is a pen, that lets you concentrate on a problem and the go with the technical stuff, memory management, security, fast code...
If you go directyle into the keyboard, You might spend lots of time creating a big powerful function to realize at the end You do not need that because It happens that variable "a" will always be negative or whatever.
But please trust me I just started programming but happily I have discovered the world of the pen and paper.
I just realized that your question is actually nor a yes no question is it about comparison with diagrams, documenting.
Pen and paper before writing the program.
Documenting while You program and that It is a good idea to use a computer, I mean of course You can document it with papers but having you code full of /* */ It is just faster and better to read it and edit it again.
So there is a place for both things but stick with the pen at the beginning.
Related
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.
G'day,
I'm always trying to improve my performance as a developer and, after listening to this interesting podcast on the topic, I was wondering if people think it is worthwhile asking for feedback from colleagues.
I am thinking of obtaining feedback anonymously in the manner suggested in the podcast by using the Rypple site. And by asking one single, short question that directly addresses a specific aspect of my work or behaviour. For example, I'm looking at questions such as:
What can I do to improve the way in which the development team and the operational work together?,
How can I help you be more effective in your job interfacing with our major client?,
What parts of my technique could I improve based on the presentation I gave today?
etc.
Edit: I am not talking about general aspects, but specifically about how my performance as a developer can be improved. Communication and working with others is a large part of working with others in a company.
Edit: These additional questions are in response to a comment to my original question by JB King.
Further examples of possible questions that could provide useful feedback to help you improve as a developer are:
Am I becoming too focused or obsessive in my solution toolset?
What technology do you think I should learn to expand the team's capabilities?
What technology do you think I should focus on to improve the team's overall capabilities?
All of these directly address my personal progress as a developer.
cheers,
If you want to get honest feedback about what you are doing, you may want to find someone that observes what you do, and just ask their opinion, perhaps while having a beer. :)
But, it is important that you don't get defensive in any way, as you are asking for honesty.
And, you should consider making changes based on what they say, as that will help others to see that you are not only open to criticism, but willing to adapt, to become a better developer.
But, ultimately, you need to get an idea what type of programmer you want to be. Then it is useful if you have someone that you work with that exemplifies those qualities, then you can develop a relationship to see if they can help you become a better programmer.
For example, I knew an architect who would always pull a chair over and sit down when answering a question, so he was always on the level of the developer. That little action was so impressive to me, as it was a simple action, but it showed a willingness to bring himself to the level of others. That is how I want to be seen as I mentor others.
I think asking for anonymous feedback is bad, in part because it shows that there is a communication problem on the team, where people are not willing to be open with their feelings and opinions. The team lead should deal with that, as it could eventually be damaging to the team, if people keep their true opinions bottled up rather than expressing them, in order to help the team to be better.
I'd actually recommend not being anonymous when asking for criticism. One of your stated goals is to improve communication with colleagues; I think you might improve this better by actually talking with them instead of using a tool.
Being able to take criticism in person will show people you are confident and serious about improving. Face time is unfortunately underrated in our industry.
Yes, asking for feedback from colleagues is worthwhile. Often you don't know what you are doing great and where you could improve without getting at least a second opinion, if not a third, fourth, and so on.
Anonymity gives the benefit that those answering don't have to fear retaliation. Sometimes this works well and the result is honest feedback and sometimes people may enter stupid things trying to be funny. Que sera, sera.
I am not sure much good will come of it. I kinda agree with James on this one.
What might be better is to have some development workshops in your team. You could do it in such a way that each week 1 developer has the floor for an hour. Find a meeting room and a projector (if you have one) and let this developer present his / her discovery to the rest of the team.
At any point in time there are huge changes happening in the industry, so there should be a lot of areas to cover, for example - one week a certain developer could talk on up and coming changes in .net framework v4 (just an example), while another week yet another developer can talk about the benefits of shorter scrum iterations (again just an example).
The idea is the developer shouldn't be forced into presenting, and he/she should decide his or her own topic of interest.
This exercise might help strengthen communication in your team, and in this way the whole team is geared towards improving development skills.
This is the good idea, bad idea which I've seen is to take this idea too far, and expect developers to go away for weekends to so called coding dojos - yeah how fun (not).
Make sure these presentations are happening during normal paid business hours, or you'll have a riot.
"How can we do our jobs more effectively?" is a great question, and well worth asking!
But you should always discuss it openly. It's about as innocent a question as one can ask in the professional world, so if you tell people to discuss it anonymously, they'll think something funny is going on, even if that's not the case. And if you can't discuss such an innocent topic openly, your organization has serious problems.
Also, if you're going to ask questions like that, you need to pay attention to the answers, and either act on them or explain why you won't. People can handle, "Good point, but we're not going to do it that way, here's why." But it's pretty demoralizing to answer a question like that - especially if you made a lot of effort - and then feel like you've been ignored.
A good question that I've found to ask is: "Would you recommend this app to someone else?" and start the conversation there.
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 10 years ago.
After investigating a little bit scrum and kanban, I finally read this answer and decided to start using kanban, picking something from scrum (note that I'm working mostly by myself, and I do have read this question and its answers).
Now, my question is: which tool would be best to get started?
whiteboard and postit
agilezen.com
JIRA with greenhopper
a spreadsheet (possibly on Google Docs)
brightgreenprojects.com
Agilo
Target Process
something else (please specify)
Notes about each:
I would lean towards the whiteboard, but there are several drawbacks (e.g. cannot make automatic charts, time measurements, metrics, and sometimes I work from home - where I need it most - and it's not convenient to carry :-)
I don't want to remember another username/password (I promised to myself to signup only to OpenID-enabled services)
My employer has JIRA but my group doesn't use it - I might ask for an account (it shouldn't require another password) and maybe later involve the rest of the group. But I don't know if they are using greenhopper and if it's a big deal installing it.
I generally hate spreadsheets
maybe overkill?
I'd be happy to have a localhost instance, but it could be problematic to give access to the whole group (per network/firewalls) - not a deal-breaker but surely a concern
What I'd like to get from this?
being more productive
tracking how much time I spend in any given task, possibly discussing the issue with my supervisor
tracking what "blocks" me most often
immediately see where I am compared to my schedule
manage in a better way my long todo list (e.g. answering faster to the "what I should do next?" question)
Do you have any suggestion?
Note on the scrumish tag: read the Henrik Kniberg's PDF. He first introduced the definition of scrumish on page 9.
If I may, I think that you are on the wrong path. Anything else than 1. or 4. is overkill and pretty much useless for a non distributed team. So for a team of one person...
Seriously, if you can avoid using a web based application, just do it. First, unless you are already mastering Scrum/Kaban, you need to learn the process, not a tool. Don't let a tool dictate the process. Then most web based tools are just too much click intensive, less easy and fast to update, less transparent/visible than a spreadsheet and a physical board. They are really 2nd category options.
So, I'd go for a spreadsheet and a physical board combo. If you need some charts (I'm still wondering what kind of chart/metrics you want to generate and what value they provide), a spreadsheet is the ideal tool (but honestly, you don't need any tool to draw a burndown). If you need to work from home, take the spreadsheet (or use google docs) and post its with you. Let's be objective, the impediments you mentioned are actually not real.
Last thing, if you had chosen the simplest thing that can possibly work, you would already be doing Scrum, Scrumban or whatever. So, instead of looking for a tool, my advice would be to just start doing it.
agilezen.com seems like the ideal solution for you. I have used it in the past solo for myself and it is convenient. I would not let a prejudice against non-OpenID sites get in the way of making a good choice.
pick the tool you already have, and start using it; don't let the absence of the "perfect tool" become an excuse not to start
EDIT: pick the simplest thing that can possibly work. In your case that would be whiteboard and postit notes. These have almost no setup overhead and will provide a constant visual reminder of what you're supposed to be doing.
And I suggest that you get used to making decisions on your own, as you're going to have to be your own Scrum Master ;-)
In the interests of diversity ;-) www.kanbantool.com has just launched too. It's open beta and seems at first glance even more "lightweight" than agilezen.
Target process is good too
We've been using JIRA with Greenhopper for a few months, in an effort to go agile. I use it for both Scrum for development, as well as for my personal kanban. The software is pretty flexible, and I'm going to keep with it. The story/subtask management is really handy, and it's fairly easy to use. One thing I like is that you can add stories/cards quickly, and can customize the data. This allowed me to add definition of done fields, work order numbers, etc.
In short, we're happy with it.
Bright Green have just launched a free version of their tool. It looks good .. the free version is fully functional too: https://signup.brightgreenprojects.com/plan/Free
I've tried out another kanban product for personal use and am absolutely loving this one. Feels lightweight and simple but actually packs in a fair amount of functionality at the same time.
www.kanbanery.com (free for personal use)
A novel tool not mentioned before is getsmartQ (out of beta since Dec 2010)
Key characteristics: very intuitive, supports LWP, customizable forms, and task discussions
Pros
configurable workflow, mark overdue stories, mail notifications (e.g., for upcoming story deadlines), multiple story owners
Stories form completely customizable, per project workflow and story forms, different roles (people only creating stories)
very responsive GUI with partial updates
Apparently good support: I've asked a question and got a good answer within a few hours
Cons
no easy way to declare something as blocked or to distinguish type (feature/bug/..)
no API
no subtasks or story dependencies
In comparison to Agilezen it has a more sophisticated notification system, but apart from that still lacks important features (see cons above).
Note, getsmartQ is under active development and hence missing features mentioned above may have been implemented in the meantime.
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 10 years ago.
I would like to know How to create a fps-game with SDL lib?
Are there any books that explain with examples?
this wins for most open ended question. You could literally write a book. But lets settle for pointing in the right direction...
Step one, you will need good debugging skills for a project like this. Pick up Code Complete by Steve McConnell. Read the whole thing. The time invested will pay for itself more than anything else you could read/experiment with.
Get your hands on some source code of some game. ANY game. Make sure you see something simple before you see something big and complex, and keep in mind when you look at any game code that they may have had a combined team put WAY more time into it than you will ever have. The point in this is to see code structure.
Get a reference for 3D math, doesn't have to be THAT in depth, but you will need to know stuff like dot products backwards and forwards, be able to figure out how to create the matrix for your camera in the world etc. (even if your writing 0% of the rendering code)
(edit) Here's a great book on 3D mathMathematics for 3D Game Programming and Computer Graphics, Second Edition (Game Development Series) This isn't the kind you learn in college, it's more like a cross between trig and more advanced practical concepts: How to create a toolbox for yourself of simple physics, efficient collision detection, etc.
You will need to know something about rendering, and pipelines. SDL gives you a leg up, but make sure you understand the concepts of what it's doing.
Read up about practical system design. Your various systems will have to interlock. Think it out well. Your system can be just a good in C or in C++, it's the THOUGHT that is put into how your data/control will flow that will count, NOT how perfectly you emulate design patterns (though these are very useful as well of coarse)
Fundamentals of AI, not "real" AI, but functional AI; there is a big difference. State machines are great to start with, and sufficient for a simple FPS.
Learn a little about estimation and planning. You will not have time to do everything you would want to do to properly make an FPS. You will have to both triage AND learn how to triage; they are 2 separate things, the latter being mroe difficult. Experience is the best teacher here of coarse. (though the legendary McConnell has book on this as well)
Have a system to insert your gameplay into your level. If it is JUST you as a programmer, then your best bet is to write a plug in for an already existing editing program such as 3DS Max. I would highly recommend Max over Maya for a programmer. Maya script is nice, but it is more geared toward clever non-programmers. I find 3DS Max to think more along the lines of how a programmer would about creating and editing your world.
You can spend YEARS making tools to let you do this right, so you want to do things in such a way that you can edit fast and accurately
If you making your own editor, incorporate it into your game world.
If your world is not TRULY 3D and you want to make lots of level fast you can save your level data as something like this, which will save you a lot of time
Where X is a wall, the other letters are game objects which a dirt simple parser can translate into game objects and world coordinates
xxxxxxxxxxxxxxxxxxxxxxxx
xx..........P..........x
xxxxxxx...........I....x
xR....xxx...........E..x
xx.................0xxxx
xxxxxxxxxxxxxxxxxxxxxxxx
But it all depends on your game. My point is that you will need to resort to "ghetto coding" how you get your gameplay data into your world is very important and you need to think of something that is both fast for you to implement AND fast with you to work with.
And what it comes down to is what is your goal here? If it's to learn to code something the absolute right way, expect to spend most of your time iterating on code that seemed decent a month ago, but now that you realize what your requirements are, it could really use another pass. Do not be afraid to rewrite, you learn a lot by doing that, but if you goal is functionality, you will probably need to figure out where to hack some things in (like embedding gameplay data nad coordinates into code files) It IS ok to hack as long as you KNOW where you have hacked, and have carefully kept it separate from your good code so you can go back and properly write the code when you get the chance.
The bottom line is, you need to decide what your goal in this is, learning, or functionality and find the happy medium between.
Download the quake 3 sources at fileshack and learn from them.
Although the very long post is valueable in the long run, I feel it doesn't give the proper instant motivation of getting things on screen. Here's some facts, along with my opinion
-SDL is a 2D graphics library, you can't write an FPS in 2D, therefore you have to go with a 3D library, either DirectX, or openGL
-SDL has the ability to "sync" with openGL, using it for graphics, but there's not a whole lot of help online for that topic
I suggest you go to Lazyfoo.net, which is an absolutly amazing beginner's resource for game programming with SDL, it shows you how to draw to the screen, but also teaches you how to apply this to programming games. After going through this, you'll be able to make a tetris clone, or most other 2D type games
After this, you'll be ready for 3D(it's a lot more complex, requires a better grasp of math, and takes a lot more code to do simpler things) if you go with openGL, check out NeHe's Tutorials , they're currently working on a new set, using SDL with openGL, because the older tutorials, although valueable, are coded rather badly and use the windows(win32) API
keep in mind, game development is one of the most demanding, and rewarding programming you'll come across, so good luck
While not SDL specific, the NeHe OpenGL tutorials are an excellent place to start for learning about how to do 3D.
If this is your first game, you'll probably want to aim lower than an FPS. Writing a simple 2D Tetris game using SDL will teach you everything you'll need to know about that library.
Pretty much anything that says in the TItle the "Tricks of the Game Programming Gurus" is going to show you how to make a FPS game. LeMothe loves them.
Edit : forgot those titles.
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 10 years ago.
Which Computer-aided Software Engineering tools do you use and why? In what ways do they increase your productivity or help you design your programs? Or, in case you do not use CASE tools, what are your reasons for this?
The best CASE tool I had to work with is the Enterprise Architect from Sparx.
It's lightweight comparing to Rose (easier to buy and cheaper too) but extremely powerful. You could do great UML diagrams or database model or anything else you want but in a nice and organised way.
It greatly helps on the initial stages of the elaboration process as you could create domain model, do some preliminary use cases, map them to the requirements and present all of it in a nice way to the customer. It helps me thinking and I re-factor my design with it until I am satisfied enough to start proper documentation.
It is also very good for database models as it could reverse-engineer most databases very neatly.
The only (but quite serious) drawback it has in my eyes is that its documentation generator is, to put it mildly, crap. Getting a proper document from it is almost impossible unless you invest a significant amount of work in the templates and then it would be only OK.
I have used Rational Rose and a few other similar packages in the past. Mostly I have used them for the UML diagram elements and have not gone into the more detailed functionality such as code generation etc.
I mostly use them for aiding the design process and clarifying my own ideas. Often I find that, in trying to come up with a design for a componant, I end up needing to write down / draw what I want to happen so I can get a clear overview in my mind of what needs to happen and why. I have found that in a lot of cases, what I end up trying to draw is essentially the same as a predefined kind of diagram in UML, such as a Use Case Diagram etc. and by then adopting that style, it becomes easier to get my ideas on paper as I have some framework to work within.
So, I use CASE tools principally for thier UML / designing tools at a highish, semi-abstract level.
Oracle Designer
Not using any. No money for them.
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 10 years ago.
We prototype a design, GUI, just to analyze a particular problem, proof of concept, etc. Sometimes we throw away the prototype, and sometimes it ends up in the production code. We use different languages, technologies, strategies, and styles to prototype.
What are the different situations you prototype usually and how do you prototype? Any good resource out there to master the craft?
One hot title is Effective Prototyping for Software Makers. The issue is that there are several schools of thought.
Rapid Prototyping. Use fancy tools; get
something done soon.
Evolutionary Prototyping. Evolve from prototype to production.
Some of this is legacy thinking, based on an era where tools were primitive and projects had to be meticulously planned from the beginning. When I started in this industry, the "green-screen" character-mode applications where rocket science and very painful to mock up. Tools and formal techniques were essential to manage the costs and risks.
This thinking is trumped by some more recent thinking.
Powerful tools remove the need for complex prototypes. HTML mockups can be slapped together quickly. Is it still a prototype when you barely have to budget or plan for it?
[You can mock it up in MS-Word and save it as HTML. It's quicker for a Business Analyst to do it than to specify it and have a programmer do it.]
Also, powerful tools can reduce the cost of mistakes. If it only took a week to put something together -- production-ready -- what's the point of an formal prototype effort?
Agile techniques reduce the need to do quite so much detailed up-front planning. When you put something that works in the hands of users quickly, you don't have quite so much need to be sure every nuance is right before you start. It just has to be good enough to consider it progress.
What can happen is the following. [The hidden question is: is this still "prototyping" -- or is this just an Agile approach with powerful tools?]
Using tools like Django, you can put together the essential, core data structure and exercise it almost immediately. Use the default Django admin pages and you should be up and running as soon as you can articulate the data structures and write load utilities.
Then, add presentation pages wrapped around real, working data. Be sure you've got things right. Since you've only built data model and template-driven HTML pages, your investment is minimal. Explore.
Iterate until people start asking for smarter transactions than those available in the default admin pages. At this point, you're moving away from "discovery" and "elaboration" and into "construction". Did you do any prototyping? I suppose each HTML template you discarded was a kind of prototype. For that matter, so where the ones you kept.
The whole time, you can be working with more-or-less live, production users.
Personally, I believe a true prototype should not be much more than diagrams drawn on paper to demonstrate the flow of whatever it is you are trying to achieve. You can then use these documented flows to run through several scenarios to see if it works with whoever has requested the functionality.
Once the paper prototype has been modified to a point where it works then use it as a basis to start coding properly.
The benefits of this process are that you can't end up actually using the prototype code in production because there isn't any. Also, it is much easier to test it with business experts as there is not any code for them to understand.
Right now I just draw pictures. I would like to do more, but to get something to a point where the users would understand any better than a picture would cost to much time.
I am interested in seeing some of these responses :)
I should mention where I work is just me and one other guy to play the roles of project manager (collect data, design spec & app), dbas, coders, tool researcher/developer, et al that comes with the job of making an app for a small company.
For webapps, start with an pure (x)HTML + CSS mock-up, and then use a framework that makes it easy to implement the functionality.
Template-based frameworks are very good for this, but we've had some good experiences with JSF + Facelets + Seam, too.
The main reason for doing prototypes is reducing risk. Thus, we do UI prototypes, which are really not very helpful unless they actually do something that a user can play around with. Just as important, we also do prototypes to either prove that something can work or figure out how something does work.
I start off making a prototype that makes the most interesting part work, then I throw it away and move on to a new, more interesting project...
*kills self*