:: Ashesh R - Blog :: » Software Engineering

Managing Humans…

Ashesh — Mon, 03 Aug 2009 13:05:29 +0000

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.”

Posted in Geek Stuff, Human Resources, Management, Practical Training 2009, Software Engineering, That's Life!

Our ‘Littoul’ Software Team

Ashesh — Sat, 25 Apr 2009 17:00:36 +0000

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: VB.net coding & Crystal Reports

Member 2: VB.net 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.

Conclusion

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

Posted in Geek Stuff, Software Engineering, Uni Student Life, University of Mauritius Tagged: Computing, University of Mauritius

Test-Driven Development at UoM

Ashesh — Tue, 03 Mar 2009 17:32:30 +0000

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). http://en.wikipedia.org/wiki/Test_driven_development

Another interesting article on the subject matter can be found here: http://www.onlined.org/papers/000145.pdf. 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: http://web-cat.cs.vt.edu/WCWiki/WhatIsWebCat

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.

Posted in Geek Stuff, Java, Review, Software Engineering, Uni Student Life, University of Mauritius Tagged: Computing, corporate, Education, Open Source, University of Mauritius

Process Models

Ashesh — Tue, 17 Feb 2009 15:31:16 +0000

A nice presentation on Agile Methodologies and Extreme Programming. The “How it works” section is useful! Thanks Utkarsh.

Another presentation on eXtreme Programming. I really appreciate the pictures of Pair Programming. It gives a really good idea of the concept.

This one on UML

A very interesting presentation on Use Case Diagram

This one on Activity Diagram.

For the lab session, I tried to draw the activity diagram on ArgoUML, and I must admit that ArgoUML rocks! Give it a try, you won’t be disappointed

Posted in British Computer Society, critical thinking, Geek Stuff, Software Engineering, Uni Student Life Tagged: Computing

UML CASE Tools

Ashesh — Tue, 03 Feb 2009 05:20:44 +0000

Today I am going to do presentation for the Software Engineering class at the University. Ahem Ahem. a bit tensed, but no…..lets remain cool as usual. Eihhhhh the slides are not ready yet and I am completing them now. So as soon finished, will upload them and share it to the Software Engineering community on my blog, via slideshare. Keep connected till then!

A major update:

I’ve just uploaded the powerpoint presentation on Slideshare!

How was my presentation? please vote:

Am hyper happy and relieved too. I was not nervous during the presentation. Just wanna say the stuff I couldnot before class:

Firstly I would like to thank our lecturer for giving us the opportunity to enhance our communication skills as IT professionals/ Professional Software Engineers. Yesterday I attended the Prize Giving Ceremony for ACM programming contest. It was a quiet observation to make that the cse student who did his speech before his audience maybe did not bother to look at his audience and talk with them. He was just reading his paper. Communication Skills, maybe he lacked that. Of course, it was a lecture theatre very full and Journalists, MBC TV camera, respected lecturers, people from Accenture, Hot atmosphere na!!!!!

If that guy had the opportunity to talk before the class, just as we are having the opportunity to talk in the Software Engineering class, maybe his speech would had been more interesting, with his touch of charisma in his speaking style.

Concerning my presentation today, that was simply unexpected. I was tensed because of the so much slides to talk on (exceeding 3 minutes even). I was not sure of myself because of the quite good number of students present in ELT 2 – Engineering Tower, for the first time speaking before such a big number of computer students,phewwwwwwwwww. I took a deep breath, talk with the beautiful gurl who was to present with me also, and mustered confidence and set of f to talk, talk and talk. I even talked in creole (li chien – Gimp, peingouin), hindi (“paisa” – meaning money), french (“bracquer la banque pour pouvoir payer IBM Rational Rose)!

Today marks one of my coolest presentation I have ever made. I would like to receive feedback on my style of presention and the design of the slides, and how was it overall? Thanks…

Posted in Geek Stuff, Java, Software Engineering, Uni Student Life, University of Mauritius Tagged: Computing, Open Source, University of Mauritius

The Software Crisis

Ashesh — Mon, 26 Jan 2009 10:21:59 +0000

Aim: To explain the background of the software crisis and the need for an engineering approach.

When projects became too big and complicated to easily maintain, the “software crisis” was born, with programmers saying, “We can’t get projects done, and if we can, they’re too expensive!”

Source: Bruce Eckel, Thinking in C++

[The major cause of the software crisis is] that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.

– Edsger Dijkstra, The Humble Programmer

The causes of the software crisis were linked to the overall complexity of the software process and the relative immaturity of software engineering as a profession. The crisis manifested itself in several ways:

Projects running over-budget.
Projects running over-time.
Software was very inefficient.
Software was of low quality.
Software often did not meet requirements.
Projects were unmanageable and code difficult to maintain.
Software was never delivered.

