Tag: project management

Take the “Smart” out of Work

Starting the post with “When I was a kid…” sounded proper until I realized this is the typical incipit of elder people talking about something that wasn’t around when they were youngsters. So I convinced myself to find an alternative incipit, but yeah, when I was young no one ever dreamed of working at home, the cave was where rocks and pebbles were and you had to fight your way with saber tooth tigers, wild mammoths, and velociraptors to get there.

The idea of remote working is not new. It gained popularity during the pandemic in the years 2020-2021, but it was already widespread in the technologically advanced industry. Once all your work is done on a computer, thanks to the innovative (but now more than 60 years old) idea of connecting a computer together at a distance – you may do your job anywhere a computer and an Internet connection are available.

Continue reading “Take the “Smart” out of Work”

Unidiomatic Solutions and Technical Debt

Jung’s Synchronicity theory is as fascinating as unscientific. It is “unscientific” because it can’t be proven false by its very own definition – two events appear to be related even if the causal relation is missing. Someone talks about dreaming of a Golden Scarab and suddenly a Golden Scarab hits your window. There is no apparent causal relationship, yet the event pair is so unlikely that the Synchronicity idea has been developed around this. My rational mind is more inclined in thinking of this as a selection bias (countless times it happens something like – you spend a few days away in a city and suddenly the news is filled with stories about this city). Nonetheless, when it happens I always feel uneasy, like the Universe would like to have a word with me.

So when I read the tweet below, by Mario Fusco, in a quite specific job timeframe, I felt called out

Tweet by Mario Fusco

In my whole professional career, I always tried to push the boundaries of the language(s) I was using, from assembly to C++, to achieve better engineering, more robust and safer code, fewer bug opportunities, simpler development, and improved collaboration. This meant sometimes introducing the latest C++ standard, sometimes introducing concepts from other languages and sometimes defining DSL with the help of the preprocessor. So I am not new to some raise of eyebrows when people look at my code.

Continue reading “Unidiomatic Solutions and Technical Debt”

button down -> light on

Picture this project – you have a battery operated gizmo with LEDs that has to light up at a given time and light off at another one. Reality is a bit more complex than this, but not that much.

So what could possibly go wrong? How much could cost the development of its firmware?

The difficult may seem on par with “press button – light on”.

As usual devil is in the details.

Let’s take just a component from the whole. If it is battery operated you need to assess quite precisely the charge of the battery, after all – it is expected to do one thing and it is expected to do it reliably. The battery charger chip (fuel gauge) comes with a 100+ pages datasheet. You may dig out of internet a pseudo driver for this chip only to realize that it uses undocumented registers. Eventually you get some support from the producer and get a similar, but different data-sheet, and a initialization procedure leaflet that is close, but doesn’t match exactly neither of the two documents.

Now may think that a battery is a straightforward component and that the voltage you measure to its connectors are proportional to the charge left in the battery. In fact it is not like that, because the voltage changes according to temperature, humidity and the speed with which you drain the energy. So the voltage may fall and then rise even if you don’t recharge the battery.

To cope with this non-linear behavior the fuel-gauge chip keeps track of energy in and energy out and performs some battery profile learning to provide reliable charge status and sound predictions about residual discharge time and charging time. The chip feature an impressive number of battery specific parameters.

Since the chip is powered by the battery itself (or by the charger) and doesn’t feature persistent storage, you have to take care of reading learned parameters, store into some persistent memory, and rewrite them back at the next reboot.

Btw, this is just a part of the system which is described by some 2000 pages programming manuals specific to the components used in this project.

In a past post, I commented an embedded muse article about comparing firmware/software project cost to the alternatives. The original article basically stated that for many projects there is no viable mechanical or electrical alternative.

This specific project could have an electromechanical alternative – possibly designing a clock with some gears, dials and a mechanical dimmer could be feasible. I am not so sure that the cost would be that cheaper. But the point I’d like to make now is that basically you can’t have an electro-mechanical product today – it is not what the customer wants. Even if the main function is the same, the consumer expects the battery charge meter, the PC connection, the interaction. That’s something we take for granted.

