--Originally published at Debugging My Mind

Today I’m gonna talk about two TED talks I watched, one done by Sam Richards, speaking about empathy, while the second one was done by David Marquet, focused on leadership.

We always think of empathy as the stereotipic small definition of “putting yourself in someone else’s shoes”, which is not saying that is wrong, but rather how deeply we actually think of it. As a student, I’ve been able to travel to different countries a few times, the most special one being the time I lived in Japan for a summer, living with a japanese family, studying the language, experiencing their culture and meeting people from a lot of different countries. An experience like this is, I believe, one of the biggest “eye openers” that a person can have towards the world, how the moral rules, the stereotypes, your opinion on plenty of things change, when you truly notice how small of a world you were originally living in.

I can safely say that experience has made me a very open-minded person, and it only goes better from that, you learn to understand, you start asking yourself “why reject things without a reason”, or “what’s truly wrong about something”, there’s plenty of moral rules here in Mexico that we all follow or consider normal without ever asking ourselves why, or even doubting lots of them at all, it can lead to people hating, judging, going out of their way to make their voice be heard when they complain about someone when it’s doing absolutely no harm to them, just because it doesn’t fit in the “normal” scenario that they’ve lived in for so long and that they don’t want to have broken.

That’s the thing with empathy, just like the talk says at the very end and that I liked a lot, specially cuz it’s a personal thing I can completely understand and have experienced. Once you manage to walk even an inch on someone else’s shoes, in a completely different and radical position to yours, one that makes you think, analyze, try to understand, suddenly the smaller things, the ones you deal with in your daily life, become so much easier to deal with and understand.

---

On the other hand we had a talk about giving leadership, giving control, not taking it. I couldn’t agree more with it, I have honestly always had a gripe with the educational system we still use, it’s a very old model, made to make soldiers, people that follow orders without questioning, making followers in a world that requires thinkers right now. Why do we keep forcing people to learn things that they won’t use, and I’m not talking about common knowledge that should be taught, like say basic maths, but are things like chemistry, calculus, physics, on a higher educational level, really going to help absolutely anyone? I know plenty of people who live a happy and successful life, without having ever used it or worried about it, so that means it was wasted time right?

Why not push people towards the things they like, the things they’re good at, the ones that are going to be useful for them in the long run. This would basically make, in a nutshell, thinkers; people who are excited to work in what they do, enthusiastic in making things work or try new ideas, and capable and wanting to make their own contribution to the bigger picture. What our country really needs right now is thinkers, not followers, for it’s the only thing stalling us in the place we are, allowing the corruption and bad practices to carry on.

--Originally published at Debugging My Mind

I like correlating what I read with my own developping experiences, trying to notice what I’ve been lacking, what I’ve been doing and how it can be similar to what the book refers to and finally, what I’ve been doing wrong. The last one tends to come up a lot in the scholar environment, as a lot of times we strive to get things done in a certain way or period of time and with a different incentive compared to a job (having the reward only be grades and learning instead of monetary compensation) which lead us to a lot of mistakes and  complications.

When it comes to a quality assurance plan, we most definitely aren’t used to make one, we usually only do proper testing once things start breaking or when the functionality is “completed”, leading into a bunch of work fixing and dealing with lots of bugs.

A really detailed plan seems very necessary for big projects, ones that will be on development for a long time and require the utmost efficiency to be on proper schedule and budget, but I don’t think this will be the case for all projects, it feels like the book, while mentioning a lot of the tools for developping these plans (like taking in consideration defect tracking, unit testing, source-code tracing, technical reviews, etc.) it doesn’t mean we have to apply every single one of them, meticulously in every project we work on, I believe the goal is to learn to sit down, analyze the problem we’re solving and what we’re developping and choose a good schedule of how quality will be checked and assured throughout the process, which in essence, becomes a plan, a quicker one it may be, but a plan in the end.

As we go into projects that involve multiple people, it definitely becomes necessary to record everything we do, since most of the times I think the biggest problem ends up being communication. Did someone fix this already? Has somebody noticed this bug? Is anyone working on this particular thing? All of these questions can be answered with a plan and proper communication. Maybe scheduling bug fixing to particular days, update the project management tool that work has started on a specific problem, write down bugs that have been found and if they have been fixed or not and how much time it took.