The most visible symptoms of the software crisis are
- Late delivery, over budget
- Product does not meet specified requirements
- Inadequate documentation
Some observations on the software crisis
- “A malady that has carried on this long must be called normal” (Booch, p.
- Software system requirements are moving targets
- There may not be enough good developers around to create all the new software that users need
- A significant portion of developers’ time must often be dedicated to the maintenance or preservation of geriatric software

From Wikipedia,

1965 to 1985: The software crisis

Software engineering was spurred by the so-called software crisis of the 1960s, 1970s, and 1980s, which identified many of the problems of software development. Many software projects ran over budget and schedule. Some projects caused property damage. A few projects caused loss of life. The software crisis was originally defined in terms of productivity, but evolved to emphasize quality. Some used the term software crisis to refer to their inability to hire enough qualified programmers.

Cost and Budget Overruns: The OS/360 operating system was a classic example. This decade-long^{[citation needed]} project from the 1960s eventually produced one of the most complex software systems at the time. OS/360 was one of the first large (1000 programmers^{[citation needed]}) software projects. Fred Brooks claims in The Mythical Man Month that he made a multi-million dollar mistake of not developing a coherent architecture before starting development.
Property Damage: Software defects can cause property damage. Poor software security allows hackers to steal identities, costing time, money, and reputations.
Life and Death: Software defects can kill. Some embedded systems used in radiotherapy machines failed so catastrophically that they administered lethal doses of radiation to patients. The most famous of these failures is the Therac 25 incident.

Therac 25 incident:

Researchers who investigated the accidents found several contributing causes. These included the following institutional causes:

AECL did not have the software code independently reviewed.
AECL did not consider the design of the software during its assessment of how the machine might produce the desired results and what failure modes existed. These form parts of the general techniques known as reliability modeling and risk management.
The system noticed that something was wrong and halted the X-ray beam, but merely displayed the word “MALFUNCTION” followed by a number from 1 to 64. The user manual did not explain or even address the error codes, so the operator pressed the P key to override the warning and proceed anyway.
AECL personnel, as well as machine operators, initially did not believe complaints. This was likely due to overconfidence.^[3]
AECL had never tested the Therac-25 with the combination of software and hardware until it was assembled at the hospital.

The researchers also found several engineering issues:

The failure only occurred when a particular nonstandard sequence of keystrokes was entered on the VT-100 terminal which controlled the PDP-11 computer: an “X” to (erroneously) select 25MV photon mode followed by “cursor up”, “E” to (correctly) select 25 MeV Electron mode, then “Enter”. This sequence of keystrokes was improbable, and so the problem did not occur very often and went unnoticed for a long time.^[2]
The design did not have any hardware interlocks to prevent the electron-beam from operating in its high-energy mode without the target in place.
The engineer had reused software from older models. These models had hardware interlocks that masked their software defects. Those hardware safeties had no way of reporting that they had been triggered, so there was no indication of the existence of faulty software commands.
The hardware provided no way for the software to verify that sensors were working correctly (see open-loop controller). The table-position system was the first implicated in Therac-25’s failures; the manufacturer revised it with redundant switches to cross-check their operation.
The equipment control task did not properly synchronize with the operator interface task, so that race conditions occurred if the operator changed the setup too quickly. This was missed during testing, since it took some practice before operators were able to work quickly enough for the problem to occur.
The software set a flag variable by incrementing it. Occasionally an arithmetic overflow occurred, causing the software to bypass safety checks.

Peter G. Neumann has kept a contemporary list of software problems and disasters.^[2] The software crisis has been slowly fizzling out, because it is unrealistic to remain in crisis mode for more than 20 years. SEs are accepting that the problems of SE are truly difficult and only hard work over many decades can solve them.

More reading: http://www.unt.edu/benchmarks/archives/1999/july99/crisis.htm

Posted in Nerd Stuff, Software Engineering Tagged: Computing

Software Project Failures

Ashesh — Thu, 22 Jan 2009 16:22:50 +0000

Can you hear me there at the back? Ok….

Welcome to the second semester of the module : CSE 2001 Software Engineering.

It was with these words that the kickoff of the module was given. It was nice to be back again in the most important module in Computer Science & Engineering course.

The first session was hyper interesting with promises of personalities in the Software Industry (Accenture, Ceridian etc) coming to give guest lectures during the semester. Software Engineering Principles and Practices would be different from what has been done in the first semester i.e OO (OOA, OOD, OOP – Java).

As an encouragement to increase our communication skills, we are supposed to talk before the class on a topic chosen by our lecturer. This time the topic is: Software Project Failures.

To start with, here is a very interesting link from my favourite blog codinghorror: http://www.codinghorror.com/blog/archives/000588.html

Agreed that our lecturer’s examples of software project failures were mostly on aviation related (NASA Mars orbitter, Air Traffic controller), we have to look for failure and its impact in other industry as well. n’est-ce pas?

Posted in Nerd Stuff, Software Engineering, Uni Student Life, University of Mauritius Tagged: Computing, University of Mauritius