I'm Kosala Nuwan

#cleancoder #software #architect #founder @alertboxinc. #ux #leanstartup addict. a #nonconformist. steals stuff from the best. Follow @kosalanuwan on Twitter. See Kosala's LinkedIn profile. Read more on Alertbox tumblog, the ahaa! geeks version of software craftsmanship column by Kosala. See Kosala on NuGet, GitHub, and CodePlex. Everything is an *Object* is a Myth.

[kosalanuwan]

Snikt! Yet another OR-Mapper

Our new product is selling like crazy

I love Microsoft, especially when it comes to Visual Studio. I would do J2E if it supports. Years back, the glory days of one of the companies I worked, decided to migrate one of the products, super-duper banking app to windows platform, to .NET ofcoz. There were few day-end routines we wrote which processes transactions to accrued interests but not more than 15 of those. We noticed there is a significant performance leak, that it took almost half-a-day to finish off, and was absolutely unacceptable for the few thousand accounts the bank had.

It wasn’t a complicated solution, yet, the Memory and the CPU were hitting nearly 100% on the app server. There were stored command used to perform queries, .NET reflections used to late bound routines, but the leaks had nothing to do with these designs of the code.

The frameworks that made our lives rapid!

Yes, we have made few mistakes here and there, and then there is Typed Datasets used as the OR-mapper in the data-tier which made our rapid development run off the roof – that was a +1. When we are digging deeper into the core of the code, debugger consumed considerable time just to instantiate the datasets. It would have been acceptable but doing this for 100s of thousands was a big cost for us. There weren’t hand full of ORMs at that time, and the ADO.NET Typed Datasets was the thingy. We were not in a position to drop all the Typed Datasets to old-school way of mapping query results to business objects. A pragmatic approach was to use the core business object, which is the Account model only on the day-end processes as a proof of concept.

Few nights with cheesy pizza and beer, my colleague Buddhi Pathirane and I managed to run the day-end routines again with old-school mappings. SHAZAM! the processes did not even take more than couple of hours to complete. In general, most of the code we wrote had to deal with stored commands, mapping query results to domain models, than the business logic. It was the fastest we could do in terms of execution, but sadly there were new bugs introduced, then there is this code that we had to write and it made our grown up developers cry.

That omnishambolic moment!

One of those days, another critical feature was to migrate all the Swedish vehicle details to a SQL server database. Operations were mostly upserts for 7-10tables and the process took nearly 9hours for 4million records. This time, it was on LINQ-to-SQL and there is nothing much we can do to hint the DataContext to optimize queries. So we decided to write our own T-SQL commands. It’s something we are all quite familiar with.

Choosing Entity Framework over LINQ-to-SQL had many benefits. The business components need not to know what data model I use. So, we used Entity Framework’s promising Code First T4 template to split the Context from the domain model. It was the unicorn when we decided to use in almost all the projects in that company. Fellow developers loved it but the major issue is that it is 2-3 times slower, or even worst in some cases. So, for many scenarios I had to write my own queries, and so did everyone else.

This out-performed in most cases but sometimes the SQL generated by the query parser is similar to the ordinary SQL we write. This led us to another clue: performance leaks were not along with the queries designed by the ORMs. Both frameworks’ mapping logic was not fast enough for this matter.

How many times do I have to fall?

We were querying and mapping results to the business objects, so we used in-line SQL queries and stored commands every time there is a significant performance leak which is quite normal for us. Typed Datasets, LINQ-to-SQL, and Entity Framework have its positives but that’s what it has been hyper promoted by the owners and the followers, for any other full blown ORM for that matters.

All I need is an ORM that suites my data-tier which can map SQL query results to business objects, not their associations and so on. It is quite straightforward so I tried writing by my own. Here’s how the first version looked like. It would be a crazy idea to replace the entire ORM, so my intention was to tweak some leaks side-by-side with this mapper wherever applicable. I also thought to push an open-source version with few more enhancements. Here’s the GitHub repo to fork.

More resources:

Snikt! source code to fork

Comic credits to Dilbert.com

[kosalanuwan]

Cleanup unit test code for tombstoning this summer?

Is our new product safe to start selling?

During the warmest winter year 2007 a leading Swedish company providing solutions for Work Force Management, transforming their major products into .NET platform when I departed to Stockholm to work closely with couple of architects amongst pioneers in the development team. Their well-footed infrastructure and toolset were quite interesting at that time. UX, Scrum, DDD, TDD, and Continuous Inspection to Continuous Delivery among the terminology detailed where 80% unit test coverage threshold of the system under test was quite a showoff. How much test code is enough to keep everyone happy? No quantitative answer can satisfy everyone, but, enough tests to break the system keeps pumping adrenaline for developers to write more tests than production code. Doing Test-driven development and writing Unit tests have different connotations in the Agile Diaspora of the software industry. It is pity when test code is not treated equally important as the system under test. In my article called Lazy developer’s test strategies reduce bug count, here’s what I said about maintaining unit tests;

You have to change your tests when the production code changes. Your tests get evolved when you add more modules to production code. Eventually, maintaining the test suite becomes the biggest complaint (…)

Tombstoning for unit testing, especially in the agile nature, could often result in no hint of whatsoever about the test suite intent to verify. A smarter, or rather a lazy way to maintain a test suite, is to express with domain-specific test language. Inevitably, this brings out the ubiquitous meanings to the specifications that screams in the test suite. The key practices in this approach when maintaining readability of the test suite are;

Structure of the suite,

Conventions to adhere, and

Patterns to practice.

Snikt! is an open source code, can be found in GitHub, which demonstrates these attributes.

