Theatre & Films Productions

Software Engineering

Managing Humans…

An interesting read from the book: Managing Humans: Biting and Humorous Tales of a Software Engineering Manager

Here is a Book Review and Here is a Google Preview of the book. Managing Humans is a selection of the best essays from Michael Lopps web site, Rands In Repose. Drawing on Lopp’s management experiences at Apple, Netscape, Symantec, and Borland, this book is full of stories based on companies in the Silicon Valley where people have been known to yell at each other. It is a place full of dysfunctional bright people who are in an incredible hurry to find the next big thing so they can strike it rich and then do it all over again. Among these people are managers, a strange breed of people who through a mystical organizational ritual have been given power over your future and your bank account. Whether you’re an aspiring manager, a current manager, or just wondering what the heck a manager does all day, there is a story in this book that will speak to you. You will learn:

  • What to do when people start yelling at each other
  • How to perform a diving save when the best engineer insists on resigning
  • How to say “No” to the person who signs your paycheck

Among fans of Michael Lopp is the incomparable Joel Spolsky, cofounder and CEO of Fog Creek Software:

“What you’re holding in your hands in by far the most brilliant book about managing software teams you’re ever going to find”.

This book is designed for managers and would-be managers staring at the role of a manager wondering why they would ever leave the safe world of bits and bites for the messy world of managing humans. The book covers handling conflict, managing wildly differing personality types, infusing innovation into insane product schedules, and figuring out how to build a lasting and useful engineering The Author: To read more of Michael Lopp try his Blog or follow @rands on Twitter. Some of my favourite quotes from the book:

A manager’s job is to take what skills they have, the ones that got them promoted, and figure out how to make them scale. They do this by building a team that accentuates their strengths and, more importantly, reinforces where they are weak. Managers who don’t have a plan to regularly talk to everyone on their team are deluded. Ideas will not be discovered, talent will be ignored, and the team will slowly begin to believe what they think does not matter.


Real work is visible action managers take to support their particular vision for their organisation. The question you need to answer for your manager is simple: does he do what he says he’s going to do? Does he make something happen? The CEO in question is not a prick. Good guy. Straight talker. Good financial sense. Many failing companies did a lot worse than ours, but that isn’t the point. The reason we sat there drunk and uncomfortable was because we had absolutely no connection with this guy. He was the mechanical CEO.

My definition of a great manager is someone with whom you can make a connection no matter where you sit in the organization chart. What exactly I mean by connection varies wildly by who you are and what you want and, yes, that means great managers have to work terribly hard to see the subtle differences in each of the people working for them. Meanwhile, you need to constantly assess your colleagues, determine what they need, and figure out what motivates them. You need to remember that what worked one day as a motivational technique will backfire in two months because human beings are confusing, erratic, and emotional. In order to manage human beings in the moment, you’ve got to be one.

A successful organization is built of layers of people that are glued together with managers. Each layer is responsible for a broad task, be it engineering or QA or marketing. Between each layer is a manager whose job it is to translate from one layer to the next . . . in both directions. He knows what his employees want. He knows what his manager wants, and he’s able to successfully navigate when those wants differ.

Management is chess. When you’re presented with a problem, you sometimes need to sit back and take a look at the board, figure out the consequences of each of move, and, most importantly, pick a move. In my experience, the move and how you pick it does not involve 48 laws, it’s only 3 words: subtlety, subterfuge, and silence. Managers lead, and a lot of managers translate that into “managers lead by talking.” Combined with the tendency of employees to not say no to these managers, you can see why a lot of us have turned into professional windbags. We think we’re guiding you by filling the air with our thoughts. There’s a time and place for that, but in order to fill the air with something relevant, you’ve got to gather and process data. In silence, you can assess.


Managers are hubs of communication. The better they communicate across these sphere boundaries, the more people they can communicate with, and the more data they have, which consequently leads to better decision-making. Ultimately, stronger communicators make more informed decisions, and hopefully are more successful because they waste less time wondering what to do. How you will be judged as a manager by your team is based on how you communicate with them. That’s not just taking the time to have that quarterly all-hands, it’s understanding what they need to hear and being able to say it in a way they’ll understand.

When I see a new manager fall back to coding, I tell the manager, “I know you can code. The question is, can you manage? You’re no longer responsible for yourself, you’re responsible for the team, and I want to see you figure out how to get the team to solve this problem without you coding. Your job is to figure out how to get yourself to scale. I want lots of you, not just one.”

Our ‘Littoul’ Software Team

