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
I work in an Extreme Programming team, pair programming every day. Recently more and more often I get to do stuff that gives slow feedback, on order of 3 minutes. For example: change some thing, recompile, run and see wheather the performance is improved. I see it coroding the quality of pair programming, and I think it affects pairs more that solo programmers. If I am alone I can do sth else, but what if I am pair programming? How would you deal with it?
If you could do something else alone, why not when pairing? Maybe simpler action items could be taken off an issue list while waiting? A 3 minute wait would be too long for me to keep the brain in the "flow-mode". So being disrupted anyway (and your partner as well), can't you just do something else with your partner?
However, in your situation, I'd not work in any environment where I have 3 minutes pauses after a change. So the question is: can't you develop and debug that code in a smaller environment, broil it to perfection and then reintegrate those pieces into the main stream ?
your mileage may vary, but i consider pair programming on anything less than a major feature to be a waste of at least one programmer's time
Pair programming should be applied only to the research/POC/innovative parts of the development. Simple tasks should be delegated to the single programmers.
It is not only the problem of the waste of time when you have to wait for your partner to complete the tivial but time-consuming task. There is also a human factor - you get bored while waiting. Remember that productive developer need to be constantly motivated - waiting for your partner to complete lowers your morale.
You should probably consider refactoring the process. Three minutes to get feedback is too much both for pairing but also for coding solo. It is killing your productivity to have to switch gears constantly. You probably just feel it more when pairing.
Performance work, where of necessity you must run for a few minutes to gather statistics, is something that isn't a great fit for XP. There's a strong case to be made for starting off as a pair to sketch out some ideas, then going solo to avoid wasting two people's time for every three-minute performance runs, then joining up again to review the work prior to checking in.
Time for a spike Performance has to be built in, not added on. The team should have a set of automated test that can run frequently (daily) in a production like environment. Also, the team should be running a profiler continuously. If you don't have either, time to stop the line and get it done now!!!
If the team finds itself in a situation where performance is an issue, it needs to identify the technical debt and create a set of story cards to address the debt. It would include a set of automate performance test, A set of profiler tests. Daily analysis of the results of the test is a must. An architectural or design spike can then be called should a performance issue present itself.
If an team has not been doing performance testing continually from the start, you could have a significant technical debt to address. Once you have the application performing, you need to keep running your automated testing daily so you can become aware if and when a problem arises. You are then better to identify the offending changes to the applications.
By running automated performance test, you can allow the test to run for some period, generally for a period of hours. The results can later be analyzed and it frees the developers to do work on other story cards without waiting for the result of numerous individual performance tests.
Waiting is a blocker. Eliminate waiting via automated tests.
It doesn't matter if you are pair programming or not. 3 minutes is way too long for getting feedback on code change even if you are coding alone. I would profile and break down the project so that I can focus on a smaller pieces. In that sense, XP is actually helping(forcing) you to improve the design before it's too late.
I would split up for those tasks. Both of you work on the code separately, and recombine every so often (30 minutes or so?) when you've made improvements.
Related
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
I am working as Scrum Master on a large software project. We are currently running Scrum.
We have about one month left in the development phase before we are supposed to end our implementation phase.
I am strongly considering switching to Kanban (Or GTD) for the last couple of weeks due to:
We have an absolute deadline
It is very hard to plan two (or one) week ahead now that we are this close to the end. The agenda, priority and outstanding tasks changes almost each day. We daily find new tasks we must remember to do before we can say our development phase is finished.
Kanban let me easier identfiy which tasks are waiting for reponse, which tasks are waiting for verification etc.
Anybody have experiences with this? Is this a good idea?
Our sprints are not entirely pontensial shippable increments (I know they should have been, but thats not what I want to discuss here)
Even though I can be considered a Kanban proponent I would think twice before making such move.
On one side:
Kanban deals very neatly with rapidly changing task priorities. It is a good answer for environments where classic time-boxed approach, here: Scrum, doesn't work very well.
Introducing simple Kanban system doesn't require much effort.
Kanban itself isn't an approach to software development and/or project management and should be put on the top of something. However, it seems that you already have this "something" as, at the moment, you have your project organized.
On the other hand:
Adding new tool to your toolbox always adds some hassle and, since you are at the end of the project, it may not be such a good idea to add the hassle now.
Kanban, as pretty much any other tool, will give you value if and only if you get team buy-in before introducing it. I mean Kanban board is useless unless it is updated by everyone in the team regularly.
If you are fluent with what you do, namely following Scrum, resigning from a part of it, namely time-boxing, may have a negative impact on team's productivity. At the same time it'll take some time before you get familiar with a new method, so there can be a question when you're going to get value of switching to other method.
All in all, I would definitely consider Kanban to such work as it gives you pretty good visibility and high flexibility in a situation where priorities are changing all the time. However, I wouldn't say that, in your case, it is a sure-shot decision. If you planned for it in a bit longer perspective it would be a no-brainer to try Kanban.
Personally, I'd probably try anyway and treat it as an experiment. If it works you keep doing it. If it doesn't you retreat back to what you are good at and eventually try Kanban in another project with a bit more preparation.
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
I have just started to write code in C, C++, Java, ASP.NET, C#, Objective-C, I-Phone, etc.
But I don't understand why i have to spend 20% of my time for fixing bugs.
I just learned those programming languages as they are. Do most programmers face this type of problem?
You don't necessarily have to spend 20% of your time fixing bugs litteraly, but - yes - most programmers have to face the problem of bug fixing. Hopefully you'll be able to spend less than 20% on your time bug fixing, if you're not careful it might even take more of your time.
No matter how good a programmer you are it is highly likely that you'll introduce a few bugs at some time. If you're diciplined with unit testing you can hopefully avoid bugs best possible. I highly recommend you to look into Test Driven Development (TDD) if you want to do your best for avoiding bugs.
There are several questions about unit testing and TDD on StackOverflow if you need help getting started. Here are a few of them:
Is unit testing worth the effort
TDD vs Unit Testing
How to start unit testing or TDD
Should I use TDD?
Getting started with TDD
Getting started with TDD, interfaces and Mockups
No, most programmers have it worse than 20%.
If you want to get ahead of the game, you'll start writing tests to go along with your code. Google for:
test first programming
test driven design
behavior driven design
Bugs will always crop up and should always be tackled as soon as possible, that way the code is fresh in your mind.
For example you are able to write, but in your post there are some "bugs": no space after comma, space before comma, no space after dot, "Programmers" is not a name of someone, so it's better "programmers". Now you can use 20% of your time to fix them.
It's kind of an odd question. If I may take the liberty to rephrase it...
Why am I spending so much time fixing my own mistakes?
Focus your energy on not making them in the first place. There are many things you can do to minimize mistakes:
Be clear ahead of time what the inputs, outputs, and side effects of your methods are.
Break down your problem into small, easy-to-write functions and methods.
Write lots of tests.
Write testable methods.
Proofread your code before you hit that compile/run button.
Have someone else proofread.
As you gain experience, you'll find that the easy mistakes become less frequent and the hard ones (usually resulting from poor design or unknown behaviors in libraries) start consuming more of your time.
Fixing bugs is a part of programming, whether you like it or not, it'll always be there.
It's been there for as long as programming has been around and it'll be there until we program no more.
It's so common you can find it in many of the the common programming jokes.
And like Wayne, most people spend a lot more than 20% of their time on debugging.
Personally, I think debugging is what makes programming fun, not because it's fun per se, but because it takes you so long to fix and once you've fixed it you get this overwhelming feeling so "WOOHOO! I did it!"
Again, I agree with Wayne on trying those techniques for programming, however, they take all the fun away from programming.
One thing I found useful when debugging is to take a break and then come back to your code after a few minutes, preferably after a short conversation with a friend or a phone call, you'll be amazed at how fast you can spot bugs, the hardest part is getting the will to stop programming and taking a break.
No, you DON'T have to spend 20% of your time fixing your own bugs.
Nobody mentioned anything about PSP/TSP, but reducing bug-fixing time is what PSP (Personal Software Process) is all about. Usually it enables one to reduce bug-fixing time to less than 10% right from the start, by formalizing your design documents & reviewing them according to a checklist; standardizing your code, reviewing it according to a code review checklist too; and then proceeding to compile and test.
Eventually you reduce your bug fixing time to near zero percent, as you become better at reviewing your designs and code. The basic idea is that it takes alot less time to fix a bug in the design document, or by reviewing the code; than the time it takes to find and fix a bug in unit tests, and more so than integration tests.
If you use good design reviews, code reviews and unit-testing, your bug-fixing time should be below 10% almost every time, I'm, on average, below 7% (according to my statistical data).
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
Recently, we've come across an issue at work where if one person is working on some code by themselves, it seems to come out with the other team members looking at it and going "Huh? That's ugly, unmanageable, I need to rewrite that"
In fact, recently, I myself have had to re-factor something that was written the week before so that I'd be able to add in my (related) feature.
I know that Pair programming is the way to go for this, but we have an uneven team (3 members). As our team is being pushed pretty hard at the moment, we really don't have time for Peer Reviews (though we can do Pair Programming, as we're allowed to estimate that into our task estimates)
I'm just curious as to how people would suggest we overcome these issues with poor code being generated.
When you work alone, and produce code which your colleagues find ugly and unmanageable and needs to be rewritten, then do you:
(a) agree with them when you look at it a second time,
(b) disagree?
If (a), then the problem is that on your own, you aren't fully clarifying your code when you write it. Since pair programming is the only thing making you write decent code, I suppose I'd recommend that the "odd one out" should work on tasks which do not involve writing long tracts of bad code: bug-hunting; maybe writing test code, since that tends to be a bit less fiendish. Meanwhile, work on improving your skills at writing better code - perhaps do reviews of your own code from a few months ago, and make notes as to what was wrong with it.
If (b), then the problem you have is incompatible ways of expressing your ideas. The code may not be bad by your standards, but it's mutually incomprehensible, which in a corporate setting means it's bad code. Pair programming means what you write is a compromise that 2 out of 3 of you understand, but that's not really a solution. You need to come to some mutual agreements about what you find most difficult about each other's code, and stop doing that. And you all urgently need to start thinking of "code quality" in terms of "my 2 colleagues will like this code", not "I like this code".
Either way, you all need to work on writing code for the purpose of being read, rather than for the purpose of getting the immediate job done as quickly as you possibly can. Personally I have done this by trying to express things in the way that I think other people might express and understand them, rather than just what makes sense to me at the time. Eventually it becomes habitual. When I write code, I write it for a public audience just like I'm writing this post for a public audience. OK, so on my personal projects it's an audience of people who think just like me, whereas at work it's an audience that thinks like my colleagues. But the principle is to write code as if someone's reading it. You're explaining yourself to them, not the compiler.
Not that my code is the best in the world, but I do think I benefited in that my first job was in a company with 30-odd programmers, so I got to see a wide range of ways of thinking about things. Also a few examples of "what not to do", where one programmer had done something that nobody else could easily understand, and therefore could definitively be said to be bad. With only 3 people, it's not clear whether a 2 v. 1 difference of opinion means that the 1 is a freak or a reasonable minority. When I did something and 4 or 5 people could glance at it and immediately say "eeew, don't do that", then I started to really believe it was just a dumb idea in the first place.
I'd also recommend that if you aren't allowed to budget for code review, lie and cheat. If you're heavily re-writing someone else's code, you're effectively taking the time to review it anyway, you just aren't providing the feedback which is the worthwhile part of code review. So sneak the review in under the radar - write a function or three, then ask a colleague to look at it and give you instant feedback on whether it makes sense to them. It helps to have a conversation as soon as you've done it, with the code on the monitor, but do try not to interrupt people when they have "flow", or to get into lengthy arguments. It's not pair programming, and it's not formal code review, but it might help you figure out what it is you're doing on your own that's so bad.
I'm surprised that you don't have time to do peer reviews but you have time to do paired programming. Is the latter not a much bigger sink of time?
We also have three developers only at our company and, surprise, surprise, we're being pushed hard at the moment. I'm pretty sure my boss would laugh at me if I suggested paired programming because that would be viewed as doubling the number of man hours for a task even though in practice that's not the result it should produce. Our peer reviews are never more than an hour and that is an extreme case. On average I would say they are probably about 10 minutes and, per developer, only happen once or twice in a day.
IMO you should give peer reviews a try. You often find that the offending people (i.e. the people writing the lower quality code) eventually realise that they need to make more of an effort and the quality improves over time.
If you have three developers and each of you think the others code is not good, you urgently need peer reviews.
So:
you are being pushed pretty hard
your code is of poor quality
Do you think the two could possibly be related? The answer is to fix the schedule.
Pair up all three at once.
Set up some coding standards.
Use a dunce cap for build breaking developers.
Perform daily stand up meetings to communicate progress.
Also try peer reviews twice a week, like Tuesday and Friday.
Pair Programming doesn't have to be all day every day to be effective. I have seen good results from even an hour or two working together each week. One way to go would be to pair A & B for a while, then A & C, then A & B... with a lot of individual time in between.
It also depends a lot on the personalities and chemistry of the team members. Two of the three might work exceptionally well together and you'd want to benefit from that.
You should still pair. Set up sessions say 1 day per week and rotate the pairs. This should keep your manager happy and increase the quality of the code, improve communication. If you keep metrics on how many faults happen in paired vs solitary coding you should start to see the benfit and display this to your manager,
eg This took x man hours but saved on average y in defect fixing. Additionally the clode is cleaner and will take less time to alter then next time we touch it.
From there you will have hard statistics and you can start to code more.
Basically your story seems to be the same as mine.
No time to do things.
Mistakes happen.
Rush to fix it (taking more time)
Go to 1
You need to stop the rot.
Code reviews
Enable Stylecop that will force you to write readable, standardised and manageable code
We use code reviews. Additionally there are some single task: changing a diagram, installing some stuff...
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
I have had a few development managers who don't seem to understand or appreciate the difficulties of software design and implementation.
Such managers believe that processes and methodologies completely solve the problem and I have a tough time explaining to them that it is not so and that you cannot read a book on the latest process fad and hope to get results by applying them as is.
The latest frustration I have is to convince my manager to
(a) Give me requirements not piece-meal but a larger set as far as possible.
(b) Give my team lead time to think about how to design, thrash out a few alternatives, work out an implementation sketch, to plan out the tasks etc.
The frustrations are compounded because of Agile methodology and the interpretation of it that says not to do up-front design (as against BIG up-front design in Waterfall), product owner can change requirements at any time and so son.
So far I haven't had much success and have to put up with the resulting frustrations.
Can you give me some arguments that can convince such managers?
EDIT-1:
Retrospectives are done, though not always at the end of every sprint, and the problems are brought up. But as I mentioned, my manager doesn't appreciate the need for design lead time and the frustrations with piece-meal requirements.
EDIT-2
I don't have a problem with changing requirements. I understand that it will be so, but imagine this: You want a small feature to begin with and then you keep adding more around it. After a few iterations, the design cannot handle it anymore and a redesign (not refactoring) is required. This could have been solved better with an upfront design in the first place, had the related features been investigated together. Its not BDUF, its the natural way of doing it (what I call software engineering common sense).
My manager doesn't understand why I ask for time to redesign (a few times I just call it refactoring so that it fits the Agile way of doing it, but it really is redesign) and not developing and demoing new features.
Every time requirements are changed (or increased) so should
the estimate to complete and,
the assessment of risk
Start giving updated estimates (even if you have to guess) and lists of risks every time you get an updated or new requirement. This will help your manager make the connection.
Try to do this in a spirit of helpfulness--"for planning purposes"--so that you aren't perceived as obstructive or lacking "can-do attitude." Remember that estimates can (in theory) come down, and risks can be reduced.
Business requirements are going to change no matter where you work. It's not your fault, it's not your boss's fault, it's not anybody's fault. The entire point of taking the requirements on piecemeal is to encourage you to think about the problem at hand, not some other problem that you might or might not need to solve. It's quite liberating once you get into the rhythm of it.
Think of upfront design as premature optimization. You may not need it, and even if you know you need it, you'll know more about your design two weeks from now than you know about it today. It'll help you solve your engineering problem with the best possible knowledge about the state of your code.
That having been said, edg is absolutely right. When you add more requirements, the estimate changes. This isn't the fault of the developers or anyone else; more work means more work no matter how you square it. If your boss doesn't realize that adding requirements will result in a larger estimate for the project you need to explain to him that Agile isn't a magic bullet that allows you to add more features without paying anything for them.
Agile Simple Design doesn't mean don't do ANY design/architecture up front.
It means do the minimal design up front, so that you will not pay a horrible price for reasonable change requests.
Scott Ambler talks about Change Cases - http://www.agilemodeling.com/artifacts/changeCase.htm
James Coplien talks about Agile Architecture - http://www.infoq.com/presentations/Agile-Architecture-Is-Not-Fragile-Architecture-James-Coplien-Kevlin-Henney
http://blog.jaoo.dk/2009/03/04/handling-architecture-in-the-agile-world/
The art/craft in all of this is in how to slice the architecture in a way that allows:
relatively fast convergence on overall architecture/infrastructure - on the order of days per months of estimated development time.
developing "just enough" architecture/infrastructure per each feature/requirement
doing the right balance of preparations for the future compared to focus on the features of today.
Its important that your Product Owner is aware of all of this balancing act as well, and you work collaboratively. He should understand that if you disregard all thinking for the future, each change will be very costly. There is a price to be paid for flexibility.
Its btw very similar to investment in QA and test automation. You pay something now, that will pay off only after X times you test the code. if the code never changes it was a waste of effort. but everyone knows that most code changes...
Buy your manager this book. That's what I did, and it worked great :)
First of all this issue seems quite sensitive, so all I wrote below is just my personal opinion, and not necessarily a wise thing to do.
In my opinion you cannot make software if you do not know what problem it should solve. If requirements come in small parts that are too small to oversee the problem, then I would just fire questions about the parts that seem to be missing. Like: "okay so the software should do X, but does that also mean Y or otherwise maybe Z? Because if it is Y then ... but if it is Z then ..." Of course if the manager is in the middle of extracting the requirements then he cannot answer, but at least he knows that there are still open issues that influence development.
About no lead time for design: design and development are an iterative process that could go hand in hand. It is just how you name the thing. If the manager wants to see some code at the end of the day, okay then I would just use the first half of the day to design and the second half of the day to make some code based on that design. If the manager does not want to see the design, fine with me then I'll just show the code.
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
Maybe my understanding of agile development isn't as good as it should be, but I'm curious how an agile developer would potentially use off-the-shelf (OTS) software when the requirements and knowledge of what the final system should be are changing as rapidly as I understand them to (often after each iteration of development).
I see two situations that are of particular interest to me:
(1) An OTS system meets the initial set of requirements with little to no modification, other than potential integration into an existing system. However, within a few iterations of development, this system no longer meets the needs without rewriting the core code. The developers must choose to either spend additional time learning the core code behind this OTS software or throw it away and build from scratch. Either would have a drastic impact on development time and project cost.
(2) The initial needs are not like any existing OTS system available, however, in the end when the customer accepts the product, it ends up being much like existing solutions due to requirement additions and subtractions. If the developers had more requirements and spent more time working on them up front, this solution could have been used instead of building again. The project was delivered, but later and at a higher cost than necessary.
As a software engineer, part of my responsibilities (as I have been taught), are to deliver high-quality software to the customer on time at the lowest possible cost (among other things). Agile development allows for high-quality software, but in some cases, it might not be apparent that there are better alternatives until it is too late and too much money has been spent.
My questions are:
How does off-the-shelf software fit in with agile development?
How do the agile manager and agile developer deal with these cases?
What do the agile paradigms say about these cases?
Scenario1:
This can occur regardless off the OTS nature of the component. Agile does not mean near-sighted.. you'd need to know the big chunks.. the framework bits and spend thinking time on it beforehand. That said, you can only build to what you know .. Delay only till the last responsible moment.Then you need to pick one of the alternatives and start on it. (I'd Avoid third party application unless the cost of developing it in-house is infeasible.. but that's just me). Prototype multiple solutions to check feasibility with list of known requirements. Keep things loosely coupled (replacable), easy to change and full tested. If you reach the fork of keep hacking or rewrite, you'd need to think of which has better value for the business and pick that option. It's comes down 'Now that we're here, what's the best we can do now?'
Scenario2:
This can happen although the chances are slim compared to the team spending 2-3 months trying to get the requirements 'finalized' only to find that the market needs or customer minds have changed and 'Now we want it this way'. Once again, its a question of what is the point of time till which you are prepared to investigate and explore before committing on a path of action. Decide wisely with whatever information you have upto that point.. Hindsight is always 20-20 but the customers wont wait forever. You can't wait till the point of time where the requirements coalesce to fit a known OTS component :)
Agile says Do whatever makes sense and strip out the non-value-adding activities :) Agile is no magic bullet. just my 2 agile cents :)
Not a strict answer per se, but I think that using off the shelf software as a component in a software solution can be very beneficial if:
It's data is open, e.g. an open database or a web service to interact with it
The off the shelf system can customised easily using a similar programming paradigm to the rest of your solution
It can be seamlessly adapted to the rest of your work-flow
I'm a big fan of not re-inventing the wheel, and using your development skills to design the 'glue' between off-the-shelf solutions can be a big win.
Remember 'open' is the important part, and a vendor will often tout their solution as open when it isn't really.
I think I read somewhere that if during an iteration you discover that you have more than 20% more work that you initially thought then you should abandon the sprint and start planning a new one taking into account the additional work.
So this would mean replanning with the business to see if they still want to go ahead with the original requirements now that you know more.
At our company we also make use of prototyping before the sprint to try and identify these kind of situations before they arise on a sprint. Although of course that still may not identify the kind of situation that you describe.
C2 wiki discussion: http://c2.com/cgi/wiki?BuyDontBuild