Related
Chapter about TDD from Martin's "Clean Code" caught my imagination.
However.
These days I am mostly expanding or fixing large existing apps.
TDD, on the other hand, seems to only be working only for writing from scratch.
Talking about these large existing apps:
1. they were not writted with TDD (of course).
2. I cannot rewrite them.
3. writing comprehensive TDD-style tests for them is out of question in the timeframe.
I have not seen any mention of TDD "bootstrap" into large monolite existing app.
The problem is that most classes of these apps, in principle, work only inside the app.
They are not separable. They are not generic. Just to fire them up, you need half of the whole app, at least. Everything is connected to everything.
So, where is the bootstrap ?
Or there is alternative technique with results of TDD
that'd work for expanding the existing apps that were not developed with TDD ?
The bootstrap is to isolate the area you're working on and add tests for behavior you want to preserve and behavior you want to add. The hard part of course is making it possible, as untested code tends to be tangled together in ways that make it difficult to isolate an area of code to make it testable.
Buy Working Effectively with Legacy Code, which gives plenty of guidance on how to do exactly what you're aiming for.
You might also want to look at the answers to this related question, Adding unit tests to legacy code.
Start small. Grab a section of code that can reasonably be extracted and made into a testable class, and do it. If the application is riddled with so many hard dependencies and terrifying spaghetti logic that you can't possibly refactor without fear of breaking something, start by making a bunch of integration tests, just so you can confirm proper behavior before/after you start messing around with it.
Your existing application sounds as if it suffers from tight coupling and a large amount of technical debt. In cases such as these you can spend a LOT of time trying to write comprehensive unit tests where time may be better spent doing major refactoring, specifically promoting loose coupling.
In other cases investing time and effort into unit testing with Mocking frameworks can be beneficial as it helps decouple the application for purposes of testing, making it possible to test single components. Dependency Injection techniques can be used in conjunction with mocking to help make this happen as well.
I just finished (mostly) a major application that I've been working on for a little over a year (off and on). It is around 86k lines of code, 50k of those is from Visual Studio's auto-generated dataset. It's largely a GUI to interacting with the database, generating reports, etc. It deals with money and manages contracts so it is important for it to be as bug free as possible.
I've walked through the code, and ran the program myself. I, for the most part, cannot find more bugs. I am however, sure there are, I've just been working on the system so long I can't see them anymore. I know there are some, because of some intermittent issues I run across, but can never pinpoint.
How should I go about software testing in order to discover the remaining bugs?
I know this is a little late, but have you heard of Test-Driven Development?
There are lots of tests you could build to discover the "remaining" bugs:
1) Unit tests
2) Integration tests
3) Behavior/Business/Acceptance tests
You could always attend a Developer Testing Bootcamp to get more ideas.
You can involve some of your end users and do a beta test that way. The less experience they have with the application until now, the more likely they are to try things you didn't think of.
Since you didn't use TDD to write it. Your best bet now is to add as many automated tests as possible to cover common scenarios. That way, when you do find bugs, and there are ALWAYS bugs in programs, you can hopefully minimize the risk to the rest of the system when you fix them.
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
Hey all. I would like to get some insight on a question that I have been trying to find some information about. If you are the solo developer that is building a project from ground up, how do you manage the project? In the past, I have worked on a few personal projects that have grown into fairly large projects. In almost all of those projects, I have tried to wear the hats of all the roles that would normally be in place during a normal software development project (i.e. Product Owner, developer, architect, tester, etc.). It seems that when I leave the project for some time and come back, it is extremely hard to get back into the rhythm of what I was doing. So with that, I have some questions:
If I know the requirements (at this
current time), do I record them
anyways? If so, how do I go about
doing this, and how do I manage these
requirements? Product backlog,
features list, etc?
If this is the case, are full blown product backlogs or use cases a little overkill?
How does one efficiently appropriate
his/her time to each respective role?
What would be a normal flow of events
that one would follow? Start coding
immediately, write down user
stories/use cases, then go into
OOA/D?
What diagramming/modeling would be sufficient for this level? Domain model, class diagram, etc?
Basically, I was curious how everyone out there in the SO community would go about developing a project from inception to deployment when you are the lone, solo developer. What steps, documentation, and other project related activities are needed to help bring this project from an impractical, hobby project to something more professional? Any help, references, or suggestions would be greatly appreciated. Thanks in advance.
The most difficult part, I have found, about developing solo is that it's just tough to keep yourself driving forward. Even if you're doing this to make a living (AKA, running your own software business), unless you have pressing needs (AKA, you're going to starve if you don't make money) it can be difficult to sit down and just code.
From your perspective, I would recommend following good software practices where it makes sense to. For example, if I were a solo software developer, I would have no reason to create a collaborative development environment. All I really need is an SVN server, my IDE, and a place to record documentation (might setup a wiki or a website or something). I would personally create a realistic schedule to follow and would work on sticking to that.
As for level of effort of documentation, that really depends on you and the product you are developing. For example, I would definitely recommend recording your requirements. Unless your product is trivial, there is no way you'll remember them all and why you wanted certain ones over others. Managing a full backlog, however, can be a job in and of itself. In the solo programmer case this may not make sense.
Basically, the point I'm trying to get across (and should be followed with every project - not just in this case) is have just enough management that makes sense. The rest should be focused on the work and the development of the product.
Something else you may want to look into is reading this - Agile Programming Works for the Solo Developer. There are other, similar, articles out there. Might give you some good thoughts.
If I know the requirements (at this
current time), do I record them
anyways? If so, how do I go about
doing this, and how do I manage these
requirements? Product backlog,
features list, etc?
I have two lists of features:
A high-level view which states the scope of the finished product
A list of the features which I'm implementing in this iteration
Because I don't need to communicate it to other people (yet) I tend to write down the things that I don't know about the project (if I already know it there's no need to write it down): it's when it gets too complicated, or when there are details which I haven't defined but need to define, that I start to define them in writing.
I did however try to investigate/make a business-case for the project before starting coding.
How does one efficiently appropriate
his/her time to each respective role?
I did non-programmer, product-owner thinking at times when I had to be away from the computer anyway.
Apart from that, my cycle is:
Implement more functionality
Integration-test it
[repeat as above]
Every 3 to 6 months I compare the new-functionality-accomplished against my estimated schedule, and then recalibrate: i.e., make a new list of the highest-priority features to implement in the next few months.
What would be a normal flow of events
that one would follow? Start coding
immediately, write down user
stories/use cases, then go into OOA/D?
I started with working part-time or in my spare time, to make sure that I had:
Understood the required functionality
Made significant architectural decisions
Written any throw-away prototypes as necessary to learn new technology
After that I was ready to start developing full-time.
What diagramming/modeling would be sufficient for this level? Domain model, class diagram, etc?
I'm not using diagrams at all (except for sketches of the UI). By structuring the code, and refactoring, I'm able to know/remember/rediscover/decide which software components implement what functionality.
It seems that when I leave the project
for some time and come back, it is
extremely hard to get back into the
rhythm of what I was doing.
You need to comment your code more. If you leave the code, come back in two weeks, and can't remember how the code works, you need more comments.
If I know the requirements (at this
current time), do I record them
anyways?
Yes, for the same reasons stated above.
how do I manage these requirements?
A feature list is OK, provided you have enough detail in each feature to jog your memory.
How does one efficiently appropriate
his/her time to each respective role?
Break down each feature into smaller and smaller tasks, until you feel like you can do each task in a half day or less.
What would be a normal flow of events
that one would follow?
That depends on your development style. In general I would follow a clear but simple architecture, avail yourself of software patterns where practical, and provide adequate unit tests for your code as you go.
What diagramming/modeling would be
sufficient for this level?
Sufficient diagramming/modeling to make the project clear in your head.
What steps, documentation, and other
project related activities are needed
to help bring this project from an
impractical, hobby project to
something more professional?
Other than what I have already mentioned, make sure you have a good source control system and daily backups in place.
Good luck!
If you believe there is a chance that you're going to work on the project for some amount of time, leave it, and then come back to it at a later date...your best bet is to treat the documentation for the project the same as if you were working with a large team.
That means documenting requirements (even if they're from yourself), writing use cases (if functionality is going to be complex, otherwise some other form of documentation could suffice), and some level of UML diagraming (or other domain specific diagram) which could include activity diagrams/class diagrams/etc.
That way, when you leave the project for some amount of time, you can come back to a well documented idea and pick up where you left off.
As a side note, I try to do the majority of those things no matter what...that way if I ever find somebody interested in working on the project with me, I can get them up to speed quickly and get them on board with my ideas.
This is how I work, YMMV:
Keep a spreadsheet for high level of everything - list of your projects, and some top-level items/todos/reminders
Create a "project" folder for each product/project you have or work on, and create a strucuture to contain documentation and code for the project.
Keep a top-level "catch-all" document for each project, in the root of this folder. Keep you ideas, research, notes etc in this doc.
Then if you want to get organized, keep an MS project file (or similar) and plot out timelines for the various steps in each project. This is good for tracking progress on each project and make sure you arent forgetting anything. Basically keeps you honest with yourself.
And if you need to track progress on project work you are doing for clients, I understand Basecamp is a good solution for this. I am currently evaluating it for my own company. See www.basecamphq.com
Even as a solo developer, you should document at least the overall features of your project, and then the requirements for the particular feature you are working to complete, and then maybe produce a short pseudo-code for the functionality you're currently working on.
That way, if you do end up breaking away from that project, you can get back to it and see where you're up to easily enough. It's also pointless getting too far ahead of yourself with details for this same reason.
It's also a neat motivational tool for a solo developer - getting through and ticking things off is a way to show progress - something that you can start to feel you're not making when you're chewing through a couple of thousand lines of code and it seems like you're still miles away from actually having 'module x' completed.
Lastly - with regards to code comments - I at least try and fill out what actions/behaviour a new function should have in an outline, and then write the code in between the comments. Also, it is useful having plain English explanations of why you're branching in an if/else to support the logic in the condition...
I belive that better results in solo development one can achive with appropriate tools support and tasks that compensate lack of ohers people and help to organize working time. Any tool that generate metada with minimal create time cost describing your software is helpful.
VCS and tools for tracking user actity/code changes history - very important is to add good commit messages
mind-mapping tools for storing project related data (e.g. XMind), blacboard is useful too :)
time tracking tools (e.g. Toggl.com)
write a lot of acceptance test and use acceptance testing frameworks
Of course these clues also fits in non solo development :)
As a lone developer, I've found that your time is very expensive. This means that you have to balance sustainability and momentum - even though you are just one guy, you have to do things so that the you six months from now can go back and look at old stuff without wasting time, without spending so much time maintaining the systems that it compromises your flow.
Your question suggests that you are thinking in terms of fairly heavyweight tools and processes, but the 80/20 rule applies - for example, you can nail documentation well enough by TDD, using the doc tools of your platform to generate API docs, plus a Wiki for specs, lists, etc.
In that vein, I would suggest that you choose your platform carefully. The question about modelling suggests that you are using a platform that produce a lot of code and artifacts, but you may be able to get most of the functionality for much less management overhead elsewhere. Today I'm working on a .NET Web app that I wrote "the right way", but now realize that I could have delivered the same functionality much more efficiently in this case by using PHP with a PHP MVC framework to keep a clean structure.
Specific tools that I'd recommend:
A distributed version control system (much less overhead than centralized)
The most lightweight platform that you can use that has good tooling
A Wiki to easily capture and maintain small and large bits of content
Whatever testing framework that you can use, right from the start of the project
A lightweight TODO list system that you can access from anywhere
I used to work on a very small team (one dba and one C# developer). Even then I found it very useful to have written requirements, formal tests, source control and bug tracking (we used bug tracking for our features as well as bugs). It helped us to not forget anything and a year later when you were doing maintenance, you had something to research though to help you undersatnd what you did. Plus when the two of us left (as most people eventually move on) there was documentation there for the next person.
I would really love to push for TDD development inside the shop I'm working in. Lots of the seniors over there didn't work with unit testing or did unit testing that was hitting the database.
I would love to bring some good arguments, books for training, possible coach to ease the transition.
I have found that it is often very hard to push TDD from the developer up. What I tend to do is talk about the benefits of TDD as much as possible and wherever possible, introduce elements of TDD myself bit by bit.
If they don't mind, start a new project with unit tests in it (managers seldom mind more test coverage) and start developing that way yourself. Slowly show the rest of your team the benefits and try to win some converts. Once you have a few other developers on your side, start pushing management for some training.
You could also offer to run some lunch-n-learns about it for the other developers. Teaching is the best way of learning and your will hopefully gain allies. If you are lucky, you can talk your boss into buying the pizza for the lunch-n-learn and everyone benefits.
Like Rob P said - I also found that preaching ended me with a hoarse voice and no one listening. I got results faster and more widespread by doing it and keeping that part visible. Be open to questioning and don't force it. Encourage and praise but don't preach.
Combine it with publishing the results of your testing- and have that automated - you can send out an email perhaps. You want many subtle reminders to show people how good your method is.
I think a good way to sneak in TDD principals into an existing product is to start writing unit tests for bugs. This way you slowly start to build up a set of unit tests for regression testing which become an integral part of the project, especially if you can get them run as part of your build process.
The only hurdle will be the existing code might be resistant to testing, but that's just another excuse to do some refactoring.
Once people start to realise the benefits the momentum will grow, but you need to pioneer the way.
While I can't tell you what will work, I can tell you some things that definitely will not work and should be avoided:
I'll write the code, you write the test
This always comes up at first. People assume that since you're so gung-ho about testing, you should be the one writing the tests. This doesn't work at all and misses the whole point.
You wrote the test that's breaking, so you have to fix it.
If you start writing tests for your code, inevitably someone else will break those tests. Then, if you ask them to fix it, they'll often say it's your responsibility. This isn't necessarily them being a jerk, it could just be that they don't understand the process. This is where you'll need management backup.
I'll just start, and everyone will follow.
Like others have said, TDD without management support is very hard. If there are any devs who don't "drink the Cool-Aid" then they will constantly be breaking your tests and not caring. If you can't make them believe, then you need management telling them it's their job.
What finally brought me around was watching a project collapse due to too many bugs. It convinced me that I was doing something fundamentally wrong. A little research brought me to automated testing, and with a little determination I taught myself the basics. Perhaps talking to your fellow devs about similar projects (we all have at least one...) will help them realize that they might want to try something new.
Lead by example:
use TDD on all the code you write
show them the benefits as soon as you have the opportunity (regression detected by the unit test or incident recreated in your unit testing environment)
deliver "clean code that works"
propose your assistance to others
don't be dogmatic - TDD is not silver bullet
make your unit tests visible: they should compile along with the code they test
If the project doesn't have enough unit tests, you can point out bugs in the issue database that would probably have been avoided if there had been unit tests.
As for pushing TDD, or some other code religion, don't bother.
For some people (and some types of code), TDD is great. Some people don't work that way, and don't benefit from test-first. As long as they don't avoid testing altogether, I don't think it matters.
A great challenge with TDD that is brought in "bottom up" is that, when push comes to shove (as it inevitably does when a deadline approaches), management is going to over-ride the emphasis on tests: "We can't afford to test! We have to finish the project!"
Of course, this is the very situation (deadline looming, significant backlog, progress not on track with promises, leading to rapidly shifting priorities and tasks) where the benefits of TDD really kick in. Management over-rides it, the project / iteration starts to come apart in the same-old same-old, and management looks back and says "We tried TDD and it didn't help at all."
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
My company has recently started using Scrum; we've done 2 sprints. We're still learning, but we've definitely exposed and fixed some problems in our development process already. So in general I think it has been good for us.
In reading many of the internet musings about Scrum from evangelists, cynics and everyone in between, three common and somewhat contradictory themes have stood out to me:
Scrum implementation fails because the processes of Scrum are not followed closely enough.
Scrum implementation fails because the organization does not adapt Scrum to its own environment/culture/practices.
The processes of Scrum are not important; only the values in the Agile Manifesto matter.
Examples of these can be seen in the responses to these SO questions:
Have you had a bad experience with Scrum or Sprinting?
Is Scrum evil?
Is Agile Development Dead?
I have to admit that we're not yet following all the guidelines of Scrum: we haven't done a release at the end of the sprints, our Scrum Master doesn't want us to move tasks out of the sprint backlog near the end of the sprint so that he can see how much our planning was off (which means the burndown chart never goes to 0), and urgent customer support issues still have incredible power to disrupt everyone's planning, for a few examples.
My question is: in trying to solve these and other issues, is it better to try and be closer to the official Scrum processes, better to be closer to some of our pre-Scrum processes, or better to meditate on the principles of Scrum to try and come up with a different process altogether?
I would say that you are really missing one of the key components of agility if you don't release early and often. To the degree that you don't do this, your process is not agile and bound to suffer the same sorts of problems that traditional, plan-driven processes have. It may be that this is a temporary condition as you are just getting used to things, but you need to start releasing soon (and regularly).
You'll always have the problem with show-stoppers, but you may be able to help this by shortening your sprint length. The customer may not be able to wait a month, but they may be able to wait 2 weeks for some things. A shorter sprint length, then, may help you to defer some requests to the next sprint making them less disruptive. You also need to be upfront with the customer that the disruptions are actually causing your pace to suffer. They may voluntarily choose to wait if they know that their chosen features are being delayed by some requests.
Another observation that I would make is that, as with almost anything, it's better to start out by following the pattern as closely as you can while you are learning. Once you have a good grasp of the fundamental principles, you can then see where some principles can be bent, broken, or replaced much more clearly to improve the process. Until you really get it, the things you change may hurt or help -- you really have no idea since you don't have the experience that tells you how things ought to be working. Unless your Scrum master is really experienced, you may want to hew closer to the defined practices until you've got a few more sprints under your belt.
Almost everything I've read on Scrum says that one of the keys is to adapt the process to fit your own situation. No two development teams are the same, and different things work for different people.
The main ideas behind Scrum are:
Have a tight feedback loop from requirements to development and back to the stakeholder(s).
This allows the development team to continually verify that they are building something that's actually wanted and allows the development to be easily adjusted as requirements and expectations change. Stakeholders can add or remove features at any point and they can adjust the priority of the features as their needs change.
Keep the software in a state where it's releasable at the end of any given sprint.
That's not to say you have releases every sprint, but that you could if the customer decides they want to have the latest stuff. This also helps a development team avoid the situation of integration hell that comes from people going off and working on a piece of the project on for months at a time in isolation.
Be completely transparent with what's going on in development and everyone needs to be willing to make tradeoffs.
This is where most projects fail and where Scrum can really succeed if everyone buys into the process. So many development projects are set up to where a release has to have X features released on Y date and no flexibility in changing that. This results in half-done features and bug ridden software as the developers cram to get in all the required features on their checklist.
The reality is, unexpected things happen in software development. With open communication and willing participants in the Scrum process, customers and developers can continually evaluate the current state of the project and make educated decisions on prioritizing the work remaining on the project.
Scrum does work. Not with all teams in all situations, but it has been shown to work.
I would suggest trying to embrace textbook Scrum as much as your business environment allows, see how that works out, and then tune it.
Why does your Scrum master not want to move tasks out of the sprint backlog? Does he not 100% embrace the principles of Scrum? (I would see that as worrying in a Scrum master)
Most problems implementing Scrum are actually just problems in the team or business being exposed by the Scrum process e.g. - if your sprints are thrown out by unforeseen support issues this suggests you are not allocating enough resource to support
Every company is different, every project is different and every client is different.
I think it's just as easy to fail by following scrum (or any other methodology) too closely in an environment that doesn't fit the methodology as it is to fail because you follow scrum too loosely in a project that does fit.
At the end some generic answer in a QA site is no replacement to serious analysis of your own project, company, team and clients - there is no magic formula and you have to make your own decision.
Answer: You need to adopt both Scrum and XP together to get the full benefits of scrum.
Reasons:
The reasons are based on years of doing XP and scrum, and specifically on what I learned from Jeff Sutherland's talk (for the ACCU in London, May 2009)
Scrum is a management technique - not necessarily a software production method. Some people use scrum in other domains e.g. preparing museum exhibitions and running religious institutions... so it has the mechanisms you need to make a multidisciplinary team deliver work adaptably in small increments.
Scrum, originally included all the extreme programming practices. Jeff Sutherland actually said that he's never seen a scrum project achieve the higher orders of productivity measured for scrum without using the extreme programming practices.
Scrum and XP both come from the same background - Object-oriented programming, specifically with Smalltalk. The programmers went off and developed XP whilst the management people created scrum. You need both aspects - development practices and management practices.
The XP practices were deliberately removed from Scrum to make it easier to adopt. - Implementing the XP practices is hard and it's difficult to get them adopted quickly. Jeff actually said that Ken Schwaber removed the XP practices to help people get started with scrum. The danger now is that this minimal scrum has become all that people see and expect.
Lots of non-technical project managers now teach scrum - but they don't have the skillset to teach XP
Not all developers find the XP practices easy to adopt - they can be hard sell and it takes a few months rather than the 2 days it takes to establish basic scrum.
Scrum doesn't attempt to address the technical issues in software development. It's just a small management process.
The strength of scrum is that it doesn't get in the way by prescribing lots of unnecessary or irrelevant technical work.
The weakness of scrum is that it doesn't tell you what good technical practices to do.
Extreme Programming does address the technical issues involved in software development and it fits very well within scrum. The reason the scrum people didn't force everyone to do the XP technical practices is that it takes about 6 months to implement those tech practices, rather than the 2 days it takes to implement the most basic scrum.
Whether or not scrum is "evil" - there are certainly drawbacks with it. We discussed the uneasy relationship between XP and Scrum at length at XP Days, London, 2009: http://xpday-london.editme.com/WhereHasXpGone
Scrum is not really the problem that you are showing. Most development methodologies work, even waterfall, as much as we like to bash it, works. Scrum does make you concentrate a little more on the important things, but it won't stop people from making bad decisions like not really following the process.
The system is pretty simple at its core.
See the problem.
Define what done is.
Create a series of tasks that will get you to done.
Estimate those tasks.
Select enough of those so that you can get something done in a short period of time.
Complete the tasks.
Rinse and repeat.
OK admittedly these steps are simplified, and I haven't thrown in a scrum master and a customer. But the point is that the framework is just a basic time management strategy. If the people in your system are chaotic and not good at getting things done then scrum really won't help them.
It's better to start applying Scrum by the book, and to really understand the underlying principles and values from the Agile manifesto, prior to customize it, so that the process does not get denatured. Be sure to run retrospectives at the end of each and every iteration (Sprint) to "inspect and adapt" your process and eliminate waste.
For your Scrum Master, he can track what is removed from the current Sprint. Also Sprints are planned based on the previous Sprints achievement, not on what was previously scheduled. I do no get its point.