Surya Suravarapu's Blog

Ramblings on software and stuff related

Posts Tagged Agile

Joel vs UncleBob: Relevance of TDD and SOLID principles

Feb 1

Posted by Surya Suravarapu in SoftwareDevelopment | 1 Comment

This is really a clash of two titans, both of whom I greatly admire -- Joel Spolsky (Joel on software) and Robert Martin (uncle Bob). I follow both of them for many years, their writings, on Twitter, podcasts and so on. Uncle Bob was not so happy about the discussion on Stackoverflow podcast #38 and he responded in kind.

My thoughts:

  • Unit testing is extremely important. Every minute that a developer spends writing a testing is well worth hundreds of minutes he would spend later in the maintenance phase. Having said that, if the concern is whether 100% code coverage is too much? Perhaps it is, determine what gives best bang for your buck and go with that. If the question is whether they are useful at all? Absolutely. Taking the same reason as cited in the podcast -- you have a large code base and now you need to either modify or add new features. Once you make the change:
    • how do you know you are done? I run the unit tests that I wrote for the new functionality and pass them.
    • more importantly, how do I know whether I broke any existing functionality? I run all the tests that I have (assuming I have decent code coverage) and make sure all the tests are passed.
    • unit tests along with the acceptance tests, if run more often, can provide extremely useful information about any deviations from the requirements. Rapid feedback, isn't it one of the core principles of agile?
  • You don't have to follow TDD to the tee, or any methodology for that matter. But the spirit of unit testing, in my opinion, is extremely important to know the health of your code.
  • SOLID principles, as Uncle Bob said, are engineering principles. These principles guide you in building the software that is flexible, maintainable and reusable. This is even more important in agile environments where you develop software in tiny increments.
  • Enough emphasis must be given to code hygiene. With out that, it is just a matter of time that the system gets polluted, and not sure how you can keep the customer happy for long. I agree that the focus should be on the customer and just don't architect or refactor just for the sake of it. Focusing on the customer means -- designing flexible, extensible architecture (using design principles) so that you spend less time in constant-maintenance mode.
  • Another common argument against writing tests is time to market. Goal is to get the software out as quickly into the market as possible, fair enough, but at what cost? As software craftsmen we need to pledge for not shipping shit (must read).

I repeat, I have great regard and respect to both the individuals, and hope Joel can elaborate on some of the points that are discussed in his future podcasts and clear the air.

Tags: , , ,

Eliminate Waste – The Toyota Way

Jan 28

Posted by Surya Suravarapu in LeanMethodology, SoftwareDevelopment | Comments off

I'm currently reading The Toyota Way, love it so far. More detailed book review will follow in a separate post but for this one I would like to concentrate on the waste (w.r.t software development) and eliminating it. Book describes Toyota Processing System (TPS) and much more. Lot of it can easily be applied to the software development.The core principle is the same regardless of the industry --
The first question in TPS always is what does the customer want from this process? (Both the internal customer at the next steps in the production line and the final, external customer).
For every step of the process the focus is very much on what additional value is being provided to meet customer expectations.Here are the wastes described in the book along with some of my thoughts as applicable to the software development:
Overproduction
Working on projects/features/tasks that adds no value to the larger goals of the organization is considered waste. Scope management is extremely important while the project is in progress. It is not that uncommon that wants are inserted into the project scope that are separate from the needs. These wants increase significant effort with design, code, test, etc. These efforts, which are unnecessary to start with, opens up chance for more design and coding, means more scope for defects and maintenance.
Waiting (time on hand)
Lack of coordination among different groups cause team members wait for the next action. We may have seen many times developers waiting for completed requirements, testers waiting for the next build so that they can start testing. Some times even a minor change takes forever to be applied with significant overhead in the change control process. Acknowledging these issues itself is a battle that is half-won. For example, developers waiting for a central build to happen to know the issues with their code is counter-productive. They need to know that sooner; setting up a continuous integration system could help alleviate that concern.
Unnecessary transport or conveyance
Based on my understanding this point relates to overhead involved in performing development activities. For example, it may be a company policy to produce UML diagrams upfront. Architects spending significant time on this just for the documentation sake is not adding much value to the evolving design. The focus, as discussed earlier should be on value and value alone. Identify the overhead, eliminate it. Find different (lighter) ways to communicate. (Among many options Modeling in color using post-it notes is a useful design technique).
Over processing or incorrect processing
At macro level -- company's vision is not translated into tangible value-added goals by the middle management, individual architects/developers spending time working on tangential items that adds no value to the customer. Over processing has some overlap with overproduction mentioned above. Incorrect processing is more common in a heavier process environment with longer feedback loops. (On a lighter note, a cartoon describing what customer actually wanted and what was actually built).
Excess inventory
Each group working independently, developing their own components for way too long and try integrating only during the final phases of the project. This would usually result in more work or the work in a wrong direction. Incorporating rapid feedback mechanism is the key. Again, a close-knit cross-functional team works much better minimizing this waste.
Unnecessary Movement
Unnecessary distractions could fall in this category. As is often quoted from Peopleware -- developers work their best when they are in the "flow" or "in their zone". Each distraction wastes significant development time. Needless to say but as much as possible developers must not be pulled into unnecessary meetings as they should concentrate as much as possible on the stuff they do the best.
Defects
This is a well known waste in the software development. A defect by itself is not such a bad thing, but the concentration should be on finding it sooner and as much early in the process as possible. Patching the fixes is not the best way to build the quality. The quality must be built into the process. Test automation is an absolute must (my experiences in this regard are documented here). It is equally important to learn from the earlier defects, recently posted my thoughts on root cause analysis
Unused employee creativity
This is applicable to employees in any industry. It is extremely important to instill a sense of ownership in the team. In the author's own words -- losing time, ideas, skills, improvements, and learning opportunities by not engaging or listening to the employees is not acceptable.

Tags: , ,