Structure of a test suite, is the firsts that screams at the glance. It’s also the firsts that speaks the same domain of its system under test. It’s the firsts that answers for many questions when dealing with specifications: which spec belongs to which interactor, what behaviors have being verified, and so on and so forth. Typically, this is quite similar to the structure of the production code, at least that’s how it feels when peeked.

Conventions, on the other hand, adds clarity and readability when organizing these specifications. There are few conventions to note here:

Convention used to logically group specifications that belongs to a single interactor, for instance, DatabaseSpecs namespace.

Convention used to name unit test specifications, for instance, WhenExecuteQuery class.

Convention used when writing assertions, for instance, ThenStrongTypedListIsReturned assertion.

It sounds boring – no drama at all – when writing a unit test. Almost every specification initialize or mock few dependencies, execute a method or two, and check the outcome. Its the same for any given use case. But, it takes time to idealize specifications for behaviors which are worth writing. A smarter approach is to use the Arrange-Act-Assert pattern when designing these specifications. A much clean approach, however, is to use the Build-Operate-Check pattern, plus, a naming convention to logically grouping assertions. It is called Single Concept per Test.

More resources:

Snikt! source code to download

Comic credits to Dilbert.com

Read Lazy developer's test strategies to learn more about test patterns

[kosalanuwan]

Scream! Work-in-progress is a waste, do One feature at a time

The best thing about the future is that it comes one day at a time. – Abraham Lincoln

Hypothetically, if a team is left with only Two-thousand keystrokes – it’s just a random figure, enough to convince my mental model – the toughest challenge, despite the fancy features in the Product Backlog and the Build Matrices, is to deliver value for the money. For a novice team, this would look nothing but chaos, but it doesn't when the keystrokes are the limited window of opportunity to dive in the blue ocean.

Use agile programming methods

Doing Scrum way of Product Engineering, the Agile Diaspora of the software industry, especially in offshore and outsource teams, keeps forgetting its very basics of delivering Working Software as a Team. In simple steps, Scrum starts by breaking down a product idea into a smaller feature, which is then prioritized and shipped iteratively as a team that shares the same goal. Experts from Continuous Inspection to pretty much Continuous everything have been talking about this now and then. A smart decision, even in the real world, is to push many stories to the right corner of the Scrum Board. A much smarter decision, however, is to get the top stories first, obviously, but what it is then went wrong with delivering features?

An experienced team can have their interpretation of how they should be delivering features within the sprint, as their wish. Let’s accept, passionate developers, compelled to pick stories that are fancy them more. It’s their ego that is not letting go of any technically challenging task. It is the same ego that keeps them over committed on work schedules, regardless of how good or bad their time management skills are.

You worked on tasks that aren't important

Matured teams can wish to formulate self-organized self-governed for themselves. The catch is, when the team was struggling, it’s that cynical habit of them to volunteer for troubleshooting, stepping out their own urgent and important stories, and multi-tasking. As Stephen R. Covey nicely explains in his book First Things First, it’s not unusual to see how people move onto not important activities that appears to them as urgent. Thus the Work-In-Progress cannot indicate the actuals of the sprint since there are many people involved with too many feature stories, simultaneously. The PO, management, stakeholders, and the team too have to patiently wait till the end of the sprint to know the remaining work since Burn Down matrices do not adopt the numbers.

XP, or rather interesting Feature Crews – What do these have for Scrum teams? A way of pairing working model to glossing over, if adopted with care. There is nothing unusual in splitting the team among smaller ministries. Perhaps, not too many and not too little but just enough to get the features to move forward without being blocked half-way through. It is said, two heads are always better than one. The changing scenario in Scrum teams begins by:

Pairing with an experienced developer when the code is not familiar.

Work-in-progress stories indicate the active stories that the team is currently working.

Working at a pace which is currently optimum for the team.

The number of stories that are slipped to the next sprint is minimal or rather declined.

For the benefit of stakeholders, clients, and those who think the time has arrived to dive into the blue ocean, after sprinting few iterations, it is a matter of terminating the current sprint and compiling the features what was in the right corner of the Scrum Board. Despite the features that can be shipped, the ones that have been discarded can be minimized with its focus on the limited work-in-progress.

More useful resources:

Succeeding with agile by Mike Cohn

Planning extreme programming by Kent Beck

First things first by Stephen R. Covey

How to practice pair-programming with Code Kata

Comic credits to Dilbert.com

[kosalanuwan]

Oh-no! Yet another Tab Control : Without JavaScript

You can be my disposable evil lackey!

Few months ago, we had some issues with our tab controls used in the web app. We did some mistakes too here and there, and also there is this JavaScript nightmare. There are plenty of client-side JS libraries available, for instance, jQuery UI and Kendo UI comes really handy when it comes to UI controls, but, there is very little we can do when it comes to changes. What do accordions, tabs, and menus, have in common? They all behave similar way, and which is why most implementations have unordered-list - ul tag - as the skeleton.

Replacing list with radio buttons

Radio buttons are quite good for Single source of Truth concept. Meaning, in a group of radio buttons, only one radio button you can mark as checked, which is why it comes very handy in this scenario. You just have to prefix a radio button on each element - tabs in this case - to obtain the state of the selected item.

Note the for attribute in label tag that bounds to the specified radio button, and ofcoz, nobody likes to have a bullet holes next to captions so take it off with little bit of styling.

Toggle content when clicked

It's called General Sibling Combinator effect! Pay attention to this;

The elements represented by the two sequences share the same parent in the document tree and the element represented by the first sequence precedes (not necessarily immediately) the element represented by the second one. – w3.org

If you wonder what that means, the style is applied as long as the radio button and its corresponding content share the same parent DOM element, in this case, input and the article tags sharing same div as their parent.

For this selector to work in IE8 and earlier, a <!DOCTYPE> must be declared. – w3schools.com