Even the cheapest gizmo from China has the battery indicator!

And this is the source of distortion, we (and our internal customer who requested the project) have a hard time in getting that regardless of how inexpensive the consumer device is, that feature may have taken programmer-years to be developed.

This distortion is dangerous in two ways – first it leads you to underestimate the cost and allocate an insufficient budget; second and worse it leads you to think that this is a simple project and can be done by low-cost hobbyists. Eventually you get asked to fix it, but when you realize how bad the shape of the code (and the electronics) is, you are already overbudget with furious customers waving pitchforks, torches and clubs knocking at your door.

First Sprint

The first sprint is over and it has been though. As expected we are encountering some difficulties. Mainly role keys without enough time to invest in Scrum.

Scrum IMO tends to be well balanced – the team has a lot of power having the last word on what can’t be done, what can be done and how long it will take (well, it’s not really the time, because you estimate effort and derive duration, but basically you can do the inverse function and play the estimation rules to get what you want).

This great power is balanced by another great power – the Product Owner (PO) who defines what has to be done and in what order.

Talking, negotiating and bargaining over the tasks is the way the product progress from stage to stage into its shippable form.

In this scenario it is up to the PO to write User Stories (brief use cases that can be implemented in a sprint) and define their priority. In the first scrum planning meeting, the team estimates one story at time to set the Story Points value.

This is a straightforward process, just draw a Fibonacci Series along a wall and then set a reference duration. We opted for a single person in a week is capable of working for 8 story points. This is just arbitrary. You can set whatever value you consider sound. Having set two-week sprint and being more or less 5 people we estimated an initial velocity somewhere between 80 points per sprint and (having the value) 40 points. The Scrum Master (SM) reads the User Story aloud and the team decides where to put it on the wall. Since the relationship between story points is very evident then it is quite easy and fast to find where to put new stories.

In that meeting, that went well beyond the boxed 2 hours, all the team was there, SM included, but the PO who was ill (the very first day in years). We could have delayed the meeting but the team would have been idling for some days…. not exactly doing nothing, you know there’s always something to refactor, some shiny new technology to try, but for sure we wouldn’t have gone the way our PO would have want us to go.

So we started and in a few moments it became clear that we were too much. Being a project that ranges from firmware to the cloud when talking about a specific story many people were uninterested and became bored and started doing their personal stuff. In the end, we were about three being quite involved in the estimation game.

The lack of the PO in that specific moment was critical – we missed the chance of setting proper priority on tasks since we had to rely on a mail and we can’t ask our questions and get the proper feedback. At the end, we discovered that the topmost prioritaire User Story remained out of the sprint.

The other error we made was to avoid decomposing User Stories into Tasks. This may seem redundant at first, but it is really needed because an User Story may involve different skills and thus different people to be implemented.

The sprint started and we managed to get the daily scrum. This is a short meeting scheduled each day early in the morning where each member of the team says what she/he has done the day before, what is going to do that day and if she/he sees any obstacle in reaching the goal. This meeting is partly a daily assessment and partly an intent statement where, at least ideally, everyone sets the goal for the day. Everyone could assist, but only the team may speak (in fact has to speak).

Daily Scrums were fine, we managed to host one/two programmers that were not co-located most of the time via a skype video call. The SM updated the planned, doing, done walls. The PO attended most of the times.

On the other hand, the team interacted sparingly with the PO during the sprint, but just in part because his presence was often needed elsewhere. Also, I need to say that our PO is usually available via phone call even if he’s not in the office.

This paired with the team underestimating the integration testing and definition of done. Many times user stories were considered done even if not tested with real physical systems, but just with mockups. Deploy process failed silently just before the sprint review leaving many implemented features not demonstrable. Also, our definition of done requires that the PO approve the user story implementation. This wasn’t done for any task before the sprint end, but we relied on the sprint review for getting the approval.

The starting plan included 70 Story Points and we collect nearly another 70 points in new User Stories during the sprint. These new Stories appeared both because we found stuff that could be done together with the current activities or the needed to be done to make sense of the current activities.