For the Yearly module Structured Systems Development, we have to present software demo which assesses our understanding of the concepts taught in the lectures and practical experience in the labs. The criteria used for the demo are:

  • Proper running of system
  • User friendliness
  • Types of controls used other than textbok and buttons
  • Proper Validation
  • Reports
  • Outstanding functionalities like splash screen and progress bar

The emphasis was clearly on Proper running of the system (correct manipulation of data, handling of errors, correct link between different forms etc.).

After 1 week of hard work (nearly min three hours everyday to 6 hours on the project), our ‘Littoul Souftware Team’ gave birth the much awaited masterpiece:

So the big question: How was the development in Team experience?

Personally for me, this was a unique opportunity for software development in Team. The tasks had been distributed as:

Member 1: coding & Crystal Reports

Member 2: Validation coding and Testing

Member 3: Database administrator & Documentation

Honestly, with each member determined and willing to give his best for the project, the Team experience was great!

Coding Horror has an interesting article on: “In Programming, One is the Loneliest Number“. As a lonesome programmer, the Internet is your only friend. MSDN Forums and Google Search are your source of programming knowledge on the internet. You wait when desperately you get a reply to a problem which you cannot solve. However here’s the key point:

What good are nifty coding tricks if you can’t show them off to anyone? How can you possibly learn the craft without being exposed to other programmers with different ideas, different approaches, and different skillsets? Who will review your code and tell you when there’s an easier approach you didn’t see?

Now in the reactions of the post, we read arguments for working alone on software projects but honestly I prefer to work in a team where I can learn and share the joy of crafting software. But then, we would need to have team of freelancers? euhh, decent freelance programmer, if you interested to work collaboratively on projects, let’s keep in touch!

Egoless Programming

Another event to highlight from the presentation experience is: you are presenting before a lecturer who will thoroughly analyse you work and will ask you questions even much in a much more advanced way than a lawyer trying to counter-argue the defendant. Well, my way of handling the situation was ‘Ok we have a bug here, we think we need to add an equal to to make it work’ i.e no arguing to try to convince that you have not make mistakes, to admit that you have not used other SQL Like statements etc. Here’s another quote from “The Ten Commandment of Egoless Programming“:

You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.


It has been a pleasure and honour to form part of “The Littoul Software Team”. Online collaboration and communication technologies has permitted us to equally share the load of work in a time where there are other assignments and exams revision coming. It feels nice to having formed part of another winning-team!

Coming together is a beginning, staying together is progress,
and working together is success,”
– Henry Ford

Test-Driven Development at UoM

Today when I took a glance at ELT2 door’s, I was shocked. Our usual lecturer was being replaced by an American guy. He had an Apple computer. Honestly I was about to not enter the lecture theater and phone a friend to confirm that the class has been postponed. 😀

Upon entering the class, Prof. Brandon, if I am not mistaken was explaining on Test Driven Development (TDD).

Another interesting article on the subject matter can be found here: According to the article, test driven development is proposed in the classroom. An automated grading  strategy is used to assess student-written code and student-written tests together, providing clear and immediate feedback to students about the effectiveness and validity of their testing. This is achieved by webCAT – the Web-based Center for Automated Testing. Web-CAT is a plug-in-based web application that supports electronic submission and automated grading of programming assignments. The Web-CAT Grader supports traditional models of automated program grading, but also supports grading of assignments where students do their own testing. It helps encourage test-driven development (also called test-first coding), where students write small unit tests for each piece of code they add. Web-CAT allows a student to submit his or her test cases along with the solution, and grades on test validity and test completeness as well as code correctness. More info on webCAT here:

The professor then continued with another presentation on webCAT, its functionalities. The Web-CAT Grader uses a web interface for student submissions and for reporting. The feedback provided to students was inspired by JUnit’s GUI TestRunner.

Then professor proceeded with JUnit and Java Doc. The presentation was hyper interesting.

Here’s an interesting video also : Extreme Test-Driven Development with UNA (Java)

Some questions followed by the software engineering community on 1: JUnit plugin on Eclipse and 2) the coverage of the our written code by webCAT

Prof. answered accordingly.

My favourite quote is: “Happiness in Programming!”

webCAT is a new feature at UoM. The lecturers at the CSE dept. are still experimenting with it. Our software engineering lecturer intends to give an assignment using the new system. No hardcopy to be submitted. Everything online and results also obtained instantly. The pending work is the creation of student accounts with their respective IDs.

Well let’s hope that this innovative feature at UoM brings us a unique experience as future software developers. Thanks CSE dept. for this great initiative and giving Computer Science students such a unique opportunity.