In the end, I believe a huge document that very thouroughly noted down every tiny bity detail might be way too much for a lot of projects, reserved to that extent only for very big or continous ones and it’s important to also consider that, how are we gonna tackle a task at hand and how much detail does it truly need? I also agree with a particular thing that keeps being mentioned, if a documentation and plan is made, if a schedule is created, they are for a reason, they should be followed and not ignored, what’s the point of using a lot of time into planning if it’s only to be scrapped and disregarded, thing I feel can be common in scholar projects.

After all the QA talk, we dive in onto System Architecture and oh do I think this one is important, I think the word itself is what should describe a Software Engineer and a programmer, the key difference, we are to have the technical and logical background to be able to design the solution to a problem. To not only make things work but have a reason for them to be the way they are, be it scalability, compatibility, performance, among others.

Most systems don’t exist in a secluded environment where they don’t interact with others, where everything will be perfect as long as they stay in their little bubble, that’s why we need architecture, not only that, but because the big system in the end will be made of smaller subsystems that handle different tasks, should one thing break, why should it mean the whole application stops working? (unless it’s a critical component for the whole application’s functionality).

Thanks to notation like UML we’re able to create diagrams that can be understood by anyone who knows the notation, making the design readable and easy to implement, which it should be, since the goal is to make an almost series of steps of how the system works and will be created, not to make a super complex mess that only the architect will understand.

While I believe there will be a class specifically orientated to this topic (or at least I hope there will be), there have been some considerations on it on others, where we have to start getting used to minimize dependencies, separate tasks, be able to make changes with ease, all good practices that lead us towards the path of being able to be good architects down the road.

Programs didn’t use to be made with the thought that they would be given maintenance in the future, compared to today’s software, running old systems ends up being a complicated task, needing very specific environments and conditions, while newer software is readibly patchable and adaptable to the future changes, it’s a living proof that it has become an important point in software development.

--Originally published at arantza's blog

¿Conoces los muchos beneficios de los grillos?

Se dice que en la antigüedad, una parte muy importante de la gastronomía de los mexicanos son los insectos, ya que son una fuente de proteína muy saludable. Nosotros como empresa mexicana queremos inculcar el hábito alimenticio que tanto caracterizaba a nuestros antepasados. ¿Y qué mejor que con algo delicioso como las galletas?

--Originally published at Debugging My Mind

Yes, just when we thought just planning was good enough we have to tackle this new idea, preliminary planning, but is it really new?

There’s a lot of activities and processes when working that we do without much thought, that pass on as quick non important topic, but after some reading and a bit of reflection, it becomes clear that they are actually  way more relevant than they seem.

How many times do we start a project based on an idea, just to realize not everyone is actually fully attuned to it, I certainly have, a lot of the times we assume that everyone understands what we’re going to do, but it ends up causing some confussion and problems down the road, it even prevents potential improvements to the project due to not fully understanding the goal. We all find it silly to have to physically write the actual objective and vision of a project, but it ends up being more useful to understanding what we’re all going to work towards in the end.

In school work, we often don’t truly have an external group making the huge decisions for our projects, it’s mostly up to us (with a bit of feedback from teachers most of the times) to decide and do changes as we see fit or simply choose the features we need to include in our project. This ends up being messy most of the times, overestimating what we can add and leaving things out that we couldn’t complete or even changing our end goal depending on the final product we were able to create.

There’s definitely little to no preliminary planning in most projects we do for school, mostly due to time restrictions and the advancing nature of the work, where we’re being guided by our teacher, but there’s definitely a lot of opportunities to start making use of what we can and specially on what might definitely need it. I believe these planning tools work as guidelines of how much more preparations and documentation we can do to make the implementation part easier, but it’s up to us to recognize depending on the project, which ones we gotta use, which ones can be taken out due to time or goal and which ones end up being critical to make things easier, even then I do think it’s worth knowing and considering all of  them and how they make the difference between a programmer and a software engineer.

 

--Originally published at Debugging My Mind