Without considering the Definition of Done, we managed to crunch about 70 points that were nearly halved by the application of Definition of Done (in the worst possible moment, i.e. during the Sprint Review).

Thinking about improving the process, probably working from remote is not quite efficient, I noticed that a great deal of communication (mainly via slack, but also via email and Skype) happened the day that those two programmers were off-site.

The sprint end was adjusted to allow for an even split of sprints before delivery, therefore we had something less time than was we planned for.

End/Start sprint meetings (i.e. Sprint Review, Sprint Planning, and Sprint Retrospective), didn’t fit quite well in the schedule, mostly because of PO being too busy in other meetings and activities.

Am I satisfied about the achievements? Quite. I find that at least starting to implement the process exposes the workload and facilitates communication. The team pace is clear for everybody.

Is the company satisfied about the achievements? This is harder to say and should be the PO to say this. I fear that other factors affecting the team speed in implementing the requests of the PO may be considered with the scrum and dumped altogether. Any process poses some overhead and the illusion that a process is not really needed to get the things done is lurking closely.

Today we planned for another sprint, but this is for another post.

The build succeeded… uh, yes, and…

The phone rings in the heart of the night. A sleepy programmer, tired for an extended period of hard work and long hours, wakes up and after a few attempts picks up the receiver. On the other side the slightly frantic voice of his boss: “Good news. The build succeeded…. oh, yes, and Jimmy has been kidnapped”. In fact, Jimmy (not the real name), a coworker and friend, had been kidnapped by two crooks while he was withdrawing at an ATM a couple of hours earlier. Luckily he was released in the night, naked in open country, but unharmed.
Well, I wasn’t there so I can’t say for sure if the conversation really occurred this way or if it has been “enriched” for the audience. But this situation came to mind recently because I start feeling that it captures quite well some peculiar traits of the videogame industry when compared to the software development industry at large.
In my experience, and surfing the internet also to many other experiences as well (see this, this, or this, or just google for more results), most game development projects turn into a nightmarish run for your life against the deadline. The only certainty is that you and your loved ones are going to pay an exaggeratedly high price for you “making games”.
Family, health, friends, life, nothing matters when confronted with The Game. You can’t plan a vacation with your family, you can’t go to the gym, you can’t be home to be with your children or your wife, but hooray the build has succeeded.
But why? Why has to be like this in the videogame industry? While industry and academia have developed methods and strategies to improve project management relieving workers, reducing risks and improving quality, why the game industry fails so epically to be a saner environment?
Of course every project, regardless of the industry, has to be profitable and economically viable. And the justification I often heard is that if you are late then you can only work longer to hit the target. You have only to agree, but this is just denying the value of planning. Is like to say if you are outdoor and starts raining you can only get wet. Yes. At that point, you don’t have any other option. But a good planner likes to be prepared and would have brought an umbrella.
As any project management book will tell you, projects are defined by three variables – time, resources, quality. Time is, well calendar time needed to complete the project. Resources are the people working on the project and their tools. Quality is the quality of the product that can also be seen as a list of features.
Of these variables only two can be set, the other one is given. That is, you can set the target quality and the time, but then the resources count is derived and cannot be forced. If you attempt to fix all three variables, then the project will be understaffed or late or shoddy, possibly all three.
The agile process doesn’t do any magic, it is just chopping the project into smaller projects with more flexibility on the feature list. A sane agile project will scrap features that don’t fit into the iteration and those that add the least value to the project. This is known also as de-scoping and it is something that I found extremely hard to do on a game project planning.
My impression is that, aside from the basic mismanagement, in the process of developing a game too much passion and too strong emotions are involved. It is not just being passionate about your own work, it is something more akin to religious devotion. In my past experience, people had a brawl because of the misappreciation of an artist’s work.
So, if the videogame is, after all, a work of art and art is about emotions and feelings, is it possible to make games and work in a sane environment?

Demotivational Poster

