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 a lot into agile methodologies. Some papers I've read at Martin Fowler's website looked thoroughly unflawed to me to say the least, and I was wondering what agile practices are most suited to game development, particularly for small-budget, small-sized and inexperienced team projects (bold because it's really important).
Concepts such as refactoring look like they could absolutely combine with a small and inexperienced team. The idea of "embracing the change" also combines with inexperienced teams whose ideas twist and turn all the time. But things like TDD are rather problematic.
It's hard and suboptimal to test a class that interacts with Direct3D, for example. It doesn't make much sense.
I'd be most deeply grateful if you could list a bunch of practices that made sense for game development. Ones that aid in the organization of artistic production are a plus. Citations of real-world cases are another plus.
Thanks in advance.
edit --
Plus, my team is composed of 3 people: one programmer, one graphics designer and one programmer/graphics designer combomix. We do not have a client, so we must make all decisions alone.
I've read in an article by Fowler that agile sort of depends on developer-client interaction, but he also mentioned that clients unwillingly to adhere to agile could still be well-served by agile development (the article was called New Methodology). How does that apply to my case?
Conclusions --
I think questions at StackOverflow can help others too, so I'll try to summarize my thoughts on the subject here.
Through the use of mock objects, even hard-to-test elements such as graphics interfaces and their relationship to client classes might be manageable.
For example, instead of letting every client of the interface truly test its use under many conditions (fullscreen/windowed mode switch, for example, which affects almost everything in the game), they could be tested against a mock that seemingly to them behaves the same as the original class, and additionally test that mock's fidelity to the original object.
That way, the slow part (actually opening the window and stuff) is only done once in checking the mock's fidelity to the implementation, and everything else just run smooth over the mock. [thanks to Cameron]
A BDD mindset aids at easening the paranoid seek for thorough testing of units, "replacing" testing by specification of actual behaviours, not squeezed units which in many cases are better off let untested (or only indirectly tested, if you prefer putting it that way) to avoid too much one-to-one test vs. unit (class, method, variable, etc) parity, which adds to test (now "specification") fragility. [thanks to Kludge]
I would recommend trying out VersionOne (www.versionone.com). VersionOne is free for a small team working on a single project, and has easy-to-use tools for agile status tracking and project planning. Their site also has links to explanations of the various Agile development methodologies.
There are different flavors of Agile development; I'd recommend taking a look at the Extreme Programming (XP) model, as a good example:
http://www.extremeprogramming.org/map/project.html
Agile development is as much concerned with project planning and requirements tracking as it is with the actual programming practice.
The idea is to make sure you record game features that need to be developed (as "user stories"), give a (very rough) estimate of how long each will take, and figure out which ones are important. Box out a small amount of time for each release, and schedule the most-important, least-expensive features that you can release in that time. This system ensures steady forward progress, protects you against constant, unpredictable priority changes, and makes sure you don't develop a huge monolithic code base that doesn't work.
With regard to Test-Driven Development, I think Cameron's and Andrew Grimm's comments are both on point. You can do a lot more unit testing if you abstract away things like graphics API calls.
You definitely want to look at Extreme Programing (XP), take a look at Kent Beck's Extreme Programming Explained: Embrace Change, 2nd Edition
The most useful thing you can do though is to do some research on Behaviour-Driven Development which is basically Test-Driven Development done right. It takes the focus off of tests and back onto specifications. You don't worry about what classes do so much as what behavior your program exhibits.
So saying you aren't going to use TDD, or BDD, is just plain crazy talk. One of the core concepts of Agile development is developing your software from your tests/specs. You have to get out of the mindset that tests/specs are testing your classes. That's not really what they're for. They are for describing the behaviors your application should exhibit then using that test/spec to write the behavior into your application.
You might write something like this
Describe Startup
it "should display a welcome screen" do
game = Game.new
game.start
game.output_buffer.should match("Welcome")
end
end
Then you go write the code to make it happen. You describe the code you want, then you go write it. It allows you to write your code in little, bite sized chunks and best of all when someone else picks up your code they can run the tests and see that everything works. When they want to add new functionality they use the same process so now when you go back to the code you can have faith that their code works too.
Agile/Lean methods such as Scrum, XP and Kanban have been successfully applied to game development since 2003.
There are a number of blogs including:
http://blog.agilegamedevelopment.com/
and a book as well. See the book link in the blog above.
If you have good model view controller (MVC) separation, you should be able to test "business logic" without graphics. For example, testing that a given weapon produces the correct amount of damage, can't shoot through walls, and has a given area of effect.
Agile is not at all compatible with GameDev. They are two completely opposite methodologies.
Agile is about development being flexible to changing business requirements and breaking down projects into clear and managable deadlines and work units. GameDev is about regularly and dramatically changing business requirements without caring about the impact on development, and breaking down development teams through unmanagable deadlines and volumes of work.
I don't believe there's actually any element of Agile that is incompatible with game development. I think you're mistaken with respect to difficulty of testing graphic functions; running a graphic function generates an image, and it's easy to compare images to manually-approved "golden masters" (see Approval Tests for one way to go about this).
Refactoring is a fine technique, but it should be done with a safety net of unit tests. The best way to get unit tests is to develop your code test-first, so TDD is another Agile practice you should be following. And it's all better - refactoring, testing, and the rest - if you pair. You have enough people on the team to be pair programming. Try it and see how much faster you get running tested features!
Related
The idea of TDD is great, but i'm trying to wrap my head around how to implement a complex system if a design is not proposed upfront.
For example, let's say I have multiple services for an payment processing application. I'm not sure I understand how development would/can proceed across multiple developers if there is not a somewhat solid design upfront.
It would be great if someone can provide an example and high level steps to putting together a system in this manner. I can see how TDD can lead to simpler and more robust code, I'm just not sure how it can bring together 1) different developers to a common architectural vision and 2) result in a system that can abstract out behavior in order to prevent having to refactor large chunks of code (e.g. accept different payment methods or pricing models based on a long term development roadmap).
I see the refactoring as a huge overhead in a production system where data model changes increase risks for customers and the company.
Clearly i'm probably missing something that TDD gurus have discovered....
IMHO, It depends on the the team's composition and appetite for risk.
If the team consists of several experienced and good designers, you need a less formal 'architecture' phase. It could be just a back of the napkin doodle or a a couple of hours on the whiteboard followed by furious coding to prove the idea. If the team is distributed and/or contains lots of less skilled designers, you'd need to put more time/effort (thinking and documenting) in the design phase before everyone goes off on their own path
The next item that I can think of is to be risk first. Continually assess what are the risks to your project, calculate your exposure/impact and have mitigation plans. Focus on risky and difficult to reverse decisions first. If the decision is easily reversible, spend less time on it.
Skilled designers are able to evolve the architecture in tiny steps... if you have them, you can tone down the rigor in an explicit design phase
TDD can necessitate some upfront design but definitely not big design upfront. because no matter how perfect you think your design is before you start writing code, most of the time it won't pass the reality check TDD forces on it and will blow up to pieces halfway through your TDD session (or your code will blow up if you absolutely want to bend it to your original plan).
The great force of TDD is precisely that it lets your design emerge and refine as you write tests and refactor. Therefore you should start small and simple, making the least assumptions possible about the details beforehand.
Practically, what you can do is sketch out a couple of UML diagrams with your pair (or the whole team if you really need a consensus on the big picture of what you're going to write) and use these diagrams as a starting point for your tests. But get rid of these models as soon as you've written your first few tests, because they would do more harm than good, misleading you to stick to a vision that is no longer true.
First of all, I don't claim to be a TDD guru, but here are some thoughts based on the information in your question.
My thoughts on #1 above: As you have mentioned, you need to have an architectural design up-front - I can't think of a methodology that can be successful without this. The architecture provides your team with the cohesion and vision. You may want to do just-enough-design up front, but that depends on how agile you want to be. The team of developers needs to know how they are going to put together the various components of the system before they start coding, otherwise it will just be one big hackfest.
It would be great if someone can provide an example and high level
steps to putting together a system in this manner
If you are putting together a system that is composed of services, then I would start by defining the service interfaces and any messages that they will exchange. This defines how the various components of your system will interact (this would be an example of your up-front design). Once you have this, you can allocate various development resources to build the services in parallel.
As for #2; one of the advantages of TDD is that it presents you with a "safety net" during refactoring. Since your code is covered with unit tests, when you come to change some code, you will know pretty soon if you have broken something, especially if you are running continuous integration (which most people do with a TDD approach). In this case you either need to adapt your unit tests to cover the new behavior OR fix your code so that your unit tests pass.
result in a system that can abstract out behavior in order to prevent
having to refactor large chunks of code
This is just down to your design, using e.g. a strategy pattern to allow you to abstract and replace behavior. TDD does not prescribe that your design has to suffer. It just asks that you only do what is required to satisfy some functional requirement. If the requirement is that the system must be able to adapt to new payment methods or pricing models, then that is then a point of your design. TDD, if done correctly, will make sure that you are satisfying your requirements and that your design is on the right lines.
I see the refactoring as a huge overhead in a production system where
data model changes increase risks for customers and the company.
One of the problems of software design is that it is a wicked problem which means that refactoring is pretty much inevitable. Yes, refactoring is risky in production systems, but you can mitigate that risk and TDD will help you. You also need to have a supple design and a system with low coupling. TDD will help reduce your coupling since you are designing your code to be testable. And one of the by-products of writing testable code is that you reduce your dependencies on other parts of the system; you tend to code to interfaces which allows you to replace an implementation with a mock or stub. A good example of this is replacing a call to a database with a mock/stub that returns some known data - you don't want to hit a database in your unit tests. I guess I can mention here that a good mocking framework is invaluable with a TDD approach (Rhino mocks and Moq are both open source).
I am sure there are some real TDD gurus out there who can give you some pearls of wisdom...Personally, I wouldn't consider starting a new project with out a TDD approach.
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 5 years ago.
Improve this question
Is Agile really different from TDD ? If so what are the main differences ?
Agile is anything that is inline with the values listed here - http://agilemanifesto.org/
XP (Extreme Programming) is a methodology that qualifies as agile. There are others too (Scrum, Crystal, etc..)
TDD (Test Driven Development) is a specific engineering practice from XP - which is a way to write code + drive design in incremental chunks. You write a test first, make it pass with the simplest possible change and then refactor to improve the structure/design. You do this in a loop till you're done.
http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/Test-driven_development
In short, TDD and Agile really focus on different aspects, and aren't mutually exclusive of one another.
TDD is very focused on how code gets written (and thus tends to be aimed at the work cycles of individual or small groups of developers exclusively).
Agile is really focused on the overall development process, not just how the code gets written and tested (and thus focuses a lot on project management and groups of developers, as opposed to specifically how a given developer writes code).
I'm going to play devil's advocate and say, Yes. TDD and Agile are the same thing, just at different scales.
Bear with me, here.
First off, TDD encourages you to have a plan of what you want to achieve, before you achieve it. You don't think about how you're going to achieve it. You just think about how to demonstrate that the thing you're about to write is valuable, and you work out how you know. This is very similar to the way in which projects are ideally sourced and requirements are gathered in Agile methodologies.
Then, you do the minimum necessary to get feedback on the work. With TDD this means a red or green bar. At a higher level, Agile methodologies encourage you to showcase and get feedback from stakeholders, or (preferably) release to production and see if it works and if anyone uses it.
Then you work out what the next bit of work to do is, and you write the next bit of the plan.
Agile methodologies may also use estimation and prioritisation, but these are mostly to do with assigning budgets and working out whether the work is worth doing in the first place - which devs do naturally at a small scale.
Agile methodologies are iterative - that is, the periods of planning, implementation, delivery and feedback are cyclical. So is TDD, with exactly the same steps.
Agile methodologies usually emphasise communication, conversation and lightweight documentation. TDD can be used as a form of documentation, too, especially if you make the test-names into meaningful sentences and use the same language that the business use together with realistic examples. This can also encourage communication and conversation.
Agile methodologies encourage reflection and learning from the past. TDD has this lovely red bar which can help you to do that very quickly.
If you scale TDD up, you get Acceptance Tests or BDD-style scenarios. Further up you start getting into Feature Injection and other forms of vision-driven analysis. Further up still you're looking at whether the released project retains your market share, or provides the options you wanted going forward, or achieves whatever its original vision was. The tests get bigger, but the process of writing just enough, getting feedback on it and learning continuously is still the same, no matter what the Agile methodology is.
All the rules which help Agile to be successful at a large scale can be applied to TDD at a small scale, and vice versa. (I'm trying hard to think of any exceptions to that and can't).
So, no. Agile isn't different to TDD. It's just TDD-done-bigger.
The differences are huge because I think there's a very simple distinction:
Agile is a philosophy whereas TDD is a specific methodology.
There are any number of ways you can work that are agile but by and large you are either doing TDD or you're not.
You can be Agile without using TDD (or a variant thereof) and you can use TDD without being agile (though I'd be somewhat surprised).
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 3 years ago.
Improve this question
Coming from an IT background, I've been involved with software projects but I'm not a programmer. One of my biggest challenges is that having a lot of experience in IT, people often turn to me to manage projects that include software development. The projects are usually outsourced and there isnt a budget for a full time architect or PM, which leaves me in a position to evaluate the work being performed.
Where I've managed to get through this in the past, I'm (with good reason) uneasy about accepting these responsibilities.
My question is, from a perspective of being technically experienced but not in programming, how can I evaluate whether coding is written well besides just determining if it works or not? Are there methodologies, tips, tricks of the trade, flags, signs, anything that would say - hey this is junk or hey this is pretty damn good?
Great question. Should get some good responses.
Code cleanliness (indented well, file organization, folder structure)
Well commented (not just inline comments, but variables that say what they are, functions that say what they do, etc.)
Small understandable functions/methods (no crazy 300 line methods that do all sorts of things with nested if logic all over the place)
Follows SOLID principles
Is the amount of unit test code similar in size and quality as the code base of the project
Is the interface code separate from the business logic code which in turn should be separate from the infrastructure access code (email, database, web services, file system, etc.)
What does a performance analysis tool think of the code (NDepend, NDoc, NCover, etc.)
There is a lot more to this...but this gets your started.
Code has 2 primary audiences:
The people who use it
The people who develop it
So you neeed 2 simple tests:
Run the code. Can you get it to do the job it is supposed to do?
Read the code. Can you understand the general intentions of the developer?
If you can answer yes to both of these, it is great code.
When reading the code, don't worry that you are not a programmer. If code is well written / documented, even a non-programmer should be able to see guess much of what it is intended to achieve.
BTW: Great question! I wish more non-programmers cared about code quality.
First, set ground rules (that all programmers sign up to) that say what's 'good' and what isn't. Automate tests for those that you can measure (e.g. functions less than a number of lines, McCabe complexity, idioms that your coders find confusing). Then accept that 'good coding' is something you know when you see rather than something you can actually pin down with a set of rules, and allow people to deviate from the standard provided they get agreement from someone with more experience. Similarly, such standards have to be living documents, adapted in the face of feedback.
Code reviews also work well, since not all such 'good style' rules can be automatically determined. Experienced programmers can say what they don't like about inexperienced programmers' code - and you have to get the original authors to change it so that they learn from their mistakes - and inexperienced programmers can say what they find hard to understand about other people's code - and, by being forced to read other people's code, they'll also learn new tricks. Again, this will give you feedback on your standard.
On some of your specific points, complexity and function size work well, as does code coverage during repeatable (unit) testing, but that last point comes with a caveat: unless you're working on something where high quality standards are a necessity (embedded code, as an example, or safety-critical code) 100% code coverage means you're testing the 10% of code paths that are worthwhile to test and the 90% that almost never get coded wrong in the first place. Worthwhile tests are the ones that find bugs and improve maintainability.
I think it's great you're trying to evaluate something that typically isn't evaluated. There have been some good answers above already. You've already shown yourself to be more mature in dealing with software by accepting that since you don't practice development personally, you can't assume that writing software is easy.
Do you know a developer whose work you trust? Perhaps have that person be a part of the evaluation process.
how can I evaluate whether coding is written well
There are various ways/metrics to define 'well'or 'good', for example:
Delivered on time
Delivered quickly
No bugs after delivery
Easy to install
Well documented
Runs quickly
Uses cheap hardware
Uses cheap software
Didn't cost much to write
Easy to administer
Easy to use
Easy to alter (i.e. add new features)
Easy to port to new hardware
...etc...
Of these, programmers tend to value "easy to alter": because, their job is to alter existing software.
Its a difficult one and could be where your non-functional requirements will help you
specify your performance requirements: transactions per second, response time, expected DB records over time,
require the delivery to include outcome from a performance analysis tool
specify the machine the application will be running on, you should not have to upgrade your hardware to run the app
For eyeballing the code and working out whether or not its well written its tougher, the answers from #Andrew & #Chris cover it pretty much... you want code that looks good, is easy to maintain and is performant.
Summary
Use Joel Test.
Why?
Thanks for tough question. I was about to write a long answer on merits of direct and indirect code evaluation, understanding your organisational context, perspective, figuring out a process and setting a criteria for code to be good enough, and then the difference between the code being perfect and just good enough which still might mean “very impressive”. I was about to refer to Steve McConnell’s Code Complete and even suggest delegating code audit to someone impartial you can trust, who is savvy enough business and programming-wise to get a grasp of the context, perspective, apply the criteria sensibly and report results neatly back to you. I was going to recommend looking at parts of UI that are normally out of end-user reach in the same way as one would be judging quality of cleaning by checking for dirt in hard-to-reach places.
Well, and then it struck me: what is the end goal? In most, but very few edge cowboy-coding scenarios, as a result of the audit you’re likely to discover that the code is better than junk, but certainly not damn good, maybe just slightly below the good enough mark. And then what is next? There are probably going to be a few choices:
Changing the supplier.
Insisting on the code being re-factored.
Leaving things as they are and from that point on demanding better code.
Unfortunately, none of the options is ideal or very good either. Having made an investment changing supplier is costly and quite risky: part of the software conceptual integrity will be lost, your company will have to, albeit indirectly, swallow the inevitable cost of the new supplier taking over the development and going through the learning curve (exactly opposite to that most suppliers are going to tell you to try and get their foot in the door). And there is going to be a big risk of missing the original deadlines.
The option of insisting on code re-factoring isn’t perfect either. There is going to be a question of cost and it’s very likely that for various contractual and historical reasons you won’t find yourself in a good negotiation position. In any case re-writing software is likely to affect deadlines and the organisation what couldn’t do the job right the first time is very unlikely to produce much better code on the second attempt. The latter is pertinent to the third option I would be dubious of any company producing a better code without some, often significant, organisational change. Leaving things as they are not good either: a piece of rotten code unless totally isolated is going to eventually poison the rest of the source.
This brings me to the actual conclusion, or in fact two:
Concentrate on picking the right software company in a first place, since going forward options are going to be somewhat constrained.
Make use of IT and management knowledge to pick a company that is focused on attracting and retaining good developers, that creates a working environment and culture fit for production of good quality code instead of relying on the post factum analysis.
It’s needless to expand on the importance of choosing the right company in the first place as opposed to summative evaluation of delivered project; hopefully the point is already made.
Well, how do we know the software company is right? Here I fully subscribe to the philosophy evangelised by Joel Spolsky: quality of software directly depends on quality of people involved which as it has been indicated by several studies can vary by an order of magnitude. And through the workings of free markets developers end up clustered in companies based on how much a particular company cares about attracting and retaining them.
As a general rule of life, best programmers end up working with the best, good with good, average with average and cowboy coders with other cowboy coders. However, there is a caveat. Most companies would have at least one or two very good developers they care about and try their hardest to retain. These devs are always put on a frontline: to fire fight, to lure a customer, to prove the organisation potential and competence. Working amongst more than average colleagues, overstretched between multiple projects, and being treated as royalty, sadly, these star programmers very often loose touch with the reality and become prima donnas who won’t “dirty” their hands with any actual programming work.
Unfortunately, programming talent doesn’t scale and it’s unlikely that the prima donna is going to work on your project past the initial phase designed to lure and lock in you as a customer. At the end the code is going to be produced by a less talented colleague and as a result you’ll get what you’ll get.
The solution is to look for a company there developer talents are more consistent and everyone is at least good enough to produce the right quality of code. And when it comes to choosing such an organisation that’s where Joel Test comes mighty handy. I believe it’s especially suitable for application by someone who has no programming experience but good understanding of IT and management.
The more points company scores on the Joel Test the more it’s likely to attract and retain good developers and most importantly provide them with the conditions to produce quality code. And since most great devs are actually in love with programming all the need is to be teamed up, given good and supportive work environment, a credible goal (or even better incredible) and they’ll start chucking out high quality code. It’s that simple.
Well, the only thing is that company that scores full twelve points on the Joel’s Test is likely to charge more than a sweatshop that scores a mere 3 or 5 (a self-estimated industry average). However, the benefits of having the synergy of efficient operations and bespoke trouble-free software that leverage strategic organisational goals will undoubtedly produce exceptional return on investment and overcome any hurdle rates by far outweighing any project costs. I mean, at the end of the day the company's work will likely be worth the money, every penny of it.
Also hope that someone will find this longish answer worthwhile.
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 3 years ago.
Improve this question
The question might seem trivial, but it's an actual problem: when you're working on a project, do you do any kind of architecture design before actually starting coding? Do you spend much time working together with a customer to get a detailed specs/usecases/mockups?
During coding, do you alter those architectural decisions made before? Do you go back to the customer with new set of specs/usecases/mockups?
I'm wondering, what's a good balance between all those non-coding actions and coding itself, from your experience?
Update:
Ok, so from the anwsers so far it seems like there are 2 approaches:
design early, then sit and code to avoid late fixes
minimize the design alone part, instead do iterative development (agile methodologies seem to prefer it that way).
I guess which way to go depends on the project, team and customer... am I right?
That which minimises the total time spent ;-)
It heavily depends on the kind of project, but generally speaking it's better to "waste" time over-designing and specifying requisites than finding out later that something was wrong and come the whole way back to fix it.
I read something about quantitative measurements of the impact of poor design decisions in "The Mythical Man-Month" or maybe in a book called something like "Software Requirements Pro Practices" from Microsoft Press, I think the time wasted in a late fix (near product delivery) was about 10x than in early stages.
If you do agile, design and coding are the same thing. In my experience it is good to pair program during the very first stage of the project...
Have a look at scrum, agile and waterfall. This is related to project management not programming per se.
Architecture also becomes easier once you have built enough applications within a domain or a platform. In PHP, if you use Joomla, Symfony or codeigniter then your scaffolding and architecture is already in place. Same for ASP.NET MVC.
My personal experience tells me that you should consider different factors. There's no silver bullet. My personal list follows, grown mostly by experience.
If you are developing something that is well known in details, the development team is sparse and with difficulty to communicate efficiently all together, the team has strong or huge dependencies towards the work of other teams, and what you are developing has a fundamental long term importance that will be difficult to change in the future (eg. file formats), go for a very long design phase, akin to a waterfall model. Also, you should spend a lot of design if you plan to develop a rather complex application, and you have to deeply consider all the possible interactions between features before coding. Coding takes very little time compared to design. Also, you should consider this if it somehow important to keep efficient record of how the application behaves from a very high level point of view, and if your team tends to be highly unstable, so that your knowledge stays on paper, rather than in people's brain.
if you have to implement something brand new and to do research on, you want feature as soon as possible, growing the application from fast feedback, you have a pool of geeks that work in the same room, are very committed to your cause, love programming and they are passionate to share and build together, go for agile methods.
if you are in between to the previous two cases, go for an iterative approach. I normally choose a 3 months schedule. When I code alone, I work agile-like, mostly because I have to cope with frequent disruption, so I add feature by feature. However, I release iterative, namely I don't plan to do an official, stable release before the third iteration. I want space to learn the field, do mistakes, and correct them before committing to maintain some stupid choice.
if you code in academia, you are screwed, because you have some of the issues in 1 without the manpower to accommodate them, and some of the issues in 2 without the easy communication required by agile methods.
roughly 50/50. whenever ive analysed my project schedules, it turns out about 50% of the time goes into design, project management, quality control, and auxiliry tasks. the remaining 50% is coding. if i dont see that 50/50 ratio, i worry.
mind you, this is using traditional waterfall model (which is more suited to custom-app development). agile methods are better for shrink-wrapped software in my opinion.
I would say it's roughly 50/50, no matter the "methodology" or project type. It only varies in how those 50% design are distributed. And that may depend on the project, but most of all it depends on the people who do the work, and how they are "wired". It's more a matter of psychology than methodology.
Some people (I'd say the more cautious characters) need a more detailed mental map before they start coding. If they don't have that map out of prior experience, they will need more "investigation" time up front.
Others yet like to just "jump in" into coding with only a rough mental map, and work out the details as they go.
Somewhere in between is to do the elaboration via spikes and prototypes, and develop the "big picture" on top of that running code. For me personally this tends to yield the best results, and the least waste. (After all, prototyping is, in a way, a test-first approach applied on solution ideas. You get an idea, test it out in a spike or prototype, then implement/integrate it with the main code base.)
My advice is: Find out the style that feels best to you personally, and stick to it. That's going to be pretty sure the style you are going to be most effective with.
Those two things are tightly coupled. Well at first stage, you are definitely will spend some time to make design decision. Then you will have to start coding and almost in all cases you will came up with some improvement decision for your previous design.
After all it will depend on delivery date and how much time you have at all and then to decide accordingly how you going to balance it. In general you make a startup design and then during coding you will update and change it. Also is a good practice to deeply involve your customer in design decision during development stage to force him be aware of it and how much of your time you will spend on each change.
The longer the period between when you write your specification and the time you start coding will increase the chance that requirements will change. So, to answer your question, as soon as possible....
If your suffering from too much requirement creep then I would suggest implementing smaller iterations of releases (if possible) and then creating new requirements/specifcation documents for each of these samller phases.
If you can't do this.... make sure you have a good change management process sin place.
My google-fu is failing drastically, but I recently read something to the effect of:
"Spend 6 months coding, 6 months designing and 6 months testing. The good news is, they're all the same 6 months."
It's important to design enough to have a map of what you are trying to code, and how it relates to the rest of the system. You can't just code most large projects - they're too big, and usually involve multiple components. I've done that when I was young, and you end up with a big ball of mud, or stay up all night for a week refactoring it.
What I tend to do now is design down to the package level, and assign roles to components. On large systems getting to the component selection stage can take several months, and involve some trail and prototyping coding.
Then the APIs and implementations of each package are evolved, based on what messages the functionality require, and how the clients of the packages evolve to cause the emergence of further requirements or constraints. I usually evolve an API by designing a pure interface (by writing the code for it) with unit tests for each known use case, then implement it. So there is some writing of code involved in designing - the best representation of the API is usually the code and inline documentation, and it's easiest to confirm that the client can perform the actions required to satisfy a use case ( and the code to do so is not excessively complex ) by writing code which exercises the API in that way, and that code trivially becomes a unit test for the implementation of the API when it arrives. But the code written during 'designing' isn't the code which supplies the implementation of the API. For APIs with low coupling ( so can be changed without breaking too many clients ), I'll switch between designing and implementing modes rapidly; for ones with higher coupling, I'll typically publish the API and use-case examples for peer review before committing too implementing them.
As aleemb said, this really is a project management question. I suggest you read up on several methodologies, find the useful and not-so-useful parts of each, and evaluate your own circumstances (team size/experience, customer engagement and commitment levels, what's done in your organization, schedule/budget, etc.) and come up with the best schedule you can. It really all just depends on your specific circumstances.
Think about how many people are going to be involved in writing the software.
If it's just a one-developer job, maybe take a smaller percentage for design. If you're going to have 30 people working on it, you probably want a lot bigger fraction for the design.
Getting teams of developers to write software is much like partitioning software up across multiple CPU's - you are going to get the best return for added CPU (read 'developer') when you can minimize the necessary communication between them. You sure don't want to get 10's of k-loc into your project before the developers start discussing architectural issues.
Now you could probably also make the case that, when you do a better job with the design phase, the coding will actually take less time and be less painful. Measure twice and cut once, and all that.
Also, you probably should think about the likelihood of the project being 'put on hold'; design artifacts have much better shelf life than immature code.
Depends on your chosen methodology.
Traditionally with Big Design Up Front or Waterfall you spend 90% of the time designing and 10 % of the time coding. You then spend another 90% of the time handling all the changes that the initial design missed. And another 90% of the time chasing bugs.
With modern Agile development you spend 10% of the time designing and 90% of the time coding. then another 90% handling all the changes that the customer representative forgot to mention and another 90% of the time chasing bugs.
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 6 years ago.
Improve this question
I see the benefit of TDD, and I'm trying to learn how to wrap my head around it. I'm also reading more about DDD and want to start applying both of them to my software projects.
I've purchased a few "hands on" programming books (by "hands on" I mean ones that discuss a real world application with real solutions as opposed to small snippets) and I've noticed that they typically start defining the "infrastructure" layer of the application in traditional code-first fashion, as opposed to using TDD; both books go out of their way to discuss how good TDD is and how the case study will make use of it.
For example in one of the books, ASP.NET 3.5 Social Networking, the entire second chapter develops a Logging wrapper class, an Email wrapper class, Cache and Session wrapper classes (and their associated interfaces) all without touching upon a single unit test. Another book, .NET Domain Driven Design with C#: Problem, Design, Solution does similar, and creates a base class and repository framework code-first before even touching on the "real" code.
I understand that you should test the actual logic and functionality of your domain classes. I had thought the "don't test plumbing" code only applied to code that you didn't write (e.g. built-in .NET classes), but what I'm reading seems to indicate/suggest that you should only test the code that actually has to do with your application and not the plumbing that you write to provide a foundation.
Is this an acceptable way of applying TDD?
When learning TDD, apply everything. Afterward, apply what you need.
If you are writing the plumbing from scratch then you should have tests around it. If you are just using a few interfaces and classes to abstract away your linq2sql calls then, no I wouldn't necessarily put unit tests around that.
To quote someone smarter than I:
I’m not religious about TDD. I
consider it a discipline worth
following. I don’t write all my tests
first. Some small number of them are
simply more convenient to write after
the code. There is even some code I
don’t write tests for at all, because
it’s just not worth it. But those are
exceptions to the rule. The vast
majority of the code I write, I write
test first.
-uncle bob martin via: http://www.infoq.com/news/2009/02/spolsky-vs-uncle-bob
It probably depends on other factors about how you plan to build your project.
If you're following other Agile practices, such as small iterations and deliveries, then you won't have much of an architecture or infrastructure at the start, because you won't have time to develop much while you're implementing and delivering the first few features. Anyway, why spend time on Big Design Up Front, when you don't really know what the code is going to need?
So you'll build your code test-first and over a number of iterations. Test coverage means you can refactor to improve your design, which (in theory) allows exactly the right the infrastructure to emerge for the application as it exists at any moment in time. Ron Jeffries explains it well here. Without the tests, you're probably going to hit a point where you need to stop and figure out what the structure should be, which is going to take time that could better be spent building useful features and that you're going to have to test at the end anyway.
If you're 100% certain you can map out the design correctly before you have written any code, then it's your choice to do so. Make sure to leave plenty of time in the project for testing, though. I think everyone should build at least one significant piece of work both by the "traditional" Waterfall process and by just diving in and coding in order to have some experience that puts the Agile practices into context. Otherwise you're at risk of knowing "what" without knowing "why", and that makes the lessons harder to learn.
If you test some code, and don't test other code, which code will have the bugs?
Hint: it's the untested code.
I am no expert here.
But if you are developing plumbing components, it should be tested.
If I understand correctly, with TDD, code written against interface & in absence of plumbing components, people use Mock objects.
I went into this at some length in another question. Basically, the point of using TDD and mocks and all that stuff is to develop more confidence.
TDD should be applied to any code that you develop. When using TDD you needn't test everything -- i.e., the goal isn't 100% coverage -- but coverage should be pretty high over code that you develop. For example, you don't need to test automatic gettor/settors in C# -- you can trust that the language will do it's job there. When in doubt, though, write the test first.
By all means write code-first to gain experience with a platform - just be brave and throw it away once you're sure you can tackle most tasks on that platform. I've just done that with a small Java program I've started.
Now that I've gained some experience I can see what I have to do to get very high line coverage now that I'm starting to write it test-first, even most of the plumbing.