Cool Software Things Volume I

Continuos Refactoring

Refactoring is touching the code , when it starts to smell. Long story short summary, your code starts to smell when it has duplications, long method names, long parameter lists, bloodless objects or objects which has more than one responsibility or methods more than one task or parameters has more than one meaning. Addition to that you cannot have message chain with so-called object orientence with so many delegations. And Don't forget Your code should be the documentation and documentation should be your code so writing comments are something bad, your code should be self explanatory and not require comments to explain how implementation is working.(Excluding commenting on interface. comments on interfaces are explaining the contract.). You may need refactoring if your code has one of those and here is How to do it? Answer 1, Answer 2
refactoring should be a continuos activity as you grow your product. Adding a new fix, adding a new feature, adding a new test should trigger refactoring request.

Right Software Methodology

So far I have been in the organisations applying Waterfall, SDLC, Agile. I believe software methodology is key interface in implementing software management. However What I observe is implementing software methodology is also quite important as selecting them. Companies should be aware taking the methodology as a template and applying to their own way of workings. I strongly believe In the wrong implementation of Agile you can end up with having less productive team than a flexible waterfall team. Methodology you choose should be lightweight, and you should not dictate the methodology by repeating terms and philosophy like a parrot all the time. This should be consumed naturally. The way you apply and needing should be the common sense.
For a brand new organisation my advise would be to apply the procedure below;
1. pick NONE.
2. continue working
3. struggle for a certain issue,
(you will definitely see people crying on certain things)
(your people will cry differently than the others, so don't copy paste)
4. search for an agile practice
5. apply the found practice or create a new one together
6. return 2


Delete Code

Comparing the test done, (unit test, integration test, black box test, white box test, functional test, verification test, production test, customer acceptance test) and code written, it is obvious that written code is only a small fraction of the all tests done. Moreover to that, we are observing that only small piece of the code written is actually working. Most of the code is over-designed for some never happening future feature requirement, or afraid to touch because it is not understandable.
When we bring all this together , I believe deleting code is a very valid skill. if you see things over engineered than sooner or later you will end up having your code smell. But if you think a piece of software is unnecessary but somehow that part is tight to another code or not necessary at all , than question it. This will save considerable amount of unit testing time and let other developers save their time to focus on the valid part when trying to understand the code or maintaining it.



Next: Api Design, But, Extending Runtime, Ramp up fast, Immutability, Water, Smallest thing that works