Toggle content is nothing but to show the content - article tag - bound to the checked radio button and to hid the rest by setting the height to zero. You could also use the visibility attribute but height is more appropriate in here.

Pragmatic use of Sibling Combinator

What can you do with it? Just change the layout the way you want, decorate with some CSS, and you get an accordion. Accordion can be multiple expandable as well. In that case, make the radio button a checkbox.

code + demo: accordion with html5, css3, and no javascript code + demo: accordion with multiple expandable option, without javascript

Implementing an accordion is quite easy and it’s the boilerplate for the rest of the components, for instance tab control with vertical tabs. The trick is to split the captions from accordion and put it on aside, which is another reason to use the for attribute with some float:left.

code + demo: tab control with vertical tabs, with no javascript

Pay attention to the HTML layout on the vertical tabs. This can be used to demonstrate a traditional tab control with horizontal tabs, which you can simply turn into a horizontal menu with sub-menus, with minimum changes.

code + demo: horizontal menu with sub-menus, without javascript

More good resources on CSS Sibling, Label placement:

Stuff you can do with the Checkbox hack

Read about Sibling combinators in w3c

Focus input box when label clicked

Tips for creating great web forms

Label placement on forms

Comic credits to Dilbert.com

[kosalanuwan]

When the team hits lull in the sprint?

Excuse me for trying to fill a lull in the conversation

What would a scrum team do when they hits lull in the middle of a sprint? Do something small that has a value in it!

Lull is where the team manages to resolve all work items in the sprint backlog with zero bugs halfway through the sprint. You don’t see this very often!

It’s uncommon to find a lull moment for a scrum team, so, many try to get busy, occupying them leisurely. Several major avoid-if-possible things when the team hits lull in the sprint here:

a) Fixing bugs? It could be a juicy bug, probably not logged yet, but, it’s good to investigate first, and then pass it on proper channels/discussions to identify its source, severity, and the fix required. It could be a small bug, nearby, relevant to original bug, but, it could have planned to release in a later sprint/release.

Bugs that have lesser impact on users get less priority. The fixes are pushed to later sprints/releases.

b) Cleanup some smelly code? In my article called What’s wrong with my code, here’s what I said about smelly code;

Smelly code is a bitch. Do you think that’s because programming sucks or do you think it’s because working on other’s program sucks? For the record, not everybody sucks on programming but we don’t see good code either, as in no such thing called good code there.

As much as I hate to say; the probability of introducing more bugs in correlated code regions is quite high in this scenario. It doesn't add any value to customer. Unless there is a really good reason to rewrite or refactor, you better not touch already tested code.

Rewriting to improve performance, scalability, adapt new components/plugins are justifiable. Still, it’s just another prioritized work item for another sprint.

c) Taking more work items? Backlog could be prioritized with work items small in size, enough to fit in, but, bringing in more work items to the sprint can overcommit the team to an unsustainable pace. It can ruin productivity.

d) Start a new sprint? Though work is completed or not, sprints will continue to iterate in a constant pace, without any breaks/intervals/gaps in between, but, wait a minute! Software is not built by just resources; it’s built by people, your team.

A lull moment is too valuable to waste. It’s a good opportunity for your scrum team to step out and wander around for improvements. Few experiments-to-try when the team hits lull in the sprint here:

a) Let's go through issues! It’s always good to inspect any mistakes/patterns behind design issues and bugs so the team can discuss what requires adapting better approaches to produce more quality product in next release. Team can also inspect process issues. It can reduce engineering waste.

As scrum always says; To improve productivity, find the blocks and remove them. Inspect and Adapt! baby.

b) Let's write a cool plugin! Not all tools can get what cross-disciplined teams need, so, you still need to write in-house scripts to automate check-in, build, package, and to make processes smoother, and this is where dev teams come in handy. Besides, writing cool programs is what devs are really passionate about!

c) Let's learn new stuff! Boring is what devs always complaining after mingling for a while with same tech and skills. It’s too valuable to miss the opportunity to learn a new technology, a skill, a new language, attend for a trainee program, or prepare for a certification.

Being a professional is not easy. It’s good to read things related to career, be up-to-date, and maintain your Expert status.

d) Let's research! Research is often difficult to timebox and many scrum teams neglect after their project kickoff. It sounds awesome to do minor research work such as user feasibility, localization issues, platform compatibility and so on, that can bring value to project. Studying comprehensive data and process of the product to suite test scenarios can drop bug rate. It can also wow the Pigs and Chickens.

In scrum, the Scrum Team is called “Pigs”. Everyone else is a “Chicken”.

e) Let's write a white paper or a blog article! Every developer must have a blog. When else your team has time to leave footprints on what they do? It’s relatively fast and a huge morale boost for the team. White papers are always good to share ideas with others and can bring some respect to the authors.

Blogs, white papers, patents give a nice touch in professional community.

f) Let's work on pet projects! Every developer must have at least one pet project to do trial-and-error, fantasize on new technologies, frameworks, and even components that don’t ship in your Toolbox. Try a different programming language and a tool you desire.

Social coding is the new open source community. Github is good place to start wander around.

g) Let's do some initiatives! Team could be performing well and assembled with smarter people, but, initiative programs can further amplify their creativity and leadership skills. It’s a really good chance to be part of something bigger and it can bring some recognition to the initiator and the team.

In my current company, certain initiative programs were organized to cater even broader audience. Colombo Code Camp, SL Bar Camp, and the very latest program Interns’ Summit were among them.

h) Let's have lean coffee! No matter how many coffee breaks your team had, nothing beats Lean Coffee. It’s a good time to step out and think about other than work items. Share interests on career planning, work-life-balance, 7 habits, image building, time management, or even gifts for girlfriend, in a nutshell. Helps shake of the dull feeling and rethink.