Whenever a new project arises, becoming a potential client, software devloppers jump at the opportunity promising and proposing fantastical and optimistic things, it feels like when you’re told “tips” for job interviews, you want to exaggerate and be as optimistic as possible, nothing bad, only good stuff. Thanks to this, everything becomes “possible” and very attractive time estimates are given really fast, even when estimating the time for a project can be incredibly difficult and probably needs time itself.

I think that’s the main problem, nobody wants to say that something is impossible or that it will take really long, everyone wants to “look good” about their proposals so they get the job, but isn’t failing and delivering late, or even failing the project altogether worse?

Some time ago when I began studying software engineering, I had teachers be very persitent with saying “you’re not programmers, you’re engineers”, we are not being taught to be programmers, anybody can do that, and the way software development is handled a lot of the times is from the programmer perspective. “Sure I can do this”, “Yes this can be done in X time”. Being engineer means being able to plan things, to make estimates and evaluate the given problem, use logical and exact knowledge to backup their decisions.

It’s true than in many other work areas, including engineering benefit from just adding more people to projects to make them finish faster, divide all the work load and ta-da~ it works, but this is definitely not the case with software. Why would it sound better to make smaller teams for projects instead of adding more people, simply because in my own experience it takes more effort to coordinate everyone, to have each of the members be in sync with what’s going on and what must be done. Work can’t be as easily divided and assigned separately unless it’s completely independant from the rest, which is a difficult thing to come by in software. You can try and make modules and functions as less dependant as you can, but they’re still gonna need to integrate with the others and communicate, you can’t have the groups of people working on them completely isolate from each other and expect everything to go well.

I agree with how the “Man-Month” formula is a myth for software development, how we’re currently on the transition of understanding the fact that this engineering area of work isn’t the same as the rest, how the “common rules for work” don’t translate that easily and how a general mindset must be done to correct all of this.

--Originally published at Debugging My Mind

I’m gonna take a different approach from now on, instead of mentioning things the book is saying by chapter I’m just gonna give out my opinion on the topics it talked about, whether it’s one chapter or the other will be up for guessing but it’s probably more important to identify the topics themselves and what I think of them.

First off we have staged delivery, dividing the project in different stages which all need to be able to be delivered even as a finished product at different intervals instead of having one big thing that is all delivered at once a single time at the end of a project.

I think this kind of project model fixes not only a lot of the developping issues that exist already, but also a lot of the “business” or non developping issues that stakeholders and users have with development itself.

People want results, they don’t want to be told “oh it’s going good” or “oh it’s X % done” and not actually see the fucntionality or what they’re going to receive yet, sadly, since software development is not a tangible thing except for documentation for a long time before you can see the actual program working (at least most of the cases with the usual developping methods) it’s bound to face a lot of credibility issues from the stakeholders and is one of the main problems we see these days.

For me, staged delivery seems to be a really good alternative to face all these problems I mentioned, being able to deliver something tangible in periodic releases involves the end user a lot more, to be able to meet their expectations and for them to see continous results from the development, which might just be worth all that extra effort that can be created from the new overhead required for multiple deliveries and version control.

It definitely doesn’t seem something too simple to transtition on, as pretty as it may sound from explanation alone, but I do think it’s something I want to try for myself and see how it goes, no matter how small the project is. (Having a big list of deliverable milestones and documentations definitely sounds like a big chore and a turn away like the book mentions, but hey, we gotta do it eventually, might as well start early and save ourselves a lot of bigger trouble later).

Next up we got change control, oh boy change control. As a student we often find ourselves stumbling trying to “apply” some of these concepts throughout version control on git, keeping code on a repository that can rollback if needed and help control the whole thing.

I actually think we don’t get enough sort of guidance or classes or teaching that revolves around this sort of stuff, as students we’re usually hesitant to change stuff once we got it going, considering change as a meeting between all members to do something big to the whole project can be difficult after the whole initial idea and planning has gone through, and not only that but even as we try to use git and repositories to keep control, most of the times we’re never fully sure how to utilize its whole potential or what’s the “right” way to approach it, leading into issues and more problems than we want.

I agree it’s important to be willing to consider changes specially propose and look at them in the first phases of development like requirement and planning, where you can do all these changes basically for free unlike in the coding where things get a whole lot more complicated. Clients can be resilient to make big changes way down the road and it’s important to make it real clear what sort of cost something like that will take but at the same time it’s our job to try and squeeze out all the possible wanted changes as soon as possible early in development when they can be actually done.

