Posts

Measuring Cohesion - The LCOM principle

There has been a constant doubt in my mind since I got to know about the pattern of developing applications based on DDD. Still a novice, I quite frequently come across situations where I'm not sure what the best place to put a particular piece of functionality is. I take a calculated risk, quite often a wrong one, trying to assess the after effects. I recently came across this great read on cohesion. What should be a "good enough" basis for deciding how cohesive should different pieces of functionalities be. And I particularly loved the example provided: Considering two different implementations of the same functionality: Class A{ getDevices() createDevice() modifyDevice() removeDevice() repairDevice() diagnoseDevice() } It's quite logical to think of all the methods to be directly related to a device. But upon a closer look, one might say that the last two methods only deal with troubleshooting the device. Should the last two methods then sit inside a TroubleShootDe...
Read more

Must vs should

 I've been working with enterprises for the past 4 years, with most of my experience revolving around giants. Extravagant revenue, high stability and the budget to experiment. It's amazing, working on the coolest tech, with comfortable deadlines. As a tech enthusiast, it brings out the best in you, exposing you to state of the art technology which may or may not work in the end. But you can always spike on it, because the enterprises have got the appetite to handle failure in case a long haul doesn't lead to fruitful results. And why shouldn't they? They've grown to such a huge extent that it's now a necessity for them to research, experiment and take corrective measure. Take Amazon for example, the fire phone was a miserable failure but it lead to it becoming a leader in voice assisted tech, alexa. Having spent all my experience in such an ecosystem it was quite evident that anywhere I go I should expect my client to encourage working on tech that's going t...
Read more

Developmental plasticity

 Back in the days, while in college, all I used to care about was getting it done. Had you shown a white textual output on a completely black screen, you would have done buttery smooth in your academics. I must admit this went on till the final year of my college, until it hit me. I still remember how one of the deciding rounds during my placement was supposed to be something called a "pairing round", one where you'd just bounce off ideas with the mentors and build stuff programatically. What on Earth does 'designing' have to do with programming I thought, until it hit me again! This time, harder! Months long rigorous training around making us understand how the wheels of a car should have nothing to do with the odometer by design. No, we weren't learning automobile engineering, but engineering an automobile in the software ecosystem. It made sense, making sure responsibilities of objects stay right, don't get mixed up and build up a system as self descrip...
Read more