Lean Coffee is a Kanban game to play during coffee time. All you need is sticky notes, marker pens, a board with 3 columns: Topics, In progress, and Done; and a pile of topics to chat.

More good resources on Agile/Scrum:

InsideOut, Scrum practitioners, Agile & lean software development on LinkedIn.com

Process & practices on InfoQ.com

Colombo agile meetup

Succeeding with agile by Mike Cohn

Project management in the real world by Elizabeth Harrin

Comic credits to Dilber.com

[kosalanuwan]

Co-locating distributed scrum teams

We're trying something called Agile Programming!

Several decades ago, the climax in a software company was moving towards agile methods removing bureaucracy that appears in occasionally leaving only the team with bunch of prioritized features waiting to burst out for the next shipment. Stir all the teams with the product owner to a room surrounded by whiteboards brings the best return on investment of a project. However, everybody being convinced on the need for diversified talents to move forward with pushed companies to broaden their horizons beyond borders resulting constant growth on outsource (and offshore) trend since late 90’s. Consequently distributed scrum teams lack efficiency and quality knocking out diligent teams for not being productive as when they were teamed up physically in a single room.

I have the worst case of jet lag ever. I’m still a baby in this time zone!

Work with a team in Elbonia while teaming up locally doesn’t digest well. If not, worse than tech-support for Dilbert’s mom over the phone to get her on Facebook. That sounded melodramatic to just set the real sensation for it. Thanks to contemptuous benefits of outsourcing agile has being more diversified and the teams are now being distributed. Three things to notice here: 1) People working in different time zones 2) Slipping productive hours 3) Disconnecting human interactions.

Once again, I’ve no idea what they want!

Working in different time zones also results slipping innumerous productive hours unnoticeably. The meetings are no longer impromptu. Planning and other scrum ceremonies keep delaying and deprioritizing rest of the work consequently. Discussions are more or less disconnected. Conversations are emailed believing it reduces waiting time and group interactions. In the meantime conclusive comments dragging for further round trips starting to increase stress levels paralyzing work across groups.

User experience is no longer in whiteboards and paper prototypes when teams are distributed. Scoping and coordinating cross-group dependencies are quite a challenge as well. They are emailed with lengthy specs followed by a sequel of phone calls explaining its behaviors and constraints pushing thresholds of frustration with lot of head banging on the wall.

Here is a picture of Thor, their field engineer!

Kudos to vendors who bought video conferencing and screen sharing tools that led cutting down many round trips of emails, IM’s, phone calls, and head banging too. Other than experimenting features, it comes very handy during design meetings and scrum ceremonies that requires physical interaction and brainstorming.

Thanks to JIRA emails are no longer carefully crafted. They are now moved to wiki conversations and pimped with user stories in backlog, code snippets from Gist, conversations on Yammer, and other intriguing plugins killing email clients. Meanwhile, working on a single feature limits the work-in-progress (WIP) isolating from teams being interdependent consequently reduced the cross-group interactions that can fit into a common time zone finally convinced everyone regarding the increase in quality of shipped features from end-to-end.

People only want real friends!

Whatever the future brings, social networks play a major role building something that will last: teams, tools, and the bond. The climactic moments and outbound experience during teams are now often shared in fan pages on Facebook giving opportunities for new conversations on Twitter and Yammer. These footprints on the social networks are essential to socially interacts distributed teams.

Though fascinating tools co-locate distributed teams, physical meet up that bond teams with human relationships are irreplaceable. Occasional visits to other distributed teams at least twice annually during appraisals and budgeting meetings; for training sessions and workshops; for couple of hardening sprints with planning poker; are wise choices to a long-lasting relationship. Billboards, live-size cutouts, and wall-hangings of teammates placed in meeting rooms, hallways, and lunch areas are quite effective to keep up the momentum of team bond.

More related quotes and stories from Dilbert.com:

Use agile programming methods

I'm outsourcing your job to India

You are in a different time zone, so you'll get the call in 3hrs

Email it to me, my day starts in 10hrs

I have the worst case of jet lag ever

My app does face recognition and search all social media

What were your key learnings from the trip?

[kosalanuwan]

Programming without social networks

What did the Oracle say? She said that I will find the one!

In 90’s, apprenticeship days were long. Coffee breaks were spent with very senior programmers who wore suites and old enough to retire. Every code was thoroughly reviewed in few tiers before it gets compiled. Emails exchanged were chapters long and most had answered with code snippets for a problem. Though daily standup meetings were held there were days spent troubleshooting errors scratching head. When none of us knew the answer to a problem the program manager left with a choice of shredding the story on the backlog.

If the Oracle doesn’t know then who would? Google?!

Programming a "file drag-n-drop" for a HTML5 app on a notepad without an internet connection is a good deal of experience for any programmer. Two things to notice here: 1) Use of a rich development environment even for a less complex task 2) Breath of social networks air for the knowledgebase. A simple text editor is not the right tool for this task and the documentation is no longer shipped on CDs. It is hosted on the World Wide Web (www) with many code snippets linked everywhere.

Thanks to sorcerers who bought Google, StackOverflow, Github, and many other social networks, scratching head is the last thing a programmer would do. Using free and open source libraries with better community support is one of the new additions to the agenda in technical forums. Other than hot coffees and cookies served in discussions, it was always favored to use such libraries with confidence than inventing the wheel again. If it wasn’t, a programmer’s life would have been long as 80’s.

"Google it" has become a habit to reply to find out reliable answers. That did mean programmers would eventually land on StackOverflow, which is a Q&A site where many programmers moderate answers for those questions asked by many other programmers.

