Conceptualization

I ask my team on a daily basis to solve problems.  We solve problems by putting code into our apps.  The more I do this, the more I realized we all approach and solve problems differently: some try to fix things as quickly as we can; some contemplate on the problem for a while before acting.  Do it too quick without thinking and you get inferior code; do it too slow with too much thinking and you might never get any code.

It’s about putting ideas into action – what I call Conceptualization.  There’s a balance in learning to keep looking versus give up thinking/searching and do it.  It is an art.

Sometimes I find myself talking to myself, “I have no idea what I’m doing.”  That means I don’t have a plan, I just improvising as I do.  This usually happen when I cook.

At work, I used to have these four words posted as a big sign in the meeting room:

Analyze
Plan
Implement
Review

It reminds us that there are these four phases to solving a problem.  Knowing the four phases not only help us organize, they also remind us we should move on from one phase to another.  It also doesn’t just stop at Review, because we’d start over if we have enough time to revisit the same problem.

Am I spending too much time analyzing/planning/implementing/reviewing?  If any of these phases are taking too much time, it means we have not put enough time in the other phases.  There is an imbalance.

Someone once told me I take too much time to analyze.  My response: we are always stuck during implementation.  During implementation we often find what we built doesn’t actually solve the problem, so we have to rejig the plan and improvise.  Our problem is that we didn’t spend enough time and effort analyzing the initial problem.

Why don’t we spend enough time and effort analyzing?  Most of the time it’s because we aren’t experienced enough to foresee problems with our designs.  Other times, we are just lazy.  Sometimes, it’s both.

Over-simplification of the initial problem is a common culprit.  “Think of the edge cases,” I would remind my team.  “Now you have the sunny day scenario, start understand the rainy days.”

Not simplifying the design can also be a culprit.  Simplifying user experience is a difficult task.  Making the complicated simple is an art.  At the end of our analysis, is what we have too complicated?  As Charles Mingus famously said, ““Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that’s creativity.”

Someone once told me that the Agile methodology is to be fast and nimble.  He’s implying that there’s no time to analyze.  But just because you can “fail fast, fail often”, it doesn’t mean you have to fail many times to get something right, if you can just do it right the first time!

How do you get your ideas to action?  Do you get your designs implemented smoothly, or usually aren’t very smooth?  I would like to know your thoughts.

 

Lone Wolves vs. a Single Team

It’s been 18 years since I started my career as an application developer. I spent a good part of my career being a full-stack developer: managing the server, taking care of coding, working on interface design, meeting with clients for business requirements, writing documentation, etc. And I usually work on a project on my own. I call this the lone-wolf developer. I still do some of these to this day.

But as I started my management capacity six years ago, I was given a team of six people to manage. I wasn’t familiar with the team members, and it took me a while to understand their skillsets and mentality. Honestly, to this day I am still learning about them. My team is a group of fascinating people, with very different personalities, talents, and working-chemistry.

And that’s when I made my first mistake as a manager: I kept the status-quo by letting each member take care of their own business, that is, if they were already working on a project, they should keep working on the same thing until it is finished. Most of them are, again, lone-wolf developers.

I kept that going for more than five years.

The second mistake I made was that two of my team was on loan to the Operations team to do system integrations. It was my director’s instructions to divide up the team in such a way, and at that time I had no obvious reason to object. My only main complain, at that time, was that one of the developers on loan was a top performer.

Until one day the top performer came to my office and told me that she wants to quit. Well, as first I was in disbelief, and got a bit frustrated because I don’t seem to understand the situation, but eventually I got to know the main reason: she was given tasks and responsibilities she wasn’t hired to do, and those tasks and responsibilities doesn’t line up with her career goals. She has always looked forward to deal with data and designing solutions for data, and cares much less about operational tasks or coordinating of integration with 3rd-party vendors.

So I did the only thing I can do as a manager: I took my team members back to my team.

It wasn’t as easy as it sounds. To this day, I still meet with resistance and criticism, but I took the heat and carried on.

Oh, and I took both team members back, not just one. And I told the other team that for whatever integration or development work that needs doing, I’ll be the coordinator for the work, meaning that I’ll be the gatekeeper of resource control, and I’m going to have to understand all of those projects.

Eight months later, I think I did the absolute-right-thing.

Looking back at those five years, I was managing half a team that simply did not have the capacity to conduct development projects, so I was always getting my own hands dirty, and in turn, I never had enough time to manage projects. I was busy building features that I lost awareness of the larger picture, like organizational awareness, that is, I became less savvy about what’s happening within the organization.

Now that I have a full team of developers, I can actually run Agile development much more effectively. I can actually sit down and discuss features and make design decisions with the team, and take time to help out those who needed advice or got stuck. Furthermore, while the team is busy creating user stories, figuring out epics and designing new features, and putting code into Git branches, I can start putting new requests into the queue. (For those who aren’t familiar with Agile terminologies, I’m sorry…)

I can also start anticipating what should go into the team’s project pipeline. I can actually start formulating strategies around how to tackle the next projects. I don’t have to tell a client that the next version will take 6 months to complete because only one developer will be working on it, instead, it will only take 1 to 2 months because the entire team will work on it as an Agile Sprint.

And after that 1 to 2 months Agile Sprint, we can pause with that one project and move on to another temporarily, collect user feedback and plan for the next sprint in the project pipeline.

I also don’t have a dozen lone-wolf projects that I have to actively keep track of at any given time, instead, I can focus and concentrate on 1 or 2 Agile projects (and, truthfully, a few never ending lone-wolves).

I can also find the time to explore new technologies and tools to use, like we just did with Amazon Lambda, which has the promise to fundamentally change how some of the integration projects work.

Productivity is also better. The team burn down issues 3 times faster than previously.

I also have time to reflect and write this post.

At some point in my career, I wrote this line as my career objective on my resume, “to manage an effective development team to tackle some of the most challenging business problems.”

I hope I’m on the right track.

P.s. I will write in a separate post about how my team find this new approach.

Multi-tenancy

It’s been more than a year since I last posted here.  Actually, I forgot how long it has been since the last post.  My computer broke down yesterday, and is in the shop for a fix, so wouldn’t it be great if I pop on WP and blog a bit?

It’s been an interesting year.  I was put in charge of building an event registration application for a department within the University.  And of course, me being an idealist, decided to make sure the system can be reused by other departments.

Technically, it’s not that hard, but this is going to get technical: (1) basically involve linking all the top level tables in the database to one master table (I called it operational unit, aka op unit).  And the op unit is where all your users would belong to.  (2) You need to start generalizing all naming conventions in the system, for example, you can’t call it “learner’s report” and call it “attendance summary” because not everyone is going to use it as a learning reporting tool.  (3) Administratively, there will be a few more CRUD screens to build, but the extra effort it’s well worth the end results.

The other wrinkle is to make the URL work either by subdomain or subdirectory, e.g.

acme.app.university.edu, and
omega.app.university.edu,
OR
app.university.edu/acme and
app.university.edu/omega.

It’s not hard because this is a custom app we build from the ground up, if this were any other app, it would be hard to remodel it to include this feature.  In essence, this is “multi-tenancy” as the industry calls it.  One application/system, multiple groups of occupants/users.

Fantastic.