--Originally published at Debugging My Mind

Another day, a different book, this time looking at The Mythical Man-Month by Frederick P. Brook. What a weird title might I add, which is also a pattern that comes into the chapter titles, but in the end surprisingly, they provide very interesting analogies.

We start off with one of those, how animals and beasts would struggle on tar pits sinking down no matter how strong or small they were, just like that, programming teams can sink down the tar pit of a projects work, may it be a big or small team, nobody is exent of the dangers that software developping entails for the success of a project.

Thinking of programmers, a lot of people think of the small team in a garage, developping a program, just like anybody can do it, why the need of big corporations with hundreds of developpers and employees. Well yes, anybody can make a program, but it’s the difference between a product, a system and a system product that marks the quality and trascendence of a lot of the results, each as much as 3x harder than the basic one. As a lot people like to see it, everything is nice and pretty until you have to document everything, explain every nook and cranny so anybody can get involved, and even making it work with other programs, this is what sets the difference to have a program become a system product.

So with this comparison of the normal programs and a programming system product, and how a software developping project is compared to a tar pit, why is then that so many people want to get into programming or are so eager to try it out. In my opinion that’s the most interesting thing presented in this chapter, why is programming so likable? even to someone like myself, who is majoring in software engineering, couldn’t simply answer that question in a way anybody could understand, or I didn’t have the proper way to explain it, and another way of looking at it, I didn’t even know what I liked of it myself.

The book here presents you the best description I’ve heard of programming, what is it from it that attracts so many people and makes it likable, what makes people continue and persevere even with all the woes and difficulties that come with it. Long story short, it’s how you are provided with a relatively easy environment to experiment, to let your creativity cut loose, and not only that, but the result being something real, something interactive, something that “moves”. It’s this end result that makes so much excitement for what you’re creating.

I’m excited to see what the rest of the book has in store for me, for I am one of the people that thinks the joys of programming outweighs the woes, and I’m excited to see what boardwalks will the book provide me to walk across the tar.

--Originally published at Debugging My Mind

Today we walk into the next 2 chapters of the Software Survival Guide book, I’ll give a small summary and my thoughts on each of them.

Chapter 3 – The concepts

As the book mentions, even at scholar work level most teams want to avoid the processes and beginning planning that needs to go into a project, due to this, most of those experiences end up being stressful, full of rushing and emergency working, staying up late, stretching schedules and a whole lot of mess in short terms, yet after all of that experience a lot of people just laugh or talk about it as how interesting and strong they are to survive those or even how a new subject will require one of those experiences.

To me, it feels as something inherent, even obvious that something like planning and correct processes at the beginning of the project allow you to avoid incredibly big changes and loss of time, even from my own experience, projects that I haven’t invested careful proper planning end up having what would be a small mistake in the past to be corrected into a huge problem that requires quite some time for fixing.

It is true, having a process is the clear way to fix all of these problems, to make the whole journey easy, but the hardest part is to convince your team and coworkers to go along with this, to invest time into the processes, it always seems like the most boring thing, they just want to get right on the “interesting” part, and the question remains, how do you convince them? telling them of the consequences doesn’t seem to be enough a lot of times until it’s actually happening, the great focus is not only on learning effective processes but also an effective way of relaying them to everyone else and convince them of their use.

Chapter 4 – The skills

We begin with the main topic of the last chapter, planning, in this case the book adresses what I was talking about, trying to convince your team to take planning into account and invest the necessary time into it, talking about hours, hard data, time. It mentions how big the increase in time the projects mistakes upstream cost when you’re downstream, things that can be fixed for so much less if caught early on due to planning.

Not only that but we’re provided with several different examples of planning for software developping, including: the development plan, the project estimates, the revised estimates, a quality assurance plan, a staged delivery plan, and a few others.

One of the examples I have the most experience with is requirements development, identifying the main problem to solve or make a solution for and specify each and one of the many requirementes that it has to achieve by the end of development, be it functional, non functional, interface or business model wise, there are many things that need to be specified. What the system can and cannot do, where it will be supported and any rules from the client themselves that it has to follow for their business. This is something I don’t see a lot of people around me applying yet it’s so important and in my opinion, not difficult to do right.