Besides, it is not a sin to copy some code snippets from StackOverflow, Github, Gist, or from a blog post, tweak a bit, and ship it to production. It’s there for the same reason and programmers do it all the time.

[kosalanuwan]

How to get to the next level of programming?

It doesn't matter whether you do Java, or C++, or VB, or whatever. It doesn't matter whether you are a programmer, or a senior engineer or a techy. There are no recipes to write clean code. What developers these days need is hiking, and hiking again!

A full week of hiking and exploring

On a sunny Sunday, May 13th, after BCS lectures on Programming,  @sumusiriwardana and I thought of High Tea. While serving ourselves, she started an interesting topic about the need for software craftsmanship, clean code, etc.

@sumusiriwardana: Can you tell how to write beautiful code or clean code?

@kosalanuwan: A computer program is the most complicated thing on earth, second to the human brain, so, no one still knows how you write a computer program for some idea in the head using a programming language, but somehow you do it.

Isn’t that what developers do with SDLCs and ALMs?

Yes, SDLCs and ALMs can only help you up to a certain extent, it can streamline the process and narrow down some vague ideas into smaller chunk of diagrams and text, but still there is no such tool that could do the interpretation. So, you still have to interpret the program by your own. Some programmers are good at interpreting programs inside-out, and some interpret the same program the other way around, some write it top-bottom approach. None of these approaches are wrong.

But, software engineers want recipes, how do you say whether this code is clean or not? How do you identify it?

I know it when I see it! Another way to say, my gut says it’s clean, so I believe it. That’s how I know that this is beautifully written when I see it, when I read it. Maybe it’s the Styling. I mean, I am not a Roman that uses ALL CAPS with no punctuation. So, Styling and Case-ing can clearly express what the program is intend to do.

Anyways, I have to agree to disagree with prescriptive way of doing software development, writing beautiful clean code. That’s not the mindset a developer should have in software craftsmanship, there are principles, and there has to be ethics, disciplines, but not rules and steps as such.

What you meant by the mindset?

I believe that, with agile I don’t need prescriptions; I have to be disciplined, self-motivated, self-organized, a dedicated individual who writes beautiful code every time, and it’s quite good to do pair programming kind of thing during the apprenticeship, but I haven’t seen that in our software engineering community. I’ll tell you what’s there in the industry, there are 10+yrs of experienced senior engineers, and those 10+yrs is like 1yr, 10+ iterations - I cannot recall where I’ve heard this before.

Why pair programming is important when crafting beautiful code?

It says, two heads is always better than one. Pair programming is something you need in apprenticeship to journeyman to software craftsmanship. Now, developers can train their selves on this in Code Kata sessions - there are few articles compiled at #Alertbox on Code Kata session. Many have misunderstood pair programming and do it in a very expensive way. You have do pair programming like playing Ping-Pong, You write the Test, I write the Code, I write the Test, and now You write the Code. Also, there are some of the values to keep in mind when writing programs. Those values you can practice by your own, not just when pair programming.

What are those values to keep in mind when crafting?

Here’s what I would keep in mind when writing beautiful code:  a) Writing unit tests in Red-Green-Refactor approach   b) Minimizing coupling, maximizing cohesion, i.e. maintaining principles like SOC, and YAGNI   c) Avoiding duplicate code i.e. saying everything once-and-only-once, like DRY principle   d) Writing refactor-able code i.e. breaking down into small chunk of code like in SRP. Not following these disciplines is like Breach of Ethics.

But, then again, programs will be too complex to understand with all those principles, yes?

Nej nej nej! I call it how mature the developer is with principles. It's like hiking. You’ll be totally lost at first, the jungle is a stranger for you, but after many attempts, you’ll become familiar with it, you know every inch of it and eventually, taking a hike on this jungle is a piece of cake for you. A developer and design patterns has the same relationship. It says, practice is what makes you perfect, and Katas are good way to get there. When you are matured with these principles and patterns it will become difficult for you to think without those.

More readings on Clean Coding:

Colombo Code Camp

Code Retreat Sri Lanka

The pragmatic programmer: from journeyman to master by Andrew Hunt, David Thomas

Clean code: a handbook of agile software craftsmanship by Robert C. Martin

Clean coder: a code of conduct for professional programmers by Robert C. Martin

Comic credit to Dilbert.com

[kosalanuwan]

What Rules to follow in Code Kata?

Try to keep the code kata session as a social coding event. I didn’t find many rules, except followings;

There is no student in the session, everybody is leader.

Facilitator must arrange resources.

Sensei must find a problem to solve, an algorithm, for instance, John Conway’s Game of life.

Sensei circulates the problem among the rest (at least 1w prior).

Sensei asks questions, does not give answers but only guides through.

Sensei keeps track on pairing time (approx. 15min-20min).

Typist works with Guider when coding, Pair programmers do as advisors say.

All advisors must participate on the projected code, give ideas to pair programmers.

All advisors must have their turn in pair programming, coding, and help coding.

[kosalanuwan]

What are the Roles in Code Kata?

These are the roles I have seen in Code Kata;

A facilitator Have to make sure resources (in Step 1) are available and ready for the session, could be an advisor, but not the sensei.

A sensei Doesn’t sit with advisors, guides the session like a scrum master (important! there are no students in this session), timebox each pair programming session, to which pairs.

Pair programmers Only 2 programmers, sharing the IDE. Once a pair spent timeboxed period, typist moves to Guider’s seat, and a new advisor becomes a Typist.

Typist – The one who controls the IDE.

Guider – The one who guides the typist.

Advisors Observes the code, provide feedback, suggestions, comments, proposes the changes to do. Everyone gets to pair program at some point during the session.

[kosalanuwan]

How to: Code Kata in 5 easy steps?

