Typing “Agile Development” into Google search brings up 123,000,000 results. Sift through the first 5 pages, spend 3.5 hours reading through webpages that all seem to be the exact same copy of each other with cosmetic edits, or worse, websites that say the exact opposite, and be nowhere nearer to understanding what an agile transformation is. Been there done that.
We have tried, and we have failed, and this is what we have learnt – to save you all that computer eye strain, mouse fatigue etc. 🙂
Speaking to Titaners across teams, we bring you the differences in work practices after our Agile transformation, broken down into the main areas of:
After a full month at Titansoft as interns, we have come to learn more about Titansoft’s Agile culture. So, what is Agile software development?
Agile is often compared to the traditional Waterfall methodology where a linear approach is taken with software development; each stage is generally finished before the next one can begin. On the contrary, Agile methodology emphasizes the rapid delivery of an application in complete functional components, with a high commitment level from the client throughout the project. With Agile, all tasks are “time-boxed” into phases called “sprints”.
In Titansoft, each sprint lasts a week within which a running list of deliverables planned at the start of the sprint is completed. Deliverables are prioritized according to their value as agreed by the stakeholder and product owner. If all planned tasks for the current sprint cannot be completed in time, work is reprioritized and the information is used for future sprint planning.
Bright and early at 9.30am, the 5 of us arrived at Titansoft, ready for our first day of internship. We were welcomed by our friendly HR colleagues, Sky and Jessie, who tapped us in to a quiet office and explained Titansoft’s unique flexi working hours where Titaners get to plan their own work schedule, as long as work gets done!
As interns, we received a brief orientation where we played some ice-breaking games to learn more about each other and Titansoft. For Summer 2018, we have 4 Software Developer (SD) Interns and 1 HR Intern (who says operational role interns are not welcomed in a tech company!)
Inheritance is a common feature in OOP languages to specialise classes/types and allows polymorphism. It is easy to reuse the common functionality between classes by moving it to the parent class and use by the child classes. Without being mindful of software design principles, it can lead to increased coupling and responsibilities, making existing code hard to change. We’ll take you through a situation in C# MVC’s controllers and show how it improves the design by refactoring. The class diagram shown illustrates a fictitious online photo stock website.
This is a violation of interface segregation principle (ISP) which states that no client should be forced to depend on methods it does not use. In this case, BaseController has multiple methods and through inheritance, all of the child controllers have access to them but only use some of them and does not need some of them. When there’s a change in BaseController’s GetCredit, the child controllers which use it might be affected and should be checked and tested.
Stored procedure has been a standard in Titansoft for a long time. So why did we choose this over inline query? What are the benefits? Well, in my opinion, here are the top 4!
As James Shore says of pair programming in his eponymous blog, “It’s more fun than it sounds: two programmers at one computer. One drives; the other navigates. Switching roles fluidly, they constantly communicate. Together, they accomplish better work more quickly than either could alone.” Teamwork never sounded so poetic.
Titansoft is an Agile organisation and we have been practicing pair programming since 2014. And having experienced the benefits of this practice, we are extending it to out Recruitment process. Having a programming session with a potential candidate is only one part of the hiring puzzle, but it’s often the most important one. Rather than looking at the CV and asking a long list of questions, which may not be as effective, we get around recruitment for our Senior Software Developers by holding a pair programming session. We believe that the pair programming process creates a better opportunity to showcase a coder’s skill.
“Through pair programming, our developer can know more about how the candidate behaves during real work such as his working style, coding preference, discussion etc. In addition, we are also able to show the candidate the way our company people code.”
Ji Zhoubo – Senior Software Developer in Titansoft
This is the second formal TDD training I have joined (The first one was conducted by Joey Chen(https://www.facebook.com/pg/91agile/about/?ref=page_internal). I could not find online line 😦 sad..). I would like to share some “Aha” moments along the way of this training.
Before that, allow me to share how i took the training(The first 2 series, which is free 🙂 ):
- For 1st series, I implement without TDD first. The reason why I do that is I am just very curious of what is the time difference and other difference if i am lucky to find out.
- For 2nd series, I just follow the video and stop where ever I need to think or research or take notes.
Ok. That’s enough. Let’s go to the my “Aha Wow” moments:
- Really step by step by step : Fail -> Add Logic -> Pass -> Commit -> Refactor
- It’s developers responsibility to cover more tests than the general requirements from clients. (I mention this because I have an assumption from my first TDD training that developers only need to add tests based on the requirements. )
- Avoid more complex integration test by adding unit test when small class or methods come out along the way of implementation.
- Triangulation concept somehow makes me feel better compare to one of TDD rules: You are not allowed to write any more production code than is sufficient to pass the one failing unit test. Because when ever I try to hardcode to make the test I feel so bad and keep wondering why not find the basic logic 1st.
- Multilevel of abstraction code smell apply not only to same functionality, but also all same level functionality with different purpose.
Assume inside one function, there is one logic related to getPrice, three logic related to display price. We should abstract both the getPrice logic and the displayPrice logic to achieve same level of abstraction for easy reading and maintaining.
- Duplicated Concepts/Ideas: Do not repeat your self is not only about code, but also the way of covering the logic.
e.g. if A else if B else if C …. is one example of duplicated ideas
- Intuitive and Mechanical approach of software designer (http://blog.jbrains.ca/permalink/becoming-an-accomplished-software-designer)
- Refactoring based on single responsibility. Re-assign responsibility makes the code much more flexible and clear. For this I am not able to express it clearly by tying here. I strongly suggest you take the 2nd series of the training. Then you may feel it more.
For my little test “For 1st series, I implement without TDD first.”, I did it within 15mins including the tests, while the training took more than one hour. But the test cases are much more less. Reason: I understand the logic of fraction adding. So my test only focus on the logic and with few special cases. I feel some tests inside the 1st series training are duplicated. So until now, I believe that TDD can help design the code but not necessarily helpful in every development scenario.