Tag Info

Hot answers tagged

67

There's nothing wrong with working out your algorithms on paper first. Not so much for everyday coding, but for more complex algorithms, professional programmers work them out on paper or a whiteboard all the time, especially if a graphical format makes it more clear. For a student, every program is complex. If you want to get better at designing ...


63

This is a perfect example of the excluded middle fallacy. Yes, writing out the whole program on paper before you touch the actual keyboard is a bad idea. But that doesn't make the opposite extreme--immediately jumping into the coding and starting to hack away--a good idea. In fact, it's even worse. It's very important to understand what you're trying to ...


33

I think (and I may be out on a limb here) that ALL projects should have a bit of classic waterfall: The initial analysis and specification phase is essential. You must know what you are doing, and you must have it it writing. Getting the requirements in writing is difficult and time consuming, and easy to do badly. Thats why so many skip it - any excuse will ...


33

You think Michelangelo just climbed to the top of the Sistine Chapel and just started drawing? Test drawings were made. Approvals from the Pope were needed. There was scaffolding to be built. Templates made to guide the group of other artists. The restoration was even more complex. If I want to build an application and I don't have to consider the design ...


27

if you want to be just a programmer, then you wait until someone else has figured out what the client needs and then code that if you want to be a developer, and this is your client, then you take your client's hand and gently walk them through the dense scary forest of possibilities until together you find the happy bunny-filled meadow at the intersection ...


25

I'm still amazed that many people think that TDD means writing unit tests first. No it means writing tests you will need before you write the code. The test actually can be unit test, integration test, end-to-end test and of course performance test (well you will probably not write performance test before the tested code but it doesn't mean you should not ...


20

I think it is all about forming a balance. It is impossible to think of everything before you type it all out, which is precisely why the Waterfall model is so broken. At the same time, if you do too little thinking, you can cause a big mess for yourself when you get past the first several iterations. After all, you cannot beat all code into shape, and it ...


20

The premise of the analogy is wrong: many writers outline or at least think out what they are going to write before they start writing, and many painters and architects will do dozens of studies and sketches before they start on their actual "work". Given that the analogy is wrong, the answer is yes--programmers should work like writers, painters and ...


20

What is the reason for [their estimate of 2 days taking 8 days], is this common for programmers? It is, if: It isn't actually clear what they're supposed to do, so they take more time getting it right (and they should then say so, not guess about how long it will take) They're unfamiliar with the task at hand (then they should mention that and include ...


17

Why is the argument that you'll produce a better quality product in Java weak? Assuming that the technology you are familiar with can be used to (relatively) easily implement the solutions you require you should go with the technology you (as developers) know for several reasons: You are more familiar with the libraries, frameworks and tools so you'll ...


17

Go for it! If we call what you are doing thinking and designing your solution, then it makes sense your process will be much faster than just blasting out code. People like to think (and the noisy ones like to tell us) that their way of doings is better. But everyone's ability and skill mix is different. So do what works for you. As you gain practice, you ...


16

They're not actually user stories. They're stakeholder stories. Unless the software is actually paid for direct by users, it's rare that a story is created entirely for their benefit. I give you a couple of examples: keyworded articles, which allow advertisers to have more effective adverts CAPTCHAs, which are there to stop moderators having to deal with ...


16

The general techniques are somewhat common-sense, the important thing to know is that they don't require much technical expertise. The starting point with planning is to identify the exact problem that needs to be solved and have a clear and unambiguous requirement. If you don't have that, your estimates will be incorrect. Having this documented in some ...


15

Right at the very beginning! You want the community to feel that they have a genuine stake in your project, otherwise they will feel like they are being used as free labour. All communication should be over a public mailing list or forum, again this enhances the idea of the community. You can mitigate the 'design by committee' problem by laying out a ...


15

According to the Scrum Guide: The Sprint Planning Meeting is time-boxed to eight hours for a one-month Sprint. For shorter Sprints, the event is proportionately shorter. For example, two-week Sprints have four-hour Sprint Planning Meetings. That generally works for me.


14

P. Brian Mackey is right about TDD being useful - and any unit tests will improve things dramatically. As a tester, I can tell you that a thorough unit test suite dramatically decreases the number of bugs, and limits the remaining functional bugs to mostly a few predictable areas where I can focus my testing (mostly integration points / environmental ...


13

He seems to like things being defined formally, so a timer would be a good idea, since planning poker is defined as having set amounts of time for people to speak. He's got the wrong idea about estimation too, everyone estimates against the story and not the implementation, which is why you get such variance. For example some people may be ignorant of a ...


12

Good estimates take some time. If somebody wants an estimate now, let them know you'll get back to them. It's better to give them a better estimate later and make them squirm a bit now, than give them what they want, and fail to deliver because you failed at estimating. Break the task down into smaller tasks. Large tasks cannot be estimated effectively. If ...


12

When you have the privilege of starting on a new project you have a blank canvas--which is both exciting and daunting at the same time. I work in iterations, and this is how I divide up the work: Start with the goals for the project. Goals are necessarily the most vague, but helps you focus on what the client or user intends to do with the software. At ...


11

The team is the one that makes the commitment. In our team, if we feel we're waiting for (for example) an external developer, we have learned to say that we're not willing to pick up the story. The story is not in a fit state to pick up. Theres a very good chance that the late, unexpected, or different delivery from the external resource will mean your ...


11

Ultimately it depends on whether you are 100% confident that the external provider will deliver something you can use by the time you need to use it. If you cannot be sure that they'll deliver in time they don't add the story to the sprint. However, even if they've always delivered in the past there's no guarantee they'll deliver this time. You should let ...


11

when I make decisions based on assumptions [...] I get corrected Then don't make so many assumptions - clarify beforehand, ask! If the person you have to ask is not available all the time, prepare a list of questions. And repeat that whenever new questions arise, regularly, perhaps daily! This process happens multiple times throughout a project ...


11

I'm not sure if the customer really "made a mistake": They had a solution which started with a very small initial investment, which could be maintained in-house, which grew together with their reqirements and which just worked. If the current solution "works for the scope now", the argument that Access is completely unsuitable for a project of that scope ...


11

You can solve this problem with a free and simple solution. In our team, if we ever forget our planning poker cards we instead use our hands i.e. We clench our fists and show our estimate all at the same time. We find that this approach works very well as usually our estimates are on average at most eight points and any 13 point estimates are usually ...


10

Velocity is a measure of the team's capacity to do useful work (as opposed to Drag). Infrastructure tasks still deliver end-user value, albeit indirectly, by making the team more efficient in the long run. I have no problem tracking these things as user stories (the user is the dev team in this case) and prioritizing them appropriately. A Product Owner in ...


10

As long as it needs to last, no less and no more. Anything else isn't Agile. If you have a team of 2 - 3 developers and are doing 1 week sprints anything more than a hour is probably counter productive. If you have a team of 15 people and 2 weeks sprints you are looking at all day, anything less isn't detailed enough. It takes experience to get it mostly ...


10

If you are going for a complete rewrite, why not also consider if you should be using php at all? A change/upgrade of technology might be the catalyst you want to improve your design/scalability/maintainability etc...


10

For these types of things, I recommend that you file a defect, issue or an enhancement request as appropriate so that it can be tracked, scheduled if need be, and not forgotten. Get your primary and most important work done before you start tackling the extra. Not only does this help ensure you hit your own deadlines, it also gives others a chance to ...



Only top voted, non community-wiki answers of a minimum length are eligible