Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
From the agile manifesto, agile values:
Individuals and interactions over processes and tools,
Working software over comprehensive documentation,
Customer collaboration over contract negotiation,
Responding to change over following a plan
Yet doesn't TDD create a plan and almost structure out a contract negotiation?
"What are the features you want?"
"1,2,3"
Developer writes tests for 1,2,3 -> Team delivers code
"Here's 1,2,3 give us our money"
It's also a form of comprehensive documentation and also a process. Once the tests are written individuals and interactions no longer matter as much because the "source of truth" is no longer with people but ironed out in the code.
Just wondering how they fit together, if they're opposed or do they work together?
TDD is more like a practice for individual contributors, instead of a process. Test here usually refers to unit test, which is part of development work, instead of comprehensive test suits such as performance, functional, and integration tests.
TDD in certain cases should help individual contributor really think about requirement and implementation (respond to change and come up with working software). I personally do not adopt this practice, but it is an agile practice that can be adopted by a single contributor. Do not confuse it with higher level tests and related documents.
Yet doesn't TDD create a plan
Nope. TDD does not mean "write tests up front" it means "write tests before writing code". The whole "Do as much as you need and no more" comes into play. You are not expected to write the tests for all your features before writing any code, just the feature you are currently on. And then (depending on the level of testing) just a small subset of the feature will need tests now.
It's also a form of comprehensive documentation and also a process
It also aids with working software.
Working software over comprehensive documentation,
Over, not instead of. If you can get both, great.
the tests are written individuals and interactions no longer matter as much because the "source of truth" is no longer with people but ironed out in the code.
The oracle for what it does is always the code. The oracle for what it should do is always people.
TDD done well also aids with the communication.
Any insight as to why some people seem to be getting mad at the question?
The question comes off as very troll-y. You are twisting the manifesto to make it sound like anything that aids the latter is "bad" and you are twisting the definition of TDD to be an all-encompassing, completely up-front process. Neither of which are true.
Individuals and interactions over processes and tools,
BDD is a great tool for aiding interactions at a dev/BA/stake holder level. TDD (xUnit and alikes) are great tools for aiding interactions at a dev level.
Working software over comprehensive documentation
TDD helps create working software.
Customer collaboration over contract negotiation
(BDD) Being able to describe in a common language the specification and have that execute is awesome.
Responding to change over following a plan
A well tested code base can change with ease. An untested or badly tested code base is fixed.
That is, while there is value in the items on
the right, we value the items on the left more.
I also agree with Tom’s answer, ‘if it is possible to do agile well, then I believe that is always a good thing. If it is not possible to do it well, then I believe that it can be harmful.’ Agile simply isn’t the right answer for every company. It is different to do well in a large company and it’s lack of focus on software architecture can really affect the usefulness of the resulting technology. Digital Animal have written an interesting article on Agile and why it doesn’t work for them. http://digitalanimal.com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/?AT=D8c953
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 4 years ago.
Improve this question
I am a Research Scientist, and definitely the way we code is not considered "production code" that's prototypical code, but then what makes a production code ?
Testing for scalability, ability to handle real time traffic and testing all edge cases ?
But what else, for instance I also hear Python is less of a "production language" that Java or C#, what is the criteria for them to be production-able.
Any books/references drawing this point home or to sublime it, would also be great!
Thanks in advance
Production code generally means its ready to ship out to a client.
Most obvious bugs are fixed
code is well-structured and self-documenting
Automated Tests are written and have a sufficient level of coverage
It's gone through a peer review process before being incorporated into the main code base.
It will pass the "build system" may automatically check rules like: coding conventions, complexity, linting, testing, compilation. Sometimes this may include deployment success to a testing environment.
How would this compare to non-production code?
Nearly all developers start with prototype/non-production code, even developers that use Test Driven Development (TDD). The goal of their code is to "just make this work" so they can develop a first pass approach to a problem. Often this will lead to poorly named variables, excessively long (number of commands) functions, improperly formatted and often little or no tests.
Once a developer has a satisfactory working solution, they go back and clean up the code. They fix spelling errors; use design patterns, if they see one that's helpful; they make their code fit the teams coding conventions and style guide, some of which lead to real heated debates on using tabs vs spaces.
The best way to think about it is:
The first pass at writing code is a software draft that is to get the developers ideas on the page until they have their "Story" or functionality set. The goal is for them to understand it.
The second pass, i.e., getting it ready for production is refining it so that other people can understand their code. In paper writing terms, you're giving it a more coherent structure and improve trying to convey your meaning to other people better.
That's not all.
While this will generally apply to writing code, part of saying something is "ready for production" is including all the steps not involved with the actual application code.
Often it's all the steps needed to get the code into the clients hands or live.
This could be creating a Continuous Integration and Continuous Deployment system. Setting up servers, deployment groups, monitoring systems and so on.
Without these things your application may not be considered production ready by your organization.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I've been working on a CodeIgniter project with a friend of mine for almost a year now. We feel that our development process isn't as effective as we wanted to be, and currently we're not employing any software development methodologies. We're 2 man team, looking to have more people to work with us in the future, but we don't have enough people to start on scrum.
Right now, we're both working on this project on the side, would be nice to know which methodologies are best for us, to get our development going faster and more efficient.
Agile and Scrum won't make you faster or more efficient:
Since you tagged this with agile and scrum, I thought I'd mention this: neither agile nor Scrum has as its goal faster or more efficient development as you ask for in your question. In fact, changing to these approaches involves a significant learning curve, but if practiced well contributes toward very low defect rates, software that meets the customer's needs, and a development process that responds to changing requirements. Used long enough, Scrum can provide good data about roughly how much work a specific team can get done in a period of time.
Still, you might benefit from some practices:
All that said, there are a couple practices that may want to try:
Pair Programming and Test Driven Design (TDD)
Continuous Integration
TDD is not easy to learn, especially on your own. See if you can attend a CodeRetreat or similar event.
If you aren't already using a modern software change management tool (SCM) like Mercurial, git, or subversion, get one and learn how to use it.
Get regular feedback from "customer"
If you don't already know (you didn't say in your post), you might ask yourself who you are making the software for. Can you frequently and regularly demo it to that person and get feedback? Find out what they want next and put those items at the top of the backlog.
Try to make your product incrementally useful
Rather than making big product-wide changes, add small useful amounts of functionality. Your design will drift but if you have sufficient automated tests in place you can refactor as needed.
I'm curious why you say you don't have enough to do some form of scrum?
You're both on the team, one of you can own the process and the other or both of you can be the product owner. You do your daily scrum so you can know what each of you are doing - picking the work from the backlog you agreed to do. And as you add members you'll already have an established practice they can integrate into.
You can work in 2-4 week sprints, do sprint planning,review, and retrospective regardless of the number of members.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
So it seems like a lot of people are playing the blame game around where I work, and it brings up an interesting question.
Knowns:
Requirements team writes requirements for product.
Developers create their own unit tests according to requirements.
Testing team creates Test Conditions, Test Design and Test Cases according to requirements.
Product released if and only if X% of test cases from Testing team passes.
After delivery customer does Acceptance tests --> Customer response team gets bugs from the field, and lets the testing team know about these issues.
Question:
If the customer ends up filing a lot of defects, who is to blame? Is it the Testing team for not covering those? Or is it the requirements team for not writing better requirements? And how does one improve upon the system?
The statement "Product released if and only if X% of testcases from Testing team passes" really bothers me. The team may want to consider having better release criteria which is gated on more than just test pass rates. For example, are the scenarios known, understood, accounted for (and tested)? Certainly not all bugs will be fixed, but are the ones that have been postponed or not fixed been triaged correctly? Have you reached your stress testing and performance goals? Have you threat modelled and accounted for mitigations to potential threats? Have x amount of customers (internal/external) deployed builds and provided feedback prior to release (i.e. "dogfood")? Do developers understand the bugs coming from the field and the testers to create regression unit tests? Does the requirements team understand these bugs coming in to see why the scenarios weren't accounted for? Are there key integration points between features which weren't accounted for in specs, development, or testing?
A few suggestions to the team would be to first do a postmortem on the issues found and understand where it broke, and strive to push quality upstream as much as possible. Make sure the requirements team, devs, and testers are communicating frequently and well throughout the planning, dev, and testing cycle to make sure everyone is on the same page and knows who is doing what. You would be amazed at how much product quality can be gained when people actually talk to each other during development!
Bugs can enter the system at both the requirements and development steps. The requirements team could make some mistakes or over-simplifying assumptions when creating the requirements, and the developers could misinterpret the requirements or make their own assumptions.
To improve things, the customer should sign off on the requirements before development proceeds, and should be involved, at least to some extent, in monitoring development to ensure things are on the right track.
The first question in my mind would be, "how do the defects stack up against the requirements?"
If the requirement reads, "OK button should be blue" and the defect is "OK button is green", I would blame development and test -- clearly, neither read the requirements. On the other hand, if the complaint is, "OK button is not yellow", clearly, there was an issue with requirements gathering or your change-control process.
There's no easy answer to this question. A system can have a large number of defects with responsibility spread between everyone involved in the process -- after all, a "defect" is just another way of saying "unmet customer expectation". Expectations, in themselves, are not always correct.
"Product released if and only if X% of test cases from Testing team passes" - is one the criteria for release. In this case "Coverage of Tests" in written TCs is very important. It needs good review of TCs whether any functionality or scenario is missed or not. If anything is missed in TCs there might possibility to find bugs as some of requirement is not covered in test cases.
It also needs some ad-hoc testing as well as Exploratory testing to find uncover bugs in TCs. And it also needs to define "Exit criteria" for testing.
If customer/client finds any bug/defect it is necessary to investigate as: i) What type of bug is found? ii) Is there any Test case written regarding that? iii) If there is test case(s) regarding that executed properly? iv) If it is absent in TCs why it was missed? and so on
After investigation decision can be taken who should be blamed. If it is very simple and open-eyed bug/defect, definitely testers should be blamed.
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 8 years ago.
Improve this question
I'm facing developing a new web app in the future and I'm wondering how to decide what framework to use. I've settled on Python as my language of choice. But there are still may frameworks to choose from! More generally how do you choose between different similar technologies that are still in the works as the latest round of web frameworks are? I'm curious what your process is for deciding on technologies you've never used.
Recognize that no choice is perfect -- or even very good.
No matter what you choose, someone will have a suggestion that -- they claim -- is better.
No matter what you choose, some part of your tech. stack will fail to live up to your expectations.
The most important thing is "shared nothing" so that the components can be replaced.
After that, the next most important thing is automatically-generated features to reduce or prevent programming.
Look at Django. Lots of automatic admin features make life very pleasant.
There are a number of things you can do:
Download the frameworks and build something similar with them for comparison.
Look for comparisons by other people, but attempt to understand the bias of the reviewer.
Observe the community at work, see what people are building and the issues they run into when using the technology. Forums, blogs, mailing list etc are good places to check out.
Go to conferences and meet like minded developers interested.
You can also take the approach of using stable versions rather than alpha bits. After a while you might move closer the bleeding edge. People associated with the project in question are generally more biased than those approaching from other platforms, be careful who you trust.
Consider the impact of using a bleeding edge framework versus an established one. Sometimes it's important to your customers that you are on one perceived as stable. At other times this doesn't matter. How comfortable are you with fixing the framework itself? Great developers will learn the internals, or at least know enough to keep things moving whilst a bug is sent to the framework mailing list etc.
Consider some general best practices in building abstractions and reusable code on the python platform. You may be able to save yourself some work in moving to another platform. However, don't be a reuse junkie as this can limit the effectiveness of your use of the framework. The 37Signals guys are right when they talk about extracting frameworks from working code rather than building frameworks from scratch.
I know this is an old posting, but I am in a similar situation (again) and I think there are other people who may want to look for different opinions, and hear of (somewhat) successful experiences.
Since baudtack mentioned Python, I will try to answer this along the lines of my experiences using Python. Here is what has been working for me:
determine the scope of your project - outlining what your application is supposed to be able to do without introducing any programming or design notes will clarify your goals greatly
determine how you would like to work with your code, stack and data:
a. what sort of programming paradigm do you want to work with? i.e. object-oriented, functional, etc. do you want to play to your programming style or do you want to follow somebody else's programming style?
b. use semantic web or not? do you want greater control over URIs and their design? (I found web.py great for this by the way - It is my choice to create REST APIs in Python)
c. do you want to be trapped by framework requirements, or do you want a better separation of the application from the web component, i.e. use a framework to utilize your application as a set of modules, for example. My problem with Django was that I ended up not programming Python, but having to learn more Django than I needed to. If that works for you, then that is the way to go.
d. data stores... some sort of SQL vs. non RDBMS (xml databases like eXist-db with full xquery support) vs. OODBMS vs. a combination of the above? how complicated do you need this to be? how much control/separation do you need to have over how data gets stored and recalled in your application?
e. testing: unit tests... thank goodness for python! if your web app has the potential to grow (as they often do), having a sane and coherent testing platform to begin with will help out a lot in the future - I wish I had learned about this earlier on. oh well... better late than never.
f. how much control over the server do you need? hosting considerations? how much control over an Apache instance do you need to have? OS specific needs? I found that using shared hosting providers like Webfaction has been great. I eventually found I needed greater needs for flexibility and bandwidth. In other words, what can you get for your budget? If you have USD50 to spend each month, it may be better to consider a virtual hosting solution like Linode....
Finally, I echo S.Lott's sentiments that no choice for a solution is perfect, and are subject to obsolescence.
Experience trumps hearsay. I've found that prototyping is a huge help. Make a prototype that uses the features you expect to be the most important for various frameworks. This helps route out any features that may not work "as advertised."
In general though, kudos for being willing to look at new technologies.
I have a set of criteria in different categories:
Activity & Documentation
Is there an active user base?
Is there an active development base?
Is the support responsive and information accessible?
Are there user and development guides and reference material?
These are essential, there needs to be traceability of all of these to build confidence in the solution.
Ease of use
Are basic features easy and complex features possible? I typically give a new framework a test drive and try to roll out a set of use cases to see how intuitive the framework is to use.
Is installation intuitive and simple for a local/dev installation and production deployment?
How is it backed up and upgraded?
What is the effort and UX for implementing a "Hello World" type blog post, static page, menu item, and plugin?
How are versions dealt with for the core & plugins?
Example (on the topic of Automated Testing/Continuous Integration solutions)
Several years ago I evaluated several Automated Testing solution. At the time Jenkins and TeamCity were front runners and in the end I chose TeamCity because of the UX, active user & development base and quality of accessible documentation.
Example (CMS for a blog)
This criteria is also why I prefer to use Wordpress over other options. While wordpress has its shortcomings, the user and development base is strong and active which leads to a software architecture with more potential to evolve over time and maintain its relevance and a development community that provides quality plugins and themes to choose from.
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
There are numerous Agile software development methods. Which ones have you used in practice to deliver a successful project, and how did the method contribute to that success?
I've been involved with quite a few organisations which claimed to work in an 'agile' way, and their processed usually seemed to be base on XP (extreme programming), but none of them ever followed anywhere near all the practices.
That said, I can probably comment on a few of the XP practices
Unit testing seems to prove very useful if it's done from the start of a project, but it seems very difficult to come into an existing code-base and start trying to add unit tests. If you get the opportunity to start from scratch, test driven development is a real help.
Continuous integration seems to be a really good thing (or rather, the lack of it is really bad). That said, the organisations I've seen have usually been so small as to make any other approach seem foolish.
User story cards are nice in that it's great to have a physical object to throw around for prioritisation, but they're not nearly detailed enough unless your developer really knows the domain, or you've got an onsite customer (which I've never actually seen).
Standup meetings tend to be really useful for new team members to get to know everyone, and what they work on. The old hands very quickly slack off, and just say things like 'I'm still working on X', which they've been doing for the past week - It takes a strong leader to force them to delve into details.
Refactoring is now a really misused term, but when you've got sufficient unit tests, it's really useful to conceptually separate the activity of 'changing the design of the existing code without changing the functionality' from 'adding new functionality'
Scrum because it shows where the slackers are. It also identifies much faster that the business unit usually doesn't have a clue what they really want delivered
Scrum.
The daily standup meeting is a great way to make sure things stay on track and progress is being made. I also think it's key to get the product/market folks involved in the process in a real, meaningful way. It'll create a more collaborative environment and removes a lot of the adversarial garbage that comes up when the product team and the dev teams are separate "silos".
Having regular retrospectives is a great way to help a team become more effective/agile.
More than adhering to a specific flavor of Agile this practice can help a team identify what is working well and adapt to a changing environment.
Just make sure the person running the retrospective knows what he/she is doing otherwise it can degenerate into a complaining session.
There are a number of exercises you can take a team through to help them reflect and extract value from the retrospective. I suggest listening to the interview with Linda Rising on Software Engineering Radio for a good introduction.
Do a Google search for "Heartbeat retrospectives" for more information.
I've been working with a team using XP and Scrum practices sprinkled with some lean. It's been very productive.
Daily Standup- helps us keep complete track of what and where everyone is working on.
Pair Programming- has improved our code base and helped remove "silly" bugs being introduced into the system.
iterative development- using 1 week iterations has helped up improve our velocity by setting more direct goals which has also helped us size requirements
TDD- has helped me change my way of programming, now I don't write any code that doesn't fix a broken test and I don't write any test that doesn't have a clearly defined requirement. We've also been using executable requirements which has really helped devs and BAs reach requirements understandings.
kanban boards- show in real time where we are. We have one for the Milestone as well as the current iteration. At a glance you can see what is left to do and what's being done and what's done and accepted. If you don't report in your daily standup something pertaining to what's on the board you have explaining to do.
co-located team- everyone is up to speed and on page with what everyone else is doing. communication is just-in-time, very productive, I don't miss my cube at all.