We all did it a couple of times, but it wasn't until recently that I found out how useful and efficient it was. Our fresh hires start working on production code relatively soon after their first day. Nevertheless we want to review their work before check-in.
Getting up to speed
I always start with, "Let me see the tests". It is only partially to emphasise the importance of tests, the real reason is that for me it's easier and quicker to engage in the task he has just solved. And this gives me the chance to profoundly review the code itself and how it looks.
Defining
Sometimes we don't even continue to the code, because it turns out that he misinterpreted the task at hand, and solved something else. But that's okay too, for through the tests I can very easily and clearly explain what the real task is. If we were to do this via the implementation, it would be less unambiguous.
Demonstrating
Finally, I can show him couple of coding tricks, again without being too superficial, yet being quite quick. What I mean is I can quickly refactor his code on the spot, without saying things like "... and you can imagine the rest" - no, at the end of the demonstration we have a still working code(checked by the help of the tests), but with me already having made my points on coding as we know it: expressive and duplication free.
Read full post...
Thursday, 20 October 2011
Friday, 3 September 2010
Really.Only.Very.Rarely.
The jawbreaker above is one of the most efficient half-sentence that a client could unwittingly ruin your day with. And usually alongside your day goes most of the model you have been building up. On top of all there is this huge chasm between the thinking of the customer("Really, it's no biggie. We only have like two cases a month where this and that..") and the cruel reality of software's unforgiving nature, i.e. if you want the software handle those two-times-a-month exceptions then that piece of the software needs to be developed just as well as another piece that handles all non-exceptional cases.
Laymen have a hard time understanding it, and for us it sure feels like trying to explain the colors to a blind man. No wonder, I mean we have learned software in school for years, have been around in the industry for even more. We spend most of our time in an environment where this unforgiving nature of software is self-explanatory and taken for granted.
It hasn't been till only recently that I realised how this problem is actually an opportunity. Why this jawbreaker is not something you should loath and fear -- on the contrary. This is something that can help you deliver quality software on time.
The answer is almost here. I just need you to take a second and find out on your own.
Read full post...
Laymen have a hard time understanding it, and for us it sure feels like trying to explain the colors to a blind man. No wonder, I mean we have learned software in school for years, have been around in the industry for even more. We spend most of our time in an environment where this unforgiving nature of software is self-explanatory and taken for granted.
It hasn't been till only recently that I realised how this problem is actually an opportunity. Why this jawbreaker is not something you should loath and fear -- on the contrary. This is something that can help you deliver quality software on time.
The answer is almost here. I just need you to take a second and find out on your own.
Read full post...
Monday, 14 June 2010
Agile in hostile environment
It can be tricky to apply agile methods in a fundamentally waterfall environment. So tricky in fact, that we might be better off without agility.
Agile Manifesto was created to help creating software of value, which - according to the founders - required a different approach and a different set of methods altogether. The neccessary shift of approach was expressed in nice and clean preferences from wich the methods are more or less directly derived. If because of the circumstances we cannot make the shift in the approach, using the methods stubbornly makes little to no sense. I start with the easy ones, see if I can ruin it all for you..
(1) If the deadlines and the scope is fixed, moreover you need to deliver certain results (documentation, software, test results, etc) at certain times, you are following a plan, instead of responding to change.
(2) If you need to provide detailed req.spec, estimations, design documents, etc, then obviously working software is only of second priority, since the signing and the delivery of the contract relies heavily on these documents, rather than on working software itself.
(3) If you have to have the req.spec and the corresponding estimations upfront, you and your client - forced by contract - are bound to them(i.e. requirements and more or less estimations too). And then with even the best intentions you can get your client involved in the preliminary discussion only which are theoretic almost by definition.
(4)I left the toughest one for last.
The sobering truth is that - and a sick plot twist is around the corner, you better watch out - in such a hostile, anti-agile environment, as the above depicted one - applying agile tools and processes, in fact might be the wrong choice, and for the wrong reasons too. Because this in itself goes against agile principles in that it chooses processes and tools over people, who can't enjoy the benefits of agile methods, nonetheless have to invest the extra effort they demand. And almost all of it is completely in vain, as the software won't be any more of value than it would have been with traditional methods, because it will turn out to be exactly the thing that was required/designed/estimated/agreed-upon before any line of code had been written and/or tested.
Read full post...
Agile Manifesto was created to help creating software of value, which - according to the founders - required a different approach and a different set of methods altogether. The neccessary shift of approach was expressed in nice and clean preferences from wich the methods are more or less directly derived. If because of the circumstances we cannot make the shift in the approach, using the methods stubbornly makes little to no sense. I start with the easy ones, see if I can ruin it all for you..
(1) If the deadlines and the scope is fixed, moreover you need to deliver certain results (documentation, software, test results, etc) at certain times, you are following a plan, instead of responding to change.
(2) If you need to provide detailed req.spec, estimations, design documents, etc, then obviously working software is only of second priority, since the signing and the delivery of the contract relies heavily on these documents, rather than on working software itself.
(3) If you have to have the req.spec and the corresponding estimations upfront, you and your client - forced by contract - are bound to them(i.e. requirements and more or less estimations too). And then with even the best intentions you can get your client involved in the preliminary discussion only which are theoretic almost by definition.
(4)I left the toughest one for last.
The sobering truth is that - and a sick plot twist is around the corner, you better watch out - in such a hostile, anti-agile environment, as the above depicted one - applying agile tools and processes, in fact might be the wrong choice, and for the wrong reasons too. Because this in itself goes against agile principles in that it chooses processes and tools over people, who can't enjoy the benefits of agile methods, nonetheless have to invest the extra effort they demand. And almost all of it is completely in vain, as the software won't be any more of value than it would have been with traditional methods, because it will turn out to be exactly the thing that was required/designed/estimated/agreed-upon before any line of code had been written and/or tested.
Read full post...
Subscribe to:
Posts (Atom)