Yesterday my old friend Jimmy Playfield found a motivational poster on the wall beside his desk. Usually it is quite hard to find a motivational poster that is not lame or, worse, demotivational. And the motto on the wall was quite belonging to the latter. An ancient Chinese proverb quoted: “The person who says that it cannot be done should not interrupt the person doing it”. The intent, possibly, was to celebrate those who, despite of the adverse situation and the common sense, heroically work against all odds to achieve what is normally considered impossible.
Unfortunately reality is quite different. As that famous singer optimistically sang – One among thousand makes it. That sounds like a more accurate estimation for those trying to attain the impossible. And likely, I would add, that one is the person who benefits from advice and help from friends and co-workers.
Human kind didn’t reach the moon just because someone was kept away from those who said it wasn’t possible. To achieve the impossible you need a great team fully informed on why and how your goal is considered impossible. Usually great management and plenty of resource is helpful, too.
Just reminding a lesson at the University. The teacher, made this example: “Microsoft, in the search for new features to add to their compilers line may find that adding non termination detection would be great. Imagine, you write the code and the compiler tells you that no way, under these condition, your code will hang forever in some hidden loop. Wouldn’t it be really helpful? But this is not possible and it has been proved by Turing”. But… According to the motivational post, no one would be expected to tell the marketing and the poor programmer that volunteered for implementing the feature, that no matter how hard he tries, that feature is simply not possible (at least on Turing machine equivalents).
So that motivational sentence is basically against team work, informed decisions, information sharing, risk management.
A witty saying doesn’t prove anything [Voltaire], but sometimes it is just detrimental.
Well, I was about to close here, but I just read another quote by Voltaire: “Anything too stupid to be said is sung.” Well… that makes a good confrontation between Morandi and Voltaire.

The Lottery Syndrome & Other Hypothesis

Software projects, regardless they are small or large, are likely to fail or go overtime/overbudget today not much less than they did 60 years ago. What is puzzling is that, over this period, academy and industry, defined, if not a complete theory system, at least a set of rules, best practices and “don’t” lists that, they claim, can provide accurate (or at least good enough) estimations for the effort required to complete a software project, while also providing a set of tools for managing such project to reach the desired objectives. So the real question is why projects keep failing and management keeps ignoring the wealth of evidence that would lead to better handling of such projects.
Yesterday I watched the webinar “Software Estimation in an Agile World” by Steve McConnell. I “met” Steve years ago, nearly by chance, reading his book “Software Project Survival Guide”. He is a great Software Engineer so listening to what he has to say on the matter is always worth the time.
At a given time in the presentation, a point is made that progressing the CMM level of a company not only allows them to obtain very good estimations but also development costs are reduced.
So, what can prevent any wise company manager/owner/leader to climb the CMM ladder? I have three hypotheses and my guess is that the real reason is a specific combination of these three.

  1. Mystical Data. At CMM level 0 the company is in the wilderness of mystic evaluation. There is no scientific data since there is no data collection a thus no data elaboration. The company may, in “bona fide”, reckoning that current practice is actually faster without the burden of the process.
  2. NAH Syndrome. Sometimes I heard this. It goes something like “yes, CMM and real process and the like are useful for large companies or for places like NASA and nuclear reactors [a favorite example], but CMM is Not Applicable Here, it would cost too much and it would slow us out of competitiveness”.
  3. “Lottery Syndrome”. This is very close to the reason you may want to enter a Lottery. You know that the chances to win are low, BUT they are not zero. In the same way, the company knows that driving a project without a CMM may be risky, but there is an actual chance that the outcome is a project developed in the given time and budget and in a way that makes the customer happy.

What do you think?

Reign of Terror

Thanks to linked-in pulse I stumbled in this excellent article Why my employees don’t care. I wonder, how many workplace are where bosses read these kind of articles (and Peopleware and Slack, and I may go on and on)? At the end my impression is that those who read this kind of literacy are not the people who have the real power of making things happen.I always have been at discomfort with the “Carrot & Stick” method, not to talk about the “Reign of Terror” (Project Managers are watch dogs that must shout and menacing to keep people doing what the must do). If I have to look back at my career, I expressed my profession and skills at best when I was given (or was able to get) an “insulated” framework where I could work without watchdog on my neck ready to bite me at first hesitation.