In order to have a good Code Kata session, first, you are going to need resources, schedule, and execute the plan. So, here is what I can do for you. I’ll try to put things in very simple steps;

Step 1: Followings are the resources required for the session;

A meeting room This is where you will have the session. Pick a spacious place enough to have 10 +/- 2 people. Pick somewhere peaceful ‘coz the session gets a bit noisy.

A whiteboard This is to note down the problem, any ideas, discussion during the session.

A projector This is to show the IDE so that everybody can see what the pair programmers do with the problem.

Just ONE laptop This is to do the programming.

Step 2: Pick an algorithm or a small problem. Session is all about trying to write a program for an algorithm or trying to solve a problem by writing a program for it. Typically, Code Kata starts with Convey’s Game of Life. See more games on Cyber-Dojo.com

Step 3: Pick 10 +/- 2 members. Members include pair programmers, advisors, and the facilitator. Note that there has to be a sensei as well, and you can be that person. See Roles in Code Kata too.

Step 4: Schedule an appointment, invite to all with following details;

When? At least 1w or 2w prior to Scheduled date.

Whom? Members picked in Step 3.

Date & Place? Scheduled date, time, duration, and the place picked in Step 1.

Content? Problem, Roles and Rules in the session, and what to bring for the session.

The good part about this is; participants get little space to practice the algorithm and be prepared. We can synergize all these during the session. See Rules in Code Kata too.

Step 5: Happy pair programming!

[kosalanuwan]

User Experience (UX) is probably the most misunderstood job in our timeline?

UX boom is already here, so, the IT offshore industry will have to train at least 500,000 UX professionals within next 3-4 years to design suck-less products.

You don't know what "Important" means, do you?

If you know UX well enough, you know that (technically) the term designing UX (UXD) is wrong. It is wrong b’coz we cannot design the user or experience. Instead, we design the product, its features, and its delivery. There is a science behind this UX, but majority of BAs, graphic designers, UI engineers in the IT/BPO industry (as corporations, professionals, individuals) have confused UX with Visual Design.

For some reason, the passion for UX still remains with UI designers, so that’s a plus. Sadly, companies recruit UX professionals to get the UI design done, and also, the interview process and the selection criteria is same as UI designers’. Yes, this is chaos. Great design skills are not the key to great UX.

Knowledge is not the only key to being a great UX professional. To become a true UX specialist takes time. Probably tens of years of knowledge and experience, learning by designing, observing a wide range of users, tasks, devices, and platforms. Apart from all that, there have to be design principles, concepts, a design language, and iterative processes across multiple disciplines to have a success on it's delivery. This is why UX is not just one-man’s job, and clearly, not even one-step process or discipline!

More readings for re-imagining UX:

More accurate definition for UX by Nielsen Norman Group

Interaction design encyclopedia (online)

Sketching user experiences: the workbook by Bill Buxton

Sketching user experiences: getting the design right and the right design by Bill Buxton

Don't make me think by Steve Krug

Don't make me click by Aza Raskin (video)

More articles on UX by UXMag.com (online)

Comic credits to Dilbert.com

[kosalanuwan]

How do you know which Design Pattern to use? I don’t know how, I just know it!

Design Patterns, the book of firsts that doctrine for programmers’ bible of patterns. It’s the book of firsts that describes 20+ software design patterns by the Gang of Four. Also, the book of firsts that explains software design patterns from pseudo-code to real-world examples with many modern programming languages. I did enjoy all that. Sad, for the textbook compiled to many design patterns interpreted to code snippets, the majority of novice programmers would accept as confusicult, blending on the design and implementation of agile architectures. No. Design patterns are not something that I would use without principles.

Confusicult is something that is hard, confusing, and very difficult to digest

Uncle Bob’s Clean Code is the doctrine for seasoned developers’ bible of software craftsmanship. I felt that, Robert C. Martin formulates pragmatic advice ripples with SOLID disciplines for most smells and heuristics that can be found in real-world. But then, let’s accept, even a genius cannot come forth with the best design, but a well-crafted program that is compact, clean, and refactor-able. The simple or rather fundamental steps to this well-crafted programs, is to write a few specifications, apply few design principles, refactor a little bit, rename variables, rename methods, move code blocks here and there, and put them into another class, so on and so forth. Inevitably, this brings few design principles and patterns in to programming.

As every other seasoned developers, I too enjoy all that work of a craftsman, making it work first and then making it right to keep the programs small, simple, and clean. What patterns, or rather interesting design principles to practice when crafting software? Demonstrating Pattern-based Engineering in a Clean Architecture, branches into many aspects of Software Craftsmanship, from Coding patterns to Architectural patterns to Analysis patterns.

Fast guy in tights and a movie about coffee

In real-life, novice programmers can wish to formulate these programs as complex and over-engineered, for themselves. No. Their cynical habit of slipping through refactoring disciplines, not making the programs right, leaving the working programs in whatever state they finally got it working, is no longer a recipe of Clean Code but of a world-class lasagna. There is nothing unusual about the relationship with this developer’s dilemma and hiking in a mysterious jungle. What does the finding way out has to do with this? Relationships, dependencies, roles, and perhaps, familiarity. Despite the concepts of SOC, and YAGNI, it all falls into very same principles of SRP and DRY keeping the programs small, separated, maintainable, and scalable.

The curse of the knowledge is that once learned and understood, it imprints, making impossible to unlearn. In fact, I would not know how I would program without the knowledge of employing any patterns. Thus, crafting software to patterns and principles is no longer a unicorn or the back door to heaven, but a bitch, I feel.

More useful resources about coding to patterns:

Design patterns: elements of reusable object-oriented software by GoF

Agile principles, patterns, and practices in C# by Robert C. Martin

