My mission is to create teams that change the world.
I began this mission as a software developer. I saw in myself and other teams a passion for creating products that people would use and love. I saw that same passion dashed over and over again when the products fell flat. I knew there was more out there.
I have sought for years to find ways of enabling teams and organizations to have a different story. One where the hard work pays off. One where people take pride in a job well done and a product that people love.
I’m a long way off still from saying my mission is accomplished, but I’m here to share what I’ve learned and to help people find that new story.
~ Ryan Latta, LeanAgileUS 2019 bio https://twitter.com/recursivefaults
In order to defend and preserve the honor of the profession of computer programmers,
I Promise that, to the best of my ability and judgement:
- I will not produce harmful code.
- The code that I produce will always be my best work. I will not knowingly allow code that is defective either in behavior or structure to accumulate.
- I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should.
- I will make frequent, small, releases so that I do not impede the progress of others.
- I will fearlessly and relentlessly improve my creations at every opportunity. I will never degrade them.
- I will do all that I can to keep the productivity of myself, and others, as high as possible. I will do nothing that decreases that productivity.
- I will continuously ensure that others can cover for me, and that I can cover for them.
- I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.
- I will never stop learning and improving my craft.
This video has been floating around for a while now. I found it hilarious. But in reality the more I think about it and the message in it the more true it seems to be. I wish it wasn’t true but it is. Pulling requirements out of users who aren’t sure what they want can be difficult, if impossible at times. It takes a skilled person to be able to design software for users like these.
When I am designing a project and laying out the architecture for it I start from two directions. First I look at the project being designed and determine what the business problems are that needs to be solved. I look at the people who will be using it and start with a crude UI design. At this point I am ignoring the data and just looking at what the users are asking for and who will be using it.
Once I have a basic understanding of what they are asking for I determine what the core data is that they will be manipulating and begin a basic database layout for that data. Then I start to ask questions to define the business rules that surround the data.
By starting from both ends independently I am able to lay out a project in a way that melds the two ends together. I always try to keep the designs separate for as long as possible before melding them together, but keep in mind the requirements of each as I move forward.
Once I have a good solid understanding of each end of the problem I begin to lay out the structure of the project that will be created to solve the problem.
Once the basic layout of the project solution is created I look at the functionality of the project and set up a base set of namespaces that are used depending on the type of work being done. This may be things like Account, Shopping Cart, Surveys, etc.
Here is the basic solution layout that I always start with. As the projects get better defined I refine it to meet the specific needs of the project. Some areas may be merged with others and I may add a few special ones as needed.
For large projects there are certain documents that need to be kept with it. For this I actually create a separate project or folder within the solution to hold them.
Unit testing always depends on the project sometimes it is just really basic to catch edge cases and sometimes it is set up for full code coverage. Recently I have added graphical unit testing to the arsenal.
Some projects have specific installation requirements that need to be handled at a project level.
Used if there is a need for web services, APIs, DLLs or such.
The repository contains base data classes and database communication. Sometimes also hold a directory that contains any SQL stored procedures or other specific code.
These classes contain the base classes, structs, and enums that are used in the project. These may be related to but not necessarily be connected to the ones in the data repository.
Contains any code that will perform CRUD actions with the data. It is coded in a way that the repository can be changed out with no need to rewrite any higher level code.
Performs any data calculations, business level data validation, does most interaction with the Service layer.
I always create a code module that contains helper classes. These may be extensions on system items, standard validation tools, expressions or custom built items.
The user interface is built to display and manipulate the data. UI Forms always get organized by functional unit namespace with an additional folder for shard forms and one for custom controls.