In the hope that soon or later, also those in charge will read.

You can’t see atoms

You can’t see atoms. That’s what I was taught. Well, everything you see is actually made by atoms, but you can’t see single atoms – that was the meaning of the teaching. Simply it is not possible – it has to do with atom dimensions and light wavelength. I won’t delve into the scientific reasons, but every serious physic textbook will confirm this.You may imagine my surprise when I saw some pictures of actual molecules. In fact it is true that you can’t see atoms (nor molecules), but you can use specialized sensor to produce a visual representation of atoms and molecules aspects. Yes it is not seeing directly by light rays, but is fully equivalent for all practical purposes.
That’s the idea – something is considered impossible until someone comes out with an idea to work around the limitations and voila, what once was considered impossible, today is within everyone reach.
This is what my friend Jimmy Playfield (the name is fake to protect his privacy) told me.
Some days ago Jimmy’s boss called him and all senior programmer and senior hardware designers to assign them a homework for the short vacancy they were about to have.
The goal was to find a way to work in the company environment and successfully craft project after project. The constraint though were that they couldn’t change anything in the chaotic way projects were handled.
Here is a sum of the constraints –

  • budgets are fixed, no increase in the engineers workforce;
  • requirements are roughly defined at the beginning of the project, then they continue to pour in during the entire lifetime of the project;
  • Resources are not statically assigned to a single project, but they may be temporary (and not so temporary) shared among two (or more) projects;
  • contracts are naively written, no real fences and firewall are set to force the customer to behave constructively nor to protect the company from customer whims;
  • project manager role has been declared useless, so their company charges the responsibilities of project management onto project specialists;
  • there are more projects than programmers;
  • no real policy for resource management, no motivational incentives, no benefits, no training (well, here I guess Jimmy was somewhat exaggerating).

Easy, ain’t it?
Well it sounds a hard problem. Let’s see what “project management 101” has to say about this situation.
First the triangle of project variables. Basically for every project there are three variables – Budget, Features and Time. Of these three variables you can fix two (any two), but not the third one. E.g. you can fix Time and Features, but the Budget is a consequence, or you can fix Budget and Time, but Features are a consequence (this is the agile methodology configuration.)
Usually projects at Jimmy’s company have Budget and Time fixed. So the only chance would be to work on Features.
Features variable is to be intended as a mix of features and their quality. A poorly implemented feature is likely to take less time/budget than a robust and top quality implementation. So they could slash the quality.
The problem to work in this direction – put aside ethical aspects – is that usually quality is the topmost motivational driver. Taking pride of what one does helps the involvement in the project. When a programmer in despair states – “tell me what I have to do and I’ll do it” – that’s the end of motivation, the end of involvement and the sunset of efficiency. The programmer will consider that project an accident, something that is not worth his/her neurons to be burnt on.
The other problem in slashing the quality is that legal contracts have to be armored to protect the company against the customer that could complain about the lack of quality.
I can’t see any solution for them, at least, not within the system, much like you can’t see the atom without moving to another level.
So by moving to a meta-level, you can break out of the system, e.g. by hiring someone to write the code for the project. This programmer won’t do any better than Jimmy and his coworkers – sometimes he will complete the project, sometimes he will fail. But to the company is a win-win solution, if the contractor succeeds then the company wins, if the contractor fails then the company could blame him and that’s a win again.
The major problem I see with this is that it is a bit suicidal, i.e. Jimmy and his coworkers become redundant and disposable as soon and the contractor is hired. Good luck, Jimmy and let me know if you find a better solution.

Managing Project

The current project I am working on could be considered a medium size. It involves 5 software engineers and 1 hardware engineer for about 8 months. I contributed to the planning of the software components, but I am quite critical about my skill in predicting future. Considering the pressure from top and middle management to complete the project on a given date I would take my own planning prediction with great care. So I dared to ask the project manager if he was doing some sort of risk assessment. His answer – “What the heck! If I had to do _even_ risk assessment then I would have no time at all for anything”.