Refactoring to Patterns by Joshua Kerievsky

Patterns of Enterprise Application Architecture by Martin Fowler

Clean code: a handbook of agile software craftsmanship by Robert C. Martin

Comic credit to Dilbert.com

[kosalanuwan]

Don't ask for anything that you don't need

Originally, this was a tech talk - Why certain code is hard to test? - I did for my colleagues during my stay at exilesoft.

Why certain things make code really hard to test? Source code is full of objects and that is where you write the business logic, domain abstraction, and probably the place where you can find most of the bugs. In order to test, first we nee to instantiate the Document, that's obvious.

https://gist.github.com/kosalanuwan/c5aa14362200e96655a6

The code looks clean and readable but how would I test this? I can setup a test system and write a spike as for my unit test methods and we are good to go. Well, good luck testing it.

Mixing construction with work is not a good idea, so, I can use a Factory or a Builder to construct the HtmlClient. If not, I can simply forget construction and ask for HtmlClient instance as an input argument. Ever heard of SRP (Single Responsibility Principle)?

https://gist.github.com/kosalanuwan/44db9b79e984668af987

The constructor now doesn't care how or who creates the HtmlClient. All I have to do is to simply mock the HtmlClient and get rid of the spikes and the test server. Testable but not good enough, I still have to mock HtmlClient whenever I need a Document instance.

Mocking HtmlClient everywhere is still a pain in my unit test and I fear it become smelly, so, I am going to go ahead and use Build-Operator-Check pattern in my unit tests. Ever heard of DRY (Don’t Repeat Yourself)?

However, passing HtmlClient to get the content doesn't feel right here. I still have to look at the Document constructor to see the methods I need to override. Makes sense because we are using HtmlClient only to get the Content. I should ask for Content instead of the HtmlClient so the constructor becomes more simplified and the tests become much cleaner. Ever heard of YAGNI (You Ain't Gonna Need It)?

https://gist.github.com/kosalanuwan/bbf5c6c3a8f8441d9a3e

In real world this is pretty much similar to Writing Shy Code a.k.a. Transitive Navigation; a module should know only its direct dependencies, Law of the Demeter; asking for something you don’t need directly only to get what you really want.

[kosalanuwan]

What’s wrong with my code?

Few years back, on Christmas eve 2001, Prashantha De Mel, my Senior Program Manager had the idea of going through the code and see how many WTFs we get. Perfect timing, he is about to give some key ingredients.

Smelly code is a bitch. Do you think that’s because programming sucks or do you think it’s because working on other’s program sucks? For the record, not everybody sucks on programming but we don’t see good code either, as in no such thing called good code there. Catch-22.

The truth is it’s not that hard to write code but it takes time to get the idea of readable code. It needs to redraft like a newspaper article. I’m still getting used to it; I’m not going to lie.

First up is “Encapsulating Conditionals” and looking at a logical expression used in If/Else. It makes you do the processing and understand the result while reading the expression, say, doing the math in your mind for a formula. First thing we are going to need is a name, so I can hide the formula within a method and use the method instead. Let the refactoring begin.

Next is “Avoiding Negative Conditionals”. They are also like encapsulating conditionals but apply for NOT expressions, say, collection is empty expression to check not empty. All I need to do is to wrap the not operator plus the method I wrote to encapsulate condition with another method. Excellent, moving right along.

“Encapsulating Boundary Conditions” is even easier and it gives me some –ilities, so I have to look for any +1s or -1s and move it to a separate variable or hide it within a method. Kids’ stuff.

“Polymorphic If/Else or Switch/Case” is not straightforward but unfortunately code contains same If/Else and Switch/Case statements in several places. Poor re-usability, have to admit. I have to wrap this with a Factory, Visitor, or Specification pattern and replace other duplicate code with objects to get things done. They call it “One Switch”, and cleaning up the rest is not as easy as I thought. Coffee break.

Next is “Transitive Navigation”. The code may look readable to me but it made me write more code to get the work done, as in any encapsulation there. “Shy Code”, bad design practice. Unfortunately, I should know only my direct dependencies, so I’m going to have to hide the method calls in later steps within methods in higher steps or split into smaller method calls.

“Too Many Arguments” have added too much behavior to method, so I’m going to have to group those arguments into dedicated class or I have to replace the parameters with independent methods. Perfect, moving right along.

“Avoiding Duplication” is not as easy as it says and certainly violates DRY principle.  Data layer has violated DRY principle than any other layer, so a little Materializer and Specification magic is all that is necessary to get rid of the duplicate code in DAOs.

“Say What They Do” in a method is easy when naming the method after we implement it. Makes sense because some methods do have ambiguous names, so I need to rename those methods respectively.

Methods should be “Small Enough To Do One Thing Only”. Methods here certainly violates SRP, say, doing more than one thing and some are bit lengthy, so a little Extract Method and Split Loop is all that is necessary to start refactoring these methods to make them do one thing.

“Separating Command Query” is quite a challenge, because it not only changes my method signatures but also changes the design slightly, say, return latest data after persisting. I can use an Extract Method approach and let client decide command or query.

Try to “Avoid Comments”. Unfortunately, this class contains lot of comments and I’m going to go ahead and say that the author wasn’t sure about the code been written, so little bit of comment must have satisfied. I’m going to delete these comments because it’s outdated, misleading, dead, and now the code itself explains the work.

[kosalanuwan]

If you don’t appear on Google Search Result, you don’t Exist

Originally, this was a talk - If you don't appear on Google - I did as part of Industry Awareness Program for students from University of Moratuwa during their visit to exilesoft.