Another skill talked about is two-phase funding approach. Where you ask for the funding needed for the exploratory phase so you can concretely find out how many resources you’re going to actually need for the project itself, knowing exactly what will be needed and what the client wants.

The planning checkpoint review is a great tool to find out how viable and what changes are required to the project to make it possible, better to have a good control of what needs to be done and how do-able it actually is before asking for funds for impossible tasks, unrealistic deadlines and complex functionality.

An important thing to note, also mentioned after the planning checkpoint is the involvement of the team members, you want them to have a clear vision of what the plan is, make them feel appreciated and actually part of the project, align their interests with the work assignments, in the end the projects isn’t being done only by the managers, but the whole developping team itself, there needs to be a good inclusion and integration from all parties to make all these processes succeed.

After all that, we touch possibly one of the most ignored and most important part in software developping, user involvement. The Chaos theory mentions how lack of user involvement attributes to one of the highest reasons of project failure, if the client doesn’t know what’s going on, isn’t invested and aligned with the project itself, what chances are that it will be deemed sucessful or that it will meet his expectations, when the users and clients themselves are fully involved and constantly being asked for feedback, the project is something deeply connected with them, something they are fully involved and interested in, and more importantly something they perfectly know the state of and have realistic and proper expectations for.

Far too many times teams want to chase for the next biggest idea or the best software ever made, which on one side thinking that big isn’t bad by itself, but keeping the core idea at front at all times and considering its importance is the deal breaker, clients want a software they can use, having differentiating software is very good, but if you can’t even provide the core solution without the polishing, then it’s basically no solution at all. It’s best to keep as minimalistic as possible early on and then add any polishing required should the time be available. It’s not about rushing a product, but focusing on what’s truly important.

--Originally published at Debugging My Mind

The blogging is back once again, this time it will focus on the progress of a book with a very interesting title. The Software Project Survival Guide by Steve McConnell, for now I’ll be focusing on the content in the first two chapters.

Chapter 1 – Getting welcomed to the survival

There’s a common thing I’ve been hearing throughout my software engineering studies and that’s that software development is in crisis, that referring to how so many projects that are started tend to either fail or be challenged (in other words exceding the expected cost and time) which is interesting but not that surprising due to the increasing complexity nature of today’s software needs.

One thing that does stand out is how on one side products are expected to be these perfect, enormous piece of software that can be used with ease and with no errors while projects are expected (hopefully) to just work, to succeed.

To begin with the book gives an analogy of the Marlow pyramid focused on the needs for project developping, how there’s some things we have to fulfill and be addressed before we can even touch anything else.

At first glance the first I thought is “well yeah, this seems like common sense” but it’s surprising how in practice there’s a lot of problems with the base of the pyramid, needs that HAVE to be fulfilled before we can focus on the tip, which adds the quality for the project to stand out, and creating that chance of failure.

Another important thing I agree with the book is how both the client and the team project need to have these set of “rights” or “rules” that they have to respect between each other, things as simple as providing requirements and meeting them that aren’t taken in mind given the proper importance and communication can be fleeting or missing, things like this as told by the Chaos theory are the biggest reason of project failure.

Chapter 2 – Putting yourself to the test

The book provides a simple yet hard to pass test for all project works going on or starting out, even dividing all of these questions in different sections of the project like planning, personnel and project control.

This is really useful and something to take at heart. There are a lot of situations already going on in college where teams decide to skip steps, to avoid documentation, avoid planning, ignore project control. Might it be to skip the “boring” part or to just get the work done for the grade, but it creates this really bad practice that goes out to the field once everyone graduates.

Ever since my engineering fundamentals class I’ve been amazed at how much failure exists for things that to me, start to seem like common sense. So many other engineering or professional areas already use planning as stepping stone for a surefire way to start off correctly, why don’t we?

--Originally published at Welcome to the realm of

Even though it’s not part two technically and it probably doesn’t make much sense, it is a continuation, a signal of life to my blog. It’s been almost a week and two days since I first started and until now I’ve been writing fairly regular. I realize now that I like thinking and writing my blogs in english which is nice.