Many grade-schoolers (especially in Computer/IT) wish to become Good Software Engineers. Sadly, we don’t get to meet the Oracle to seek guidance, no way to upload knowledgeable programs directly into our brain, and no Keymaker to lead us safely to our destination.

Unless you are an exceptionally passionate character like Steve Jobs or Mark Zuckerberg, having a well-polished CV might not be sufficient to make your dream job a success.

Tip 6

Choose a career path, a profession

Software Engineering, Project Management, Business Analysis are not the only profession jobs available. The cloud has few professions, jobs, career paths available in the industry. Choose wisely what you want to become. Anchor it, specialize it, make sure not to change it halfway through since many grade-schoolers make this mistake.

Tip 5

Get familiar with few technologies, principles, practices, and methodologies

.NET, Java, and Php aren’t the only jargon found in the industry. The cloud has few technologies, principles, practices, and methodologies available in the industry. Pick few things that you may interest and align with your chosen career path. Play around, do some research, and most importantly, get hold onto it (at least) for next few decades.

Tip 4

Write articles, blog posts, online (professional) journals, and seminars

Grade-schoolers and freshmen don’t have many things to demonstrate except their academics. Register your name and start blogging. It is one of the cheapest ways you can demonstrate your expertise. Your audience will be worldwide. Volunteer to speak at seminars (even during your academia). It helps your presentation skills and to build your image. Repeat your message since it takes time to build a reputation as an expert.

Tip 3

Create few public profiles and start leveraging your existing network

Having a public profile under your name is important. Make sure to register it before someone else does. Many forget the idea of Social-networking and Professional-networking. Professional networks such as LinkedIn and BranchOut have a higher rank in search results. Connect your public profiles with your blogs and vice versa. Remove irrelevant details that doesn’t support or weakening your message. Remember to maintain and keep it up-to-date. It takes time to build your personal branding. Therefore, be patience and don’t expect instance success.

Tip 2

Keep yourself up-to-date with technologies, methodologies, and practices

Being a Professional is not that easy. Many grade-schoolers lose their passion after graduated. Many freshmen lose their interests on what they do. Many forget their goals. Specialize on one or two things you do. Do few certifications and keep improving yourself. Try to make things work first, and then make it right. Maintain your “Expert” status is very important.

Tip 1

Start reading texts relevant for your career path chosen

Sadly, many grade-schoolers don’t even know the recommended textbooks of their academia. Many freshmen focus only on technology stack. Sign up on Goodreads and participate on Goodreads Challenge. Read at least 12 books per year.

[kosalanuwan]

Lazy developer's test strategies reduce bug count

Let me be clear! The bugs count tends to increase of a smart developer than a lazy developer. It is sad, but true.

Great developers who are Smart and get things Done moves very fast in early sprints of a project. The more industry experience they get, the smarter they become.

How long will it take to fix the bugs?

Apparently, the code that was written quickly appears to have more bugs. The changes they make to the codebase keeps breaking the build more often. Over time the bugs list becomes bigger and piled up at the end of each sprint. Every bug they fix keeps introducing two or more new bugs.

Let me be clear on one more thing! There is no set of practices that can replace experience. A lazy developer will spend more time when writing a piece of code following the practice of simple design that adheres to good principles and patterns.

Use of Coverage Tool

Smart developers do not like to test their programs simply because they are intelligent enough to write code that works. This is professional suicide, if not worse than, chaos. What it differs from lazy is that, a lazy developer uses a Coverage Tool to check gaps in the test strategy. This gives a visual indication, marking modules, classes, and functions that are insufficiently tested.

One Step Testing

Smart developers like complicated things, even when testing. It makes them feel intelligent and important in the team. After few laps, this makes the team moves at a snail’s speed. As a result, test strategies will require more than One Step to test modules, classes, and functions. The idea of being lazy is to have a test strategy that should be quick, easy, and obvious to do.

Don't skip Testing

Writing tests is huge. You have to change your tests when the production code changes. Your tests get evolved when you add more modules to production code. Eventually, maintaining the test suit becomes the biggest complaint among Smart developers. What lazy developer understands is that, with No Tests, the team cannot ensure that changes to one part will not break other parts of the system. The team cannot ensure that their changes to the code will work as expected.

Use Patterns and Conventions

Readability is more important in test code than production code. Most smart developers don’t follow this advice. Consequently, test code becomes a liability. Lazy developers say a lot in few expressions using a Domain-Specific Test Language such as BDD.

Arrange-Act-Assert Pattern

The test is much improved and easier to read when test code is split into three sections;

Initialization and mocking is under Arrange section

Method is being executed is under Act section, and

Outcome of the test is under Assert section.

https://gist.github.com/kosalanuwan/430c526eec45e5a8adab

Single Assertion Pattern

The easiest way to improve readability is to reduce the number of asserts in a test. This pattern limits it to One Assert per test.

https://gist.github.com/kosalanuwan/0ff5876cba0c241e61eb

Build-Operator-Check Pattern

The pattern made similar to AAA pattern. Each test is split into three parts and yield expected results. Notice that the tests are written as Domain-Specific Testing Language.

https://gist.github.com/kosalanuwan/2143351f937e148e247f

Given-When-Then Concept

The most appropriate rule is to use Single Concept per Test. This is a convention than a pattern that uses Gherkin, an ubiquitous language (of DDD) when writing tests. The test methods are called specifications of system behavior.

https://gist.github.com/kosalanuwan/481bb68f704e9a50bccf

Do Experimental Tests

Understanding third-party components is hard as integrating it with production code. Smart developers spend few days reading the documentation and deciding how this can be used and apply to code base. Consequently, all the experimenting, trying out new stuff, and long debugging sessions will start to smell in production code. Instead, lazy developers write Learning Tests and Boundary Tests exploring how and what we